Introduction#

데이터베이스 시스템은 트랜잭션의 안전한 수행을 위해 ACID 속성을 보장한다.

ACID

• Atomicity : all or nothing, 트랜잭션의 내부의 모든 연산이 성공하거나 모두 취소되어야 한다. 따라서 트랜잭션이 중간에 실패한다면 롤백되어야 한다.
• Consistency : 데이터의 일관성이 보장되어야 한다. 예를 들어, 트랜잭션 전후로 데이터베이스의 제약 조건이 유지되어야 한다.
• Isolation : 여러 트랜잭션이 동시에 실행될 때, 서로의 작업에 영향을 미치지 않고 독립적으로 실행되는 것처럼 보여야 한다.
• Durability : 데이터베이스는 디스크에 트랜잭션의 결과가 기록됨을 보장해야 한다. 성공적으로 완료된(커밋된) 트랜잭션의 결과는 영구적으로 저장되어야 하며, 시스템에 장애(예: 정전, 서버 다운)가 발생하더라도 절대 사라지지 않아야 한다.

이러한 ACID 속성은 DBMS의 Storage Engine이 담당한다. 트랜잭션의 ACID 보장을 위해 DBMS가 어떻게 동작하는지 알아보자.

fsync()#

데이터베이스의 COMMIT 연산이 디스크에 기록된다는 것을 DBMS 는 어떻게 보장할까? DBMS는 Durability를 위해 데이터를 쓸 때 write() 뿐만 아니라 fsync() 를 사용한다.

fsync() 함수는 fd 로 지정된 파일과 관련된 변경 내역을 디스크와 동기화 하는 함수이다. 일반적으로 write() 와 같은 디스크 I/O 연산은 커널 안의 버퍼 캐시나 페이지 캐시를 거치게 되기 때문에, 해당 연산이 수행되었다고 해도 실제로 디스크에 쓰기 연산이 수행됨을 보장할 수 없다. 하지만 fsync() 를 사용하면 모든 버퍼 내용을 디스크와 동기화하게 되므로 디스크 상의 파일 시스템과 버퍼 캐시의 내용의 불일치 문제를 해결한다.

하나의 트랜잭션이 커밋될 때 fsync()를 통해 변경사항이 디스크에 기록되므로, 각 트랜잭션의 Durability 속성을 보장할 수 있다.

fsync()의 오버헤드

fsync() 는 동기적(Synchronous) 연산이므로 성능 상 오버헤드가 있다. DBMS에서 fsync()의 오버헤드를 줄이기 위해 그룹 커밋이나 (MySQL InnoDB 스토리지 엔진 기준) innodb_flush_log_at_trx_commit 과 같은 옵션을 사용하여 동기화 주기를 설정한다.

로그를 이용한 복구#

데이터베이스 시점에서 복구가 필요하다는 건 어떤걸 의미할까?

우선 트랜잭션 단위로 생각한다면, 트랜잭션이 실패했다면 데이터 일관성을 위해 트랜잭션 수행 전으로 복구하는 작업이 필요하다.

또한 만약 시스템에 장애가 생겨서, 데이터베이스에서 수행된 연산들이 디스크에 모두 기록되지 않았을 때, 해당 연산의 결과들을 디스크에 동기화해야 한다. 왜냐하면 데이터베이스에서 Durability를 보장한다는 것은 사용자 입장에서 연산의 결과가 디스크에 저장되었음으로 간주하는 것이기 때문에 DBMS는 이러한 동기화를 처리해주어야 한다.

이러한 복구 작업을 위해 MySQL과 같은 DBMS에서는 로그를 이용한다.

로그는 LSN (Log Sequence Number)을 가지며, 로그가 기록될 때 마다 LSN은 단조 증가한다. 또한 MySQL (InnoDB 스토리지 엔진)은 주기적으로 체크포인트 이벤트를 발생시켜 특정 시점까지의 모든 내용이 디스크에 영구적으로 저장되었음을 보장하는 기준점을 갱신한다.

1
LSN 100 (T1 Begin)
2
LSN 150 (T1 Update A, PrevLSN=100)
3
LSN 200 (T1, Update B, PrevLSN=150)
4
LSN 220 (T2, ...)

1
LSN 100 (T1 Begin)
2
LSN 150 (T1 Update A, PrevLSN=100)
3
LSN 200 (T1, Update B, PrevLSN=150)
4
LSN 220 (T2, ...)
5
LSN 250 (T1, CLR for LSN 200, ...)

참고 자료#

• 『Real MySQL 8.0』 (백은빈, 이성욱, 위키북스)
• DBMS는 어떻게 트랜잭션을 관리할까? - Naver D2