MySQL 5.6의 새로운 기능
MySQL 5.5는 일반적인 SQL과 함께 사용가능하며, 영향력이 커지고 있고, 설계자 및 전략가에게 MySQL 5.6의 시작은 새롭고 흥미로운 이야기로 계속 찾고 있습니다. MySQL 5.6 버전은 5.5버전의 계기, 오라클이 투자와 헌신에 의해 MySQL에 대한 더 나은성능과 확장성을 제공합니다.
다음은 MySQL 5.6 개발 마일스톤 릴리스의 개발 완료 시리즈로 얻을 수 있는 기능입니다. 최초의 마일스톤 릴리스, MySQL 5.6.2은 http://dev.mysql.com/downloads/에서 지금 다운로드하실 수 있습니다. 지금 5.6 버전 베타 테스트를 시작하고 MySQL의 엔지니어링 팀에 피드백을 제공하십시요.
성능 향상
최적화 기능 개선
인덱스 조건 Pushdown
스토리지 엔진에서 where절에 대한 데이터 처리가 더 추가 되었습니다. WHERE절의 집합에 대한 결과를 가지고 오는 대신, ICP는 스토리지 엔진에 인덱스 튜플을 검사하여, 결과물을 간결하게 처리 할 수 있습니다. 그 결과는 기본 테이블에 대해서 I/O 오버헤드가 작고, 서버와 스토리지 엔진에 대한 내부 통신 오버헤드도 작습니다. 이 기능은 InnoDB, MyISAM, 그리고 NDBCLUSTER 테이블에서 사용할 수 있습니다.
pushdown 인덱스 조건에 대하여 자세히 알아보겠습니다.Multi-Range Read
여러분이 모드 디스크를 SSDs로 사용할 수 있는 그날까지, 디스크에서 데이터를 무작위로 읽어오는 것보다 순차적으로 읽어오는 것이 더 빠릅니다. 보조 인덱스의 경우, 디스크에 있는 인덱스 항목에 대한 순서와 전체 행에 대한 디스크 블록의 순서는 서로 다를 수 있습니다. 전체 행을 밖에서 부터 작은 순서대로 읽어오는 방식으로 검색하는 대신, MRR은 쿼리에서 사용되는 하나 이상의 인덱스 범위를 스캔하여, 데이터 행에 대한 연결된 디스크 블록을 정렬한 다음 I/O 요청이 큰 순서부터 차례로 디스크 블록을 읽습니다. 범위 인덱스를 검색하는 것과 인덱스 컬럼을 사용하는 조인문 같은 작업이 속도가 향상되는 혜택이 있습니다. (InnoDB의 외래키와 같은것이) 모든 스토리지 엔진에서 작동합니다.
다중 범위 읽기(multi-range read)에 대하여 자세히 알아보겠습니다.파일 정렬 최적화 (File Sort Optimization)
인덱스를 사용하지 않는 컬럼의 ORDER BY 구문과 LIMIT 구문의 결합 검색어 x 행의 내용을 sort buffer에 맞출 수 있을 때, 정렬 속도를 높일 수 있는 기능입니다. 모든 스토리지 엔진에서 작동합니다.
InnoDB 기능 개선
MySQL 5.6 버전 기반의 InnoDB는 기본스토리지 엔진으로 MySQL 5.5 버전부터 완벽하게 통합되었습니다.
영구적인 최적화 통계
MySQL이 재시작 할 때, 향상된 InnoDB 인덱스 통계의 정확성과 일관성을 제공합니다. InnoDB는 어떤 쿼리에서 사용하는 색인의 일부를 표본 추출하여, 미리 통계를 계산함으로서 최적화를 결정하는데 도움이 줍니다. 당신은 InnoDB 각각의 색인의 표본 추출의 양을 조정할 수 있습니다. 그 결과 통계는 재시작하거나 몇몇 런타임 이벤트로 인해 다시 계산되지 않는 한, 서버가 재시작 될 때까지 지속적으로 사용합니다. 보다 정확한 통계는 쿼리 성능을 향상시킬 수 있으며, 지속성 측면은 쿼리 성능 안정을 유지할 수 있습니다. 이 기능은 구성 innodb_analyze_is_persistent 옵션 innodb_stats_persistent_sample_pages 및 innodb_stats_transient_sample_pages에 의해 제어됩니다. 당신이 명시적으로 테이블에 대한 테이블을 분석 실행하여 지속적인 통계 기능이 활성화된 경우, 이 통계 단 한번만 다시 계산됩니다. 지속적인 최적화 통계에 대해 자세히 알아보십시오.
새로운 INFORMATION_SCHEMA 테이블
사람들은 더 많은 종류의 상태 및 모니터링 정보를 말했지만, 일단 InnoDB의 정보는, MySQL 5.5의 INFORMATION_SCHEMA를 통해 질의 사용하도록 만들어졌습니다. SQL 인터페이스는 SHOW STATUS 명령어에서 온 문자를 구문분석한 것보다 표준화되고 정확합니다.
통계 테이블 : InnoDB에 대한 일반 및 종합 자원 및 성능 모니터링 프레임 워크를 제공합니다. 새로운 I_S 테이블은 INNODB_METRICS입니다.
시스템 테이블 : 모니터링 편의를 위해 SQL 질의에 대한 InnoDB 내부 데이터 사전을 사용할 수 있습니다. 새로운 I_S 테이블은 INNODB_SYS_TABLES, INNODB_SYS_TABLESTATS, INNODB_SYS_INDEXES, INNODB_SYS_COLUMNS, INNODB_SYS_FIELDS, INNODB_SYS_FOREIGN 및 INNODB_SYS_FOREIGN_COLS 입니다.
버퍼 풀 정보 테이블 : 대용량 메모리 또는 고도로 로드된 시스템에서 조정을 위한 버퍼 풀 페이지 정보를 표시합니다. (고객과 커뮤니티 사용자들의 많은 요청했습니다.) 새로운 I_S 테이블은 INNODB_BUFFER_PAGE, INNODB_BUFFER_PAGE_LRU 및 INNODB_BUFFER_POOL_STATS 입니다.
새로운 InnoDB 와 관련된 INFORMATION_SCHEMA 테이블에 대해 자세히 알아보십시오.
해당 설명서를 참조하십시오.
추가적인 최적화 도구 지원
InnoDB는 ICP, MRR, 그리고 앞에서 설명한 파일 정렬 최적화 기능을 지원합니다.
분할 커널 뮤텍스
InnoDB 팀은 바쁜 시스템의 병목 현상을 제거하고 있습니다. 이젠 하나의 뮤택스로 핵심적인 InnoDB 운영에 필요한 동시 접속을 제어하는 대신에, 몇가지 추가된 세밀한 뮤텍스와 RW-Lock(읽기/쓰기 락)으로 사용량이 많은 시스템에서 충돌을 줄일 수 있습니다. 특히, 트랜잭션 제어를 위한 서브 시스템과 MVCC views 및 Locking에 대해서, 이제 별도의 뮤택스 또는 RW-Lock(읽기/쓰기 락)이 제공됩니다.
커널 뮤텍스 분할에 대한 자세한 내용을 알아보십시오.멀티 스레드 정리
InnoDB는 이제 더 효율적으로 여러 테이블에 걸쳐 퍼지 작업을 하는, 다중 퍼지 스레드가 제공됩니다. 원래, 다른 InooDB 운영과 충돌로 연결되는 경우, 퍼지 작업은 InnoDB 마스터 스레드에 의해서 처리 되었습니다. MySQL 5.5버전에서 퍼지는 별도로 하나의 스레드로 변경되었고, MySQL 5.6버전에서는 innodb_purge_threads를 1보다 큰 값으로 설정할 수 있습니다.
다중 퍼지 스레드에 대해 자세히 알아보십시오.별도의 플러시 스레드
InnoDB 테이블 캐시 pruning(가지치기)
엄청난 수의 테이블로 인하여 발생한 시스템의 메모리 부하를 줄이기 위해서, InnoDB는 이제 열린 테이블과 연결된 메모리 공간을 만듭니다. LRU 알고리즘은 가장 오랫동안 접속하지 않은 테이블을 선택합니다. 열린 테이블에 대한 더 많은 메모리를 설정은 --table_definition_cache=# 으로 구성 옵션을 제공합니다.
InnoDB 테이블 캐시에 대한 자세한 내용을 알아보십시오.memcached를 통해 NoSQL 인터페이스
웹 기반 서비스에서 계속 증가하는 성능 요구는 MySQL에 NoSQL 접근 방법을 제공하는 것에 상당한 관심을 생성했습니다. - 간단한 쿼리에 대한 놀라운 빠른 성능을 제공하면서 데이터에 대한 정기적인 SQL 액세스를 보완하기 위해 API를 사용하여, 기존의 관계형 데이터베이스 인프라의 장점을 모두 유지합니다.
memcached API를 사용하여 웹 서비스는 이제 적은 대기 시간과 높은 처리량을 보장하며, SQL로 변환하지 않고 직접 읽기/쓰기 쿼리로 InnoDB 스토리지 엔진에 액세스할 수 있습니다.
SQL 구문 분석과 같은 작업을 제거하고, 서버의 하드웨어 리소스(CPU, 메모리 및 I/O)는 스토리지 엔진 그 자체 내에서 더 많은 쿼리를 서비스하기 위해 최선을 다하고 있습니다.
memcached 사용함으로써, 개발자 및 DBAs가 할 수 있는것 :
- 기존 memcached 클라이언트를 재사용 및 응용프로그램 변경에 대한 필요성을 제거하여 memcached 인프라에 대한 투자를 유지합니다.
- 지원되는 모든 환경에서 최대의 배포 유연성 및 지속적으로 높은 성능을 제공, memcached 클라이언트 라이브러리와 플랫폼의 전체 범위를 액세스합니다.
- 지속적인 통합, 충돌 안전, ACID 따르는 데이터베이스 백엔드 처리과정 제공에 의해서, memcached 기능을 확장합니다.
확장성 향상
데이터가 점점더 커집니다. 그것은 사실입니다. 분할된 테이블(Partitioned tables)은 전체 테이블에 SQL 인터페이스의 편리성을 유지하면서, 분한된 데이터 관리에 도움을 줍니다. 이 새로운 기능은 파티션과 어떤 작업을 보다 빠르고 편리하게 처리합니다.
Partitioning 기능 개선
명시적 파티션 선택
분할된 테이블, MySQL은 큰 데이터 집합에만 해당 부분에 처리를 제한할 수 있습니다. 이젠 각각의 구문안에서 모든 파티션닝 기준을 반복하는 것 보다 어떤 파티션에서 사용되는 쿼리, DML, 또는 데이터 로드 작업을 직접 정의 할 수 있습니다.
SELECT * FROM employees PARTITION (p0, p2);
DELETE FROM employees PARTITION (p0, p1);
UPDATE employees PARTITION (p0) SET store_id = 2 WHERE fname = 'Jill';
SELECT e.id, s.city FROM employees AS e JOIN stores PARTITION (p1) AS s ...;
분할된 테이블에 대한 가져오기 / 내보내기
빠르게 분한된 테이블에 새 데이터 집합을 제공하고, 또는 파티션을 내보내는(export) 것, 또는 파티션의 한 부분을 일반 테이블과 같이 관리하는 것을 ALTER TABLE ... EXCHANGE PARTITION 구문으로 사용할 수 있습니다. 테이블 파티션이나 파티션의 부분파티션을 지정하고, 비 분할 테이블과 호환성이 유지되고, 어떤 비싼 비용 없이 준비된 스왑에서 복사합니다. ALTER TABLE e EXCHANGE PARTITION p0 WITH TABLE e2; 이 작업은 파티션 테이블을 지원하는 스토리지 엔진에서 작동합니다.
파티션을 가져오기 및 내보내기에 대한 자세한 내용을 참조하십시오.리플리케이션 기능 개선
리플리케이션은 데이터 무결성, 가용성, 그리고 빠트릴 수 없는 성능의 개선을 위한 결실입니다.
리플리케이션의 성능 개선
최적화된 행 기반 복제
기본키 또는 명시적 컬럼은 SQL에서 설정하고, INSERT, UPDATE 그리고 DELETE 이벤트에 대해서, 오직 일부분의 "이전"과 "이후" 이미지를 복제함으로써, 바이너리 로그의 디스크 공간이 증가 되는 반면 성능은 향상되고, 네크워크 리소스 및 서버의 메모리 사용량을 줄일 수 있습니다.
멀티 스레드 슬레이브
여러개의 실행 스레드를 사용하여, 슬레이브 서버에 리플리케이션 이벤트를 적용함으로써 리플리케이션 성능이 향상됩니다. 다중 스레드 슬레이브는 데이터베이스 이름을 기반으로 작업자 스레드간에 작업을 분할하고, 업데이트 적용을 순차적으로 적용하는 것보다 병렬로 적용 할 수 있도록 하였습 니다. 그 결과, 리플리케이션 처리량은 증가하고, 대기시간은 감소함으로써, 복제 지연의 위험을 최호화 하고, 슬레이브에서 최신 업데이트를 제공할 수 있습니다. 지금 the snapshot-next-mr-wl5563-labs 버전의 일환으로
Labs.mysql.com에서 다운로드 받아서 멀티 스레드 슬레이브 기능을 사용할 수 있습니다.
데이터 무결성에 리플리케이션 기능 개선
Crash-Safe Slaves
InnoDB와 같은 트랜잭션 스토리지 엔진을 사용할 때, chash-safe 슬레이브를 만들어서 MySQL 리플리에키션을 견고하고, 사용이 용이하게 확장 할 수 있습니다. 스레이브는 DBA 없이 master.info와 relaylog.info 파일에 접근하여 마지막 성공한 반영된 트렌젝션, 또는 트렌젝션을 건너뛰고 리플리케이션을 수동으로 롤백하여 자동으로 장애로부터 복구 할 수 있고, 복제 DML 엡데이트를 다시 시작 할 수 있습니다. 그 결과, 데이터 무결성이 향상되고 DBAs 더 전략적 데이터 관리 활동에 자유롭게 집중 할 수 있습니다.
리플리케이션 확인 값(Checksums)
데이터 손상을 감지하고 오류를 반환, 손상되는 것을 슬레이브 자체적으로 방지함으로써 슬레이브로 복제되는 데이터의 무결성을 보장합니다. 확인 값(Checksums)은 메모리, 디스크 또는 네트워크 실패에 의해서, 또는 데이터베이스 자체에 의해서 발생 할 수 있는 오류를 감시 할 수 있도록 바이너리 및 릴레이 로그 뿐만아니라 개별적인 리플리케이션 이벤트에도 구현됩니다. 확인 값(Checksums) 검사는 방법과 장소가 배포에 최대의 유연성을 제공, 슬레이브 단위 기준으로 구현할 수 있습니다.
시간 지연 리플리케이션
각 슬레이브에 마스터로부터 복제하는 이벤트에 대한 시간지연을 밀리초 단위로 최대 68년까지 정의 할 수 있습니다. 시간 지연 리플리케이션은 마스터에서 만들어진 운영 실수로 발생된 오류에 대한 보호 기능으로, 예를 들어 실수로 테이블을 삭제 하였다면, 슬레이브가 이전 상태로 데이터 베이스를 복원하기 위해서, 마스터로 변경할 때 사용합니다. 시간 지연 리플리케이션는 복제 지연의 인스턴스를 모방하여 테스트 응용 프로그램 동작에 유용하게 사용할 수 있습니다. 시간 지연 리플리케이션은 (SQL_THREAD의 권한을 통하여 실행하는) 슬레이브 단위 수준에서 구현되서, 바로 리플리케이션 이벤트를 적용하는 여러 개의 슬레이브를 구성할 수 있고, 또 다른 슬레이브는 5분 지연 이후에만 적용함으로서 배포 유연성을 제공합니다.
정보 로그 이벤트
슬레이브에 행 기반 이벤트에 관련하여 복제된 이벤트는 바이너리 로그에 원본 쿼리를 작성하여, 행 기반 리플리케이션을 사용할 때, 감사 및 디버깅이 향상됩니다.
Binlog(바이너리로그) 원격 백업
바이너리 로그에서 실시간 백업을 만들 복제 채널을 사용하여 운영 효율성을 향상시킵니다. "raw" 플레그를 추가 하여, 각각의 마스터 서버에 SSH로 DBA없이 접속하여 binlog를 SQL문장으로 번역하여 MySQL 인스턴스에 저장하지않고, 원격 백업 서버에 저장합니다.
Server UUIDs
자동으로 각 서버에 대해 보편적으로 고유 식별자 (UUID)는 MySQL의 기업 모니터 또는 다른 모니터링 도구는 복제 구성에서 마스터와 슬레이브 서버에 대한 정보를 검색할 수 있도록 생성합니다. UUID는 SQL 쿼리 통해 SHOW SLAVE STATUS 명령의 출력에 사용할 수 있습니다. 이 기법은 적은 데이터베이스 연결이 필요하며 원격으로 모니터링하거나 가상 IP 주소를 사용하는 서버와 더 나은 사용할 수 있습니다. 이 기능은 자동으로 발견보다 안정적이고 단순화 시스템 관리를하고, 크고 높은 동적 복제 환경에서 특히 유용합니다.
기기장치 및 PERFORMANCE_SCHEMA를 통한 진단 개선 사항
MySQL 5.6 성능 모니터링 및 튜닝을 위한 PERFORMANCE_SCHEMA 기능을 크게 향상시킵니다. performance_schema 테이블에 정보는 다양한 시스템 구성과 "가장 심한" 부하 작업과 관련 파일에 대한 문제 추적과 소스 코드의 라인에서 진짜로 무슨일이 일어나고 있는지를 알 수 있는 전반적인 데이터 베이스 성능에 하위 레벨 항목 인수를 다양한 방법으로 볼 수 있습니다.
Performance Schema에 대한 자세한 내용을 알아보십시오.오버헤드 감소
The performance_schema 코드는 해당 기능이 활성화된 상태에서 오버헤드의 발생을 줄이기 위해 5.6버전에서 추가로 조정되었습니다.
테이블 I/O 및 계측
setup_object 테이블은 DBA로 하여금, MySQL 데이터베이스 서버의 이해, 분석, 그리고 응용프로그램이 테이블에 엑서스하고 그와 관련된 I/O 부하의 발생을 조정하는 것을 가능하게 합니다.
테이블 Lock 계측
setup_object 테이블은 DBA로 하여금, "사용이 많은 테이블"을 식별하고, 응용 프로그램의 데이터 엑서스 패턴에 의해서 다른 오브젝트와 관련된 병목현상이 발생 하는 것을 감지 할 수 있게 합니다.
세션/사용자 별 계측
setup_object 테이블은 DBA로 하여금, 선택한 특정 최종 사용자 또는 응용프로그램의 커넥션을 계측하여, 특정 사용자 또는 응용프로그램으로 부터 생성된 부하를 모니터링 할 수 있게 합니다.
이것은 모니터링 데이터 수집의 범위를 좁히는 역활을 합니다:
- a) 스레드 또는 세션에 의한 것,
- b) 특정 사용자 계정에서 발행하는 연결에 의한 것,
- c) 주어진 시스템(장비)에서 발생하는 연결에 의한 것,
- d) 주어진 시스템(장비)에서 특정 사용자 계정에서 발생하는 연결에 의한 것,
계측된 연결의 수치가 감소하면, 생산 장비의 런타임 오버헤드도 감소합니다.
글로벌 성능 측정 항목 요약
글로벌 집계 데이터는 스레드와 객체와 계측 지점으로 부터 PERFORMANCE_SCHEMA로 수집됩니다. DBA가 모니터링 스크립트를 작성하거나 응용프로그램을 만드는 것이 가능합니다
테이블/인덱스 I/O 요약
setup_object 테이블은 PERFORMANCE_SCHEMA와 인덱스와 테이블로 부터 테이블 I/O 데이터를 수집하여 집계합니다. 응용프로그램에 의해 어떤 테이블 또는 인덱스에서 가장 "많이" 사용되는지, 응용프로그램에서 데이터를 액서스 하는 패턴을 파악하는데 도움이 되는 집계 수치가 표시됩니다.
테이블 락 대기 요약
데이블 락 데이터 수집은 PERFORMANCE_SCHEMA의 테이블로 집계 됩니다. 응용프로그램에 의해서 어떤 테이블이 종종 락이 발생하는지, 테이블 락으로 인하여 응용프로그램이 병목현상이 발생하는 현상 파악에 도움이 되는 집계를 보여줍니다.
Statement-Level 계측
DBA가 최종 사용자 세션이나 글로벌 집계를 통해서, 정책 실행을 모니터링 하고, 정책별 통계를 수집하고, 정책 실행을 분석하는 것이 가능하다 응용프로그램에 의해서 생성되는 어떤 정책, 실행시간/횟수 그리고 접근 경로를 측정합니다. 통계 수치는 데이터 볼륨에 대해서 WHERE 조항의 선택도와 인덱스의 사용 패턴에 통찰력을 제공하는 보고서입니다.
Labs.mysql.com에서 사용할 수 있습니다.
호스트 캐시의 내용보기 - 연결 오류의 중앙 집중식 로그
(고객들과 커뮤니티 사용자들이 많은 요청이 있었습니다. 커뮤니티 코드 기여를 통해서 제공합니다.) 연결과 관련된 오류의 중앙 집중식 로그을 제공합니다. MySQL 내부 호스트 캐시는 관계형 테이블에 SQL이 엑서스하는 것을 계측하고 노출되었고, 정확한 근본 원인(SSL, DNS, 인증 플러그인, ...)에 대한 자세한 내용과 함께 연결 오류의 중앙로그를 제공합니다. 이것은 DBA가 쉽게 수많은 사용자와 이기종 응용프로그램을 포함한 대규모 배포 문제를 해결하는 것을 가능하게 합니다.
Labs.mysql.com에서 사용할 수 있습니다.
