문서의 이전 판입니다!

MySQL 5.5 New Features

MySQL 5.5 특징

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

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

윈도우 환경에서 속도와 가용 규모가 향상되었습니다.
벤치마크 테스트 결과에 따르면 MySQL 5.5 RC는 MySQL 5.1과 비교해 윈도상에서 읽고 쓰는 작업 성능은 1,500% 향상했고 읽기 작업은 500%까지 강화되었다고 합니다.
리눅스 기반의 경우 읽고 쓰는 능력은 360%, 읽기만 하는 작업은 200% 강화됐다고 오라클은 이야기하고 있습니다.

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