MVCC in Mysql(with 트랜잭션 격리수준)

이번 글에서는 MVCC의 개념과 어떻게 동작하는 것인지, 그리고 트랜잭션 격리수준을 구현할 때 이를 어떻게 활용하고 있는지에 대해 가장 많이 쓰이는 데이터베이스 중 하나인 Mysql을 통해 정리하고자 한다.

들어가기 앞서

이번 글에서 중점적으로 다루게 될 MVCC 주제로 들어가기 전에, 먼저 트랜잭션 격리수준에 대한 배경지식이 필요하다.

트랜잭션 격리수준이란, 데이터베이스 내에서 트랜잭션들이 동시다발적으로 실행될 때 해당 트랜잭션의 조회 결과가 다른 트랜잭션에 얼마나 영향을 받게할지에 대한 수준을 의미한다.

READ UNCOMMITED, READ COMMITED, REPEATABLE READ, SERIALIZABLE의 총 4가지 수준으로 구성되고 언급한 순서의 역순으로 격리 수준이 높아진다. (READ UNCOMMITED -> ... -> SERIALIZABLE)

각 격리수준에 대한 정보와 그에 연관된 문제들은 예전에 작성해둔 포스트가 있기 때문에 링크로 대체하겠다.

트랜잭션 격리 수준

 

MVCC

개념

MVCC란 Multi Version Concurrency Control의 약자로, 직역하자면 다중 버전 동시성 제어 쯤이 된다.

다중 버전이라는 말에는 그 대상이 되는 주어가 빠져있는데, 여기에서 다중 버전을 통해 관리되는 주체는 바로 DB 레코드이다.

즉, DB는 하나의 레코드에 대해 내부적으로 여러 버전을 관리하고 있다는 것을 알 수 있다.

사용 이유

그렇다면 DB는 왜 각 레코드에 대해 여러 버전을 관리하는 것일까?

Mysql 공식문서에 따르면 그 이유는 아래와 같다.

Mysql InnoDB는 동시성, 롤백과 같은 트랜잭션 기능들을 지원하기 위해 "멀티 버저닝"을 지원합니다.

트랜잭션이 종료되는 방식은 크게 커밋과 롤백이 존재하는데, 이 중 롤백을 위해서는 특정 레코드가 트랜잭션에 의해 수정되기 전 데이터를 알고있어야 한다.  따라서 특정 레코드의 버전을 관리하는 이유로는 타당하다. (이는 사실 언두 로그에 대한 설명이기도 하다.)

그렇다면 동시성은 어떨까? 여기에서는 단순히 '동시성'으로 언급되어 있지만, 더 구체적으로는 여러 트랜잭션이 동시에 동작하는 상황에서도 데이터의 일관성을 유지하는 것을 의미한다고 보면 된다. 이를 구현하는 가장 단순한 방법은 바로 락을 사용하는 것이지만, 매번 락을 활용하게 될 경우 DB의 성능이 결코 좋을 수 없다. 이를 위해 DB가 레코드 별로 여러 버전을 관리하고, 각 트랜잭션에서 조회를 수행할 때 적절한 버전의 레코드를 읽게만 할 수 있다면 락을 활용하지 않으면서도 데이터 조회의 일관성을 유지할 수 있다.

즉, MVCC는 이 버전들을 활용하여 동시다발적으로 실행되는 트랜잭션에서도 조회를 위한 락을 획득하지 않는 방향으로 트랜잭션 격리수준을 구현한다고 볼 수 있다.

동작 방식

MVCC는 DB의 언두 로그와 트랜잭션 ID(trx_id)를 통해 구현된다.

여기서 트랜잭션 ID란 Mysql이 각 트랜잭션에 부여하는 계속해서 증가하는 값을 의미하는데, Mysql은 해당 필드를 내부적으로 유지하되 외부로 노출하지는 않는 방식으로 이를 관리한다.

MVCC의 동작 방식을 이해하기 위해 특정 레코드에 접근하여 칼럼 값을 수정(value: 10 -> 20)하는 트랜잭션(A)과 이를 조회하는 트랜잭션(B)이 동시에 실행되는 상황을 생각해보자.

이 때 각 트랜잭션의 작업 순서는 아래와 같다고 가정하자.

1. 대상 레코드 존재 (trx_id: 5, value: 10)
2. A 트랜잭션 시작 (trx_id: 10)
3. A 트랜잭션 작업 수행(value: 10 -> 20)
4. B 트랜잭션 시작 (trx_id: 11)
5. B 트랜잭션 작업 수행(레코드 조회)
6. B 트랜잭션 커밋
7. A 트랜잭션 커밋

위 상황에서 2번 작업이 수행되는 직후 버퍼 캐시의 데이터는 20으로 수정되고 해당 레코드의 trx_id 값은 10이 된다. 그리고 기존 값은 언두 로그에 저장된다. (value: 10, trx_id: 5)

그 뒤엔 B 트랜잭션이 시작되고 해당 레코드를 읽게 된다.

이 때 트랜잭션 격리 수준에 따라 동작이 달라지게 되는데, READ COMMITED와 REPEATABLE READ의 경우엔 언두 로그를 활용하여 커밋된 데이터 만을 읽어내는 반면 READ UNCOMMITED는 아직 커밋되지 않은 레코드를 곧바로 읽고, SERIALIZABLE은 언두 로그 대신 락을 활용한다.

즉 MVCC 방식은 READ COMMITED, REPEATABLE READ에만 해당한다.

READ COMMITED vs REPEATABLE READ

다만, 두 격리 수준이 MVCC를 활용하는 방법에는 엄연한 차이가 존재한다.

우선 REPEATABLE READ의 경우에는, 버퍼 캐시의 레코드와 언두 로그의 레코드 중 자신의 트랜잭션 ID 값보다 작은 레코드 중 가장 큰 데이터를 읽는다. 트랜잭션 ID는 하나의 트랜잭션 안에서는 변경되지 않기 때문에, 해당 격리 수준에서는 일정한 스냅샷을 획득할 수 있다.

READ COMMITED의 경우엔 조금 다르다. 버퍼 캐시의 레코드와 언두 로그의 레코드 중 가장 최근에 커밋된 데이터를 읽는다. 이로 인해 해당 격리 수준에서는 SELECT를 여러번 수행해도, 조회 사이사이에 다른 트랜잭션의 UPDATE 커밋이 있다면 매번 읽게 되는 데이터가 달라지는 것이다. (이를 NON-REPEATABLE READ 문제라고 부른다.)

 

참조

MySQL :: MySQL 8.0 Reference Manual :: 17.3 InnoDB Multi-Versioning

 

트랜잭션 격리 수준