트랜잭션이 지켜야 할 네 가지 성질. 각각을 무엇으로 구현하는지까지 알아야 한다.
| 뜻 | 구현 수단 | |
|---|---|---|
| Atomicity(원자성) | 전부 반영되거나 전부 취소 | undo 로그 |
| Consistency(일관성) | 제약을 깨지 않는 상태로만 이동 | 무결성 제약·트리거 |
| Isolation(격리성) | 동시 트랜잭션이 서로 방해하지 않음 | 락 · MVCC |
| Durability(지속성) | 커밋한 것은 장애 후에도 남음 | redo 로그(WAL) |
원자성 — undo 로그
변경 전 값을 따로 기록해 둔다.
- UPDATE account SET balance = 500 WHERE id = 1; -- 원래 1000
- undo 로그: "id=1의 balance는 원래 1000이었다"
롤백하면 undo 로그를 거꾸로 적용해 되돌린다
지속성 — WAL(Write-Ahead Logging)
데이터 파일보다 로그를 먼저 쓴다. 이것이 핵심이다.
- ① 변경 내용을 redo 로그에 기록 + 디스크에 fsync ← 여기까지 하면 커밋 성공
- ② 실제 데이터 페이지는 나중에 천천히 디스크로 ← 버퍼 풀에서 지연 반영
왜 로그를 먼저 쓰나 — 데이터 페이지는 여기저기 흩어져 있어 랜덤 쓰기지만, 로그는 파일 끝에 덧붙이는 순차 쓰기라 훨씬 빠르다. 커밋 응답을 빨리 주면서도 안전성을 확보하는 방법이다.
장애가 나면 재시작할 때 로그를 읽어
- 커밋됐지만 데이터 파일에 없는 것 → redo(다시 적용)
- 커밋 안 됐는데 반영된 것 → undo(되돌림)
격리성만 타협된다
실무에서 SERIALIZABLE은 성능 때문에 거의 안 쓴다. READ COMMITTED나 REPEATABLE READ를 쓰고 일부 이상현상을 감수한다.
ACID 중 A·C·D는 켜고 끄는 것이 아니지만, I는 단계를 고르는 것이다. 이 비대칭을 아는 것이 중요하다.
면접 꼬리질문
"ACID의 C와 CAP의 C는 같은가?" → 다르다.
| 뜻 | |
|---|---|
| ACID의 Consistency | 제약조건을 위반하지 않는 올바른 상태 |
| CAP의 Consistency | 모든 노드가 같은 값을 본다(선형화 가능성) |
이름만 같고 전혀 다른 개념이다. 이 구분을 짚으면 좋은 점수를 받는다.