InnoDB 스토리지 엔진

주요 특징

프라이머리 키에 의한 클러스터링

• 모든 테이블은 프라이머리 키(PK)를 기준으로 클러스터링되어 저장된다.

• 모든 세컨더리 인덱스는 프라이머리 키 값을 논리적인 주소로 사용한다.

외래 키 지원

• 여러 테이블에 대한 데이터 무결성을 보장하기 위해 외래 키를 스토리지 엔진 레벨에서 지원한다.

• 부모 테이블과 자식 테이블의 외래 키 칼럼에 대해 모두 인덱스 생성이 필요하고, 외래 키를 포함한 데이터를 추가할 때, 실제 연관 데이터가 존재하는지 확인해야 하므로 락이 여러 테이블에 거쳐 점유되다보니 데드락이 발생할 위험도 있다.

MVCC(Multi Version Concurrency Control)

• 레코드 레벨의 트랜잭션을 지원하기 위해 사용하는 방식으로, 락을 사용하지 않는 일관된 읽기 기능을 제공한다.

• 언두 로그(Undo Log)를 사용해 락 없이도 트랜잭션에서 변경(커밋)되기 전의 데이터를 읽는 기능을 제공한다.

• 값이 변경되었지만 커밋되기 전인 상태에서 InnoDB 버퍼 풀의 데이터는 갱신되어 있지만, 기존의 값은 언두 로그에 저장되어 있다.

• 롤백을 실행하면 InnoDB의 언두 영역에 있는 데이터를 InnoDB 버퍼 풀로 복구한다. 이후 해당 언두 영역을 필요로 하는 트랜잭션이 없으면 백업 데이터는 삭제된다.

• 트랜잭션이 길어질수록 관리해야 하는 예전 버전의 데이터가 많아져 언두 영역의 데이터가 많아질 수 있다.

자동 데드락 감지

• 락이 교착 상태에 빠지지 않았는지 락 대기 목록을 그래프(Wait-for List) 형태로 관리한다.

• 데드락 감지 스레드가 주기적으로 교착 상태에 빠진 트랜잭션을 강제 종료시킨다.

• 언두 로그 레코드를 적게 가진 트랜잭션이 먼저 롤백의 대상이 된다.

• 스레드가 락 목록을 조회할 때 변경되지 않도록 자체 락을 걸기 때문에, 이 스레드가 느려지면 서비스 쿼리를 처리중인 스레드가 대기할 수 있다. 특히 동시에 많은 트랜잭션이 실행되는 경우에는 성능 저하가 심해질 수 있다.

• 데드락 감지 스레드를 비활성화하고, 데드락 발생 시 일정 시간이 지나면 자동으로 요청이 실패하게 설정할 수도 있다.

자동화된 장애 복구

• MySQL 서버가 시작될 때, 완료되지 못한 트랜잭션이나 디스크에 일부만 기록된 데이터 페이지에 대해 복구 작업이 자동으로 진행된다.

• 자동으로 복구될 수 없는 파일 손상이 있다면 MySQL 서버는 종료된다. 이 경우 innodb_force_recovery 설정값을 조절하며 재시작해봐야 한다. 서버가 시작되었다면 데이터를 덤프하여 새로운 서버로 구축하면 된다.

버퍼 풀

• 디스크의 데이터 파일이나 인덱스 정보를 메모리에 캐싱하는 공간이다.

• 변경된 데이터를 모아서 처리하면 랜덤한 디스크 작업을 줄일 수 있다.

• 버퍼 풀 크기를 결정해야 하는 경우 처음에는 50% 정도만 버퍼 풀 크기로 잡고, 다른 스레드나 프로세스, 운영 체제의 사용량이 적다면 점차 늘리는 것이 좋다.

• 버퍼 풀을 여러 개의 인스턴스로 나누어 관리할 수도 있다.