MySQL 5.5의 특징 정리

점심시간을 빌어 은경님께서 올려주신 URL(http://dev.mysql.com/tech-resources/articles/introduction-to-mysql-55.html)을 기준으로하여 MySQL 5.5버전의 새로운 특징들을 대강 정리해봤습니다. '점심 시간 내에 정리할 것'이라는 목표를 두고 정리해서 내용은 조금 빈약합니다만 으흐흐.. 이건 참조만 하시고, 추가적으로 사이트 들어가서 읽어보시면 될 것 같아요~ 해석이 틀릴 수도 있으니깐요~~
[그리고 결국 점심시간내에 다 못하고 20분이나 지났군요.. ㅠ_ㅠ InnoDB의 새로운 점은 다음에 올리도록하겠습니다ㅠ_ㅠ;;]

---------
  목차
---------

 MySQL 5.5의 새로운 점
  - 성능과 확장성의 증대
   * InnoDB가 기본 스토리지 엔진이 됨
   * 트랜잭션 중의 메타데이타 락킹 메커니즘이 발전 됨
   * 윈도우 플랫폼에서의 성능이 향상 됨
  - 가용성의 증대
   * 반만 싱크 맞추는 방식의 리플리케이션
   * 리플리케이션 하트비트
  - 편의성의 증대
   * SIGNAL/RESIGNAL
   * 파티션 옵션이 다양해짐
   * 퍼포먼스 스키마
 InnoDB의 새로운 점
  - 성능 향상
   * 복구 성능이 향상됨
   * 하나의 인스턴스에 여러개의 버퍼풀을 잡아줄 수 있음
   * 롤백 세그먼트를 어려개 사용할 수 있음
   * 리눅스 플랫폼에서의 어싱크I/O지원
   * 버퍼링을 변경하는 방식이 확장됨
  - 확장성 증대
   * 로그 시스 뮤텍스의 발전
   * 플러쉬 리스트 뮤텍스의 분리
   * 퍼지 스케쥴링의 향상
  - 더 나아진 도구와 분석법
   * 퍼포먼스 스키마에서의 InnoDB 통계정보

--------------------------------------------------------

MySQL 5.5의 새로운 점

- 성능과 확장성의 증대

* InnoDB가 기본 스토리지 엔진이 됨
 MySQL 5.5부터는 InnoDB가 기본 스토리지 엔진으로 체택되었습니다. 그동안은 MyISAM이 기본 스토리지 엔진으로 사용되었기에, InnoDB의 강점인 ACID-트랜잭션, 외래키 지원, 크래쉬 리커버리등의 기능을 바로 활용하기에는 약간의 불편함이 있었습니다. 하지만 이제는 기본 스토리지 엔진이 InnoDB로 변경되어 새로운 사용자도 쉽게 InnoDB의 특징들을 경험할 수 있게 되었습니다.
 더불어 MySQL 5.5에서 체택된 InnoDB 스토리지 엔진의 버전은 1.1로 향상되었습니다. InnoDB 1.1에서의 새로운 특징은 다음 글에 정리하도록 하겠습니다.

* 트랜잭션 중의 메타데이타 락킹 메커니즘이 발전 됨
 만약 어떤 테이블이 트랜잭션에 참조되고 있다면, 트랜잭션이 종료되기 전까지는 해당 테이블에 대한 DDL, DROP TABLE, ALTER TABLE등의 작업을 할 수가 없게 되었습니다. 과거에는 전체 트랜잭션이 아닌, SQL구문 하나가 종료되는 순간에 메타데이타 락이 해제되었었습니다.
 예를 들면, 하나의 세션에서 트랜잭션이 진행 중이고, 그 와중에 잘못된 SQL구문을 입력했습니다. 이 때에 다른 세션에서 DDL문을 입력하였다면, 예전 버전에서는 트랜잭션 중에도 DDL문이 먹혔기에, 테이블 구조가 변경되며 잘못된 SQL 구문이 적용되게 될 수도 있었습니다. 하지만 이제는 트랜잭션 도중에는 메타데이타에 대한 락을 지속적으로 보유하고 있으므로 DDL문이 먹히지 않게 되었습니다.

* 윈도우 플랫폼에서의 성능과 규모가 향상 됨
 윈도우 환경에서 속도와 가용 규모가 향상되었습니다. 
   한 신문기사의 내용 발췌입니다.
벤치마크 테스트 결과에 따르면 마이SQL 5.5 RC는 마이SQL 5.1과 비교해 윈도상에서 읽고 쓰는 작업 성능은 1천500% 향상했고 읽기 작업은 500%까지 강화됐다. 리눅스 기반의 경우 읽고 쓰는 능력은 360%, 읽기만 하는 작업은 200% 강화됐다고 오라클은 전했다
  좌우간 여기선 윈도우 안쓰니 패쓰...


- 가용성의 증대

* 반만 싱크 맞추는(semi-synchronous) 방식의 리플리케이션
 우선 전체를 싱크맞추는 경우와, 전혀 싱크를 맞추는 않는 방식을 이야기 하겠습니다.
 만약 전체 싱크를 맞추는 (fully-synchronous) 리플리케이션 구성이 되어있다면, 마스터에 연결된 세션이 커밋을 날렸을 때에, 이에 연결되어있는 모든 슬레이브에서도 커밋을 적용 완료 해야지만 트랜잭션 완료 메세지를 세션에 반납하는 방식입니다. 따라서 트랜잭션 시간이 길어지게 되는 문제가 있었습니다.
 전혀 싱크를 맞추지 않는 (asynchronous) 방식으로 리플리케이션이 구성되어 있다면, 슬레이브에 트랜잭션 내용을 적용 완료했는지의 여부와 상관없이, 마스터에서는 트랜잭션을 완료하고, 계속적으로 새로운 트랜잭션이 진행됩니다. 이 경우에는 트랜잭션 완료시간은 빨리지겠지만, 가용성에서는 문제가 있을 것입니다.
 이번에 새로이 등장한 반만 싱크를 맞추는 개념(semi-synchronous)은, 이 두 구성의 절충점 정도라 보시면 됩니다. 모든 리플리케이션 슬레이브에 대한 싱크가 맞추어지기를 기다리는 것이 아니라, 최소, 단 하나의 슬레이브에서만 싱크가 맞추어 졌다면 트랜잭션을 완료시키는 방식입니다.

* 리플리케이션 하트비트
 리플리케이션 구성의 노드 가용성을 체크하기 위해서 하트비트 메커니즘이 사용되어 있습니다. 여기에 하트비트 체크 시간을 변경할 수 있게 되었습니다.

  STOP SLAVE;
  CHANGE MASTER TO master_heartbeat_period= milliseconds;
  START SLAVE;
  SHOW STATUS like 'slave_heartbeat period'
  SHOW STATUS like 'slave_received_heartbeats'

 

- 편의성의 증대
* SIGNAL/RESIGNAL
 SIGNAL/RESIGNAL명령은 스토어드-프로시저, 사용자 정의함수, 트리거 등을 작성할때에 예외처리를 어떻게 할지에 대한 제어를 가능하게 끔 해줍니다.
 SIGNAL명령은 자바와 같은 다른 언어에서의 THROW, RAISE 구분과 비슷하게 활용할 수 있습니다. 이를 통해 에러 구문들을 말끔히 정리하는 것이 가능할 것입니다.
 RESIGNAL명령을 통해서는 에러를 통과시키거나, 기본 에러 정보를 수정할 수 있게끔 해줍니다.

* 파티션 옵션이 다양해짐
 컬럼 레벨의 파티셔닝이 가능하게 되었습니다. RANGE COLUMNS, LIST COLUMNS옵션을 CREATE TABLE명령문에 끼워 넣음으로써 설정이 가능합니다.
 RANGE와 LIST파티셔닝의 차이점은 오라클에서와 같습니다.
 자세한 구현법은 http://dev.mysql.com/doc/refman/5.5/en/partitioning-columns.html 페이지에서 확인가능합니다.

* 퍼포먼스 스키마
 퍼포먼스 관리를 위한 performance_schema라는 이름의 스키마를 추가적으로 사용할 수 있습니다. 이 스키마에는 MySQL 내부적인 디테일한 성능 정보를 담고있는 테이블들이 저장됩니다. 현재 시점에서의 성능 뿐 아니라, 과거의 정보들까지도 기록해 둘 수 있습니다.
 퍼포먼스 스키마에는 굉장히 다양한 내용이 들어 갈 수 있으므로, 마찬가지로 직접 해당 사이트를 (http://dev.mysql.com/doc/refman/5.5/en/performance-schema.html) 살펴보시는 것이 도움될 것 같습니다.