[Database] MVCC(다중 버전 동시성 제어)

📂 데이터베이스 MVCC 실전: Lost Update와 Write Skew 해결

목차

• 1. MVCC(다중 버전 동시성 제어)란?
• 2. 격리 수준(Isolation Level)별 동작 차이
• 3. Lost Update 해결: Locking Read (FOR UPDATE)
• 4. Write Skew(쓰기 왜곡) 현상과 해결
• 5. MySQL vs PostgreSQL: 실전 동작 및 Serializable 비교
• 6. Q&A 및 최종 요약

1. MVCC란 무엇인가?

다중 버전 동시성 제어(Multi-Version Concurrency Control)는 데이터 접근 시 해당 시점의 스냅샷(버전)을 보여주어 동시성을 높이는 기법입니다. 핵심 원칙은 "읽기는 쓰기를 막지 않고, 쓰기는 읽기를 막지 않는다"는 것입니다.

작동 방식: 데이터를 업데이트할 때 원본을 덮어쓰지 않고, 이전 버전을 별도 영역(MySQL의 Undo Log 등)에 보관합니다. 변경 시마다 System ID나 Transaction ID를 저장해 현재 트랜잭션이 읽을 수 있는 적절한 버전인지 판별합니다.

---

2. 격리 수준(Isolation Level)에 따른 동작

격리 수준	MVCC 동작 방식
Read Uncommitted	MVCC를 거의 사용하지 않으며 Dirty Read 발생
Read Committed	쿼리가 시작된 시점의 스냅샷을 읽음 (SELECT마다 갱신)
Repeatable Read	트랜잭션이 시작된 시점의 스냅샷을 끝까지 유지
Serializable	가장 엄격함. 주로 Locking이나 SSI를 통해 처리

Consistent Read: 특정 시점의 커밋된 데이터만 읽는 기능입니다. MySQL은 이를 Consistent Non-locking Read라 부르며, 롤백 시 연쇄 복구 불능을 막기 위해 커밋 시점에만 Write Lock을 해제하는 회복 가능성(Recoverability)을 보장합니다.

---

3. Lost Update 해결: Locking Read

Repeatable Read에서도 MVCC만으로는 Lost Update(업데이트 유실)를 막지 못할 때가 있습니다. 이를 위해 개발자가 직접 락을 거는 Locking Read를 사용합니다.

배타적 락 (SELECT ... FOR UPDATE): X-Lock 획득. 타 트랜잭션의 읽기/쓰기 모두 차단.

공유 락 (SELECT ... FOR SHARE): S-Lock 획득. 타 트랜잭션의 읽기는 허용하나 쓰기 차단.

※ MySQL 특징: Locking Read 시 스냅샷이 아닌 가장 최근에 커밋된 데이터(Latest Committed Data)를 읽어옵니다.

---

4. Write Skew(쓰기 왜곡) 현상과 해결

두 트랜잭션이 서로 다른 데이터를 수정하지만 결과적으로 비즈니스 로직(예: 계좌 합계 0 이상 유지)이 깨지는 현상입니다. 각자 자신의 스냅샷만 보고 판단하기 때문에 발생합니다.

 

해결 방법
1. Locking Read 사용: 조회 시점에 락을 걸어 트랜잭션을 직렬화합니다.
2. 격리 수준 상향: Serializable 레벨을 사용해 이상 현상을 자동 감지하게 합니다.

---

5. MySQL vs PostgreSQL 동작 차이

비교 항목	MySQL (InnoDB)	PostgreSQL
Locking Read 시점	락 해제 시까지 대기 후 최신 커밋 데이터 읽어 진행	락 대기 후 행이 먼저 수정/커밋되었다면 에러(Rollback) 발생
충돌 처리	선행 락 우선, 후행은 최신 값을 보고 판단	First-updater-wins: 먼저 시도한 쪽 성공, 나머지는 실패
Serializable 구현	SELECT를 FOR SHARE로 자동 변환 (락 기반)	SSI(의존성 그래프 추적) 방식 사용 (MVCC 기반)

---

6. Q&A 및 요약

Q: 특정 트랜잭션에만 Read Committed 설정이 가능한가요?
가능합니다. 다만 리포트 출력처럼 속도가 중요한 특수 상황에서만 권장됩니다. 시스템 전체의 정합성이 깨질 위험이 크기 때문입니다.

 

최종 요약

• MVCC는 성능이 좋지만 Repeatable Read에서도 Lost Update/Write Skew는 발생한다.
• 결제나 재고 관리 로직은 반드시 FOR UPDATE를 활용하거나 DB별 Serializable 특성을 숙지해야 한다.
• 사용 중인 RDBMS의 공식 문서를 통해 세부 구현을 확인하는 것이 안정적 설계의 핵심이다.