Multi Version Concurrency Control

[hyeonic]

주제

Multi Version Concurrency Control에 대해 학습한 뒤 이해한 내용을 공유한다.

선정 이유

일관된 읽기를 위해 MySQL 서버의 내부는 어떻게 동작 하는지에 대한 궁금증으로 시작하였다.

해당 텍스트

MVCC의 가장 큰 목적은 잠금을 사용하지 않는 일관된 읽기를 제공한다. InnoDB는 이것을 언두 로그(Undo log)를 통해 제공한다.

아래와 같이 한 건의 레코드를 INSERT한다고 가정한다.

mysql> INSERT INTO customer (id, password, phone_number) VALUES ('admin', '1q2w3e4r!', '000-0000-0000');
mysql> COMMIT;

INSERT문이 실행되면 DB의 상태는 아래와 같아진다.

그 다음 UPDATE를 진행한 뒤 상태를 살펴본다.

mysql> UPDATE customer SET password = 'abc123!' WHERE id = 'admin';

password 컬럼의 변경 전 값만 undo log에 복사되며 UPDATE가 실행되면 COMMIT의 유무와 상관없이 InnoDB Buffer Pool은 새로운 값으로 변경한다. 또한 Disk의 데이터는 새로운 값으로 업데이트 되는 것을 보장하지 않는다.

InnoDB가 ACID를 보장하기 때문에 일반적으로 같은 상태라고 봐도 무방하다.

이제 위와 같은 데이터베이스 상태에서 해당 레코드를 조회한다고 가정한다.

mysql> SELECT * FROM customer WHERE id = 'admin';

이것은 MySQL 서버의 시스템 변수에 설정된 격리 수준에 따라 달라진다.

• READ_UNCOMMITTED: InnoDB Buffer Pool이나 데이터 파일로부터 변경되지 않은 데이터를 읽어 반환한다. 데이터가 커밋됐든 안됐든 변경된 상태의 데이터를 반환한다.
• READ_COMMIT 혹은 그 이상: 아직 커밋되지 않았기 때문에 변경되기 이전의 내용을 보관하는 Undo log의 데이터를 반환한다.

이처럼 2개의 버전이 관리되며 필요에 따라 어떠한 데이터가 반환될지에 대해 알 수 있다. 그렇다면 만약 트랜잭션이 길어져 Undo에서 관리하는 데이터가 삭제 되지 못하고 공간을 차지하게 되면 어떻게 될까?

• COMMIT을 실행하게 되면 InnoDB는 더 이상 변경 작업을 진행하지 않고 현재 상태를 영구적인 데이터로 만들어 버린다.
• ROLLBACK을 실행하게 되면 InnoDB는 Undo log의 백업된 데이터를 InnoDB Buffer Pool로 복구와 동시에 삭제한다.

하지만 COMMIT을 진행한다고 백업 데이터가 바로 삭제 되는 것은 아니다. Undo log을 필요로 하는 트랜잭션이 없을 때 삭제된다.

관련 페이지

100 ~ 103p