InnoDB와 ACID 모델

데이터베이스가 "믿고 써도 되는 저장소"가 되려면, 크래시가 나든 하드웨어가 고장 나든 데이터가 깨지거나 결과가 왜곡되지 않아야 해요. 이 신뢰성의 기준을 정리한 것이 ACID 모델이고, MySQL의 기본 스토리지 엔진인 InnoDB는 이 원칙을 아주 밀접하게 따르도록 설계됐어요. ACID를 지키는 기능에 기대면 일관성 검사와 크래시 복구 장치를 직접 다시 만들 필요가 없죠.

출처: InnoDB and the ACID Model

ACID는 무엇의 약자인가요

ACID는 네 가지 속성의 머리글자예요.

A (Atomicity, 원자성) — 트랜잭션의 모든 작업이 전부 반영되거나 전부 반영되지 않아요.
C (Consistency, 일관성) — 데이터가 항상 정합 상태를 유지해요.
I (Isolation, 격리성) — 동시에 실행되는 트랜잭션이 서로의 중간 상태를 보지 못해요.
D (Durability, 지속성) — 커밋된 데이터는 시스템이 죽어도 사라지지 않아요.

InnoDB가 각 속성을 어떻게 지키나요

원자성은 주로 InnoDB의 트랜잭션 개념과 연결돼요. 관련 설정으로는 autocommit, COMMIT 문, ROLLBACK 문이 있어요. 하나의 트랜잭션 도중 문제가 생기면 ROLLBACK으로 원자성을 회복하죠.

일관성은 InnoDB가 크래시로부터 데이터를 보호하는 내부 처리와 맞닿아요. 대표적으로 더블라이트 버퍼(doublewrite buffer) 와 크래시 복구(crash recovery) 메커니즘이 있어요. 이중 쓰기로 페이지가 반쯤만 기록되는 사고를 막고, 복구 과정으로 일관된 상태를 되찾습니다.

격리성은 각 트랜잭션에 적용되는 트랜잭션 격리 수준(isolation level) 과 관련 있어요. SET TRANSACTION 문으로 격리 수준을 정하고, 그 아래에서 InnoDB의 잠금(locking) 메커니즘이 동시성을 조율해요.

지속성은 InnoDB의 소프트웨어 기능과 하드웨어 구성이 함께 결정해요. CPU·네트워크·스토리지 장치마다 특성이 달라서 가장 구체적인 지침을 주기 어려운 부분이고, 관련 요소들이 많죠.

지속성을 좌우하는 설정들

지속성에 영향을 주는 대표 변수들을 꼽으면 이래요.

innodb_flush_log_at_trx_commit — 커밋 시점에 리두 로그를 얼마나 강하게 디스크에 내리는지
sync_binlog — 바이너리 로그를 디스크에 동기화하는 주기
innodb_file_per_table — 테이블별 테이블스페이스 사용 여부
디스크·SSD·RAID 등 스토리지 장치의 쓰기 버퍼
장치의 배터리 백업 캐시 유무

ACID를 포기하고 성능을 택할 수도 있어요

반드시 ACID를 끝까지 지켜야 하는 건 아니에요. 추가 안전 장치가 있거나, 아주 일부 데이터 손실을 견딜 수 있는 애플리케이션이라면 MySQL 설정을 조정해 ACID 신뢰성 일부를 성능·처리량과 맞바꿀 수 있어요. 정확히 어디까지 타협할지는 서비스의 요구사항에 따라 판단하면 됩니다.

더 알아보기

복제 — ACID 트랜잭션을 여러 서버로 전파하는 구조
인덱스로 쿼리 성능 올리기 — InnoDB 테이블의 검색을 빠르게 만드는 방법
파티셔닝 개요 — InnoDB 테이블을 파티션 단위로 나누는 기법
MySQL 최적화 — InnoDB 변수·버퍼 전반을 튜닝하는 원리