InnoDB 의 Undo, Redo, Bin log

Undo log

Undo log 는 데이터 변경시 변경 이전 데이터를 기록하는 데에 사용되는 로그로,

구체적으로는 다음과 같은 상황에서 이용된다.

 

1. 운영 중 트랜잭션의 rollback 

2. 장애 후 복구 시 트랜잭션의 rollback

3. MVCC (Multi Version Concurrency Control)

 

 

 

DBMS 는 수정된 페이지를 바로 디스크에 쓰는 것이 아니라 메모리의 Buffer Pool 에 기록하고 checkpoint 연산이 수행될 때 dirty page 들을 디스크에 기록한다. 이에 관해 두가지 정책이 존재한다.

 

• STEAL: 수정된 페이지를 언제든지 디스크에 쓸 수 있는 정책
• ~STEAL: 수정된 페이지들을 최소한 트랜잭션 종료 시점(EOT, End of Transaction)까지는 버퍼에 유지하는 정책

 

거의 모든 DBMS 는 STEAL 정책을 따른다. 

STEAL 정책은 수정된 페이지가 어떠한 시점에도 디스크에 써질 수 있기 때문에, 커밋되지 않은 페이지도 디스크에 기록될 수 있다.  따라서 필연적으로 dirty page 들이 디스크에 기록되기 전에 Undo 로그를 플러시하고, 장애 후 복구시에 해당 트랜잭션의 롤백이 필요하다면 Undo 로그를 통해 복구해야 한다.

 

 

(즉, Undo log 는 DBMS 에 checkpoint 연산을 수행할떄 디스크에 플러시(fsync) 되어야 한다.)

 

또한 Undo 로그 는 MVCC 에 이용된다. REPEATABLE READ 격리 수준에서 SELECT 쿼리는 이 Undo log 를 읽어 적절한 버전을 찾아 반환하도록 되어 있다. 더 이상 어떤 트랜잭션에서도 사용되지 않는 Undo log 는 삭제된다.

 

 

Redo log

Redo 로그는 WAL(Write Ahead Log) 로 사용되는 로그이다.

장애 후 복구시에 먼저 Redo log 를 읽어 장애 전 데이터베이스의 상태를 복구하고 (커밋되지 않은 트랜잭션, 실패한 트랜잭션 모두) 어떤 트랜잭션을 롤백해야 하는지 판단한 후 Undo log 를 이용해 롤백을 수행한다.

 

복구에 Redo 로그가 필요한 이유 역시 Buffer Pool 의 관리 정책 때문인데, 트랜잭션 커밋 시 수정한 페이지를 디스크에 쓸 것인가 여부로 두 가지 정책이 구분된다.

 

• FORCE: 수정했던 모든 페이지를 트랜잭션 커밋 시점에 디스크에 반영하는 정책
• ~FORCE: 수정했던 페이지를 트랜잭션 커밋 시점에 디스크에 반영하지 않는 정책

대부분의 DBMS 는 ~FORCE 정책을 따른다. 즉, 트랜잭션이 커밋되더라도 수정한 페이지를 디스크에 반영하지 않을 수 있다. 위에서 언급한 STEAL 과 ~FORCE 정책을 채택함으로써 DBMS 의 버퍼 풀 관리 전략은 트랜잭션의 수행과 분리될 수 있다. (트랜잭션 여부와 관련 없이 언제 디스크로 dirty page 를 쓸지 정할 수 있다) 

 

 

하지만 ~FORCE 정책을 따르게 되면, 커밋된 트랜잭션이 유실될 수 있는데, 이를 위해 트랜잭션의 변경사항을 Redo log 에 기록하고, 이는 Log buffer 에 쌓이게 된다.  Log buffer 는 커밋 또는 체크포인트 연산 전에 디스크로 플러시되어야 한다. (단, Redo log 를 커밋시에 반드시 플러시할지, 1초 간격으로 플러시할지 설정 가능한 옵션이 존재한다. Durability 와 성능을 trade-off 할 수 있다.)

 

 

Bin log

 

binary log 는 master-slave replication 에 주로 사용되는 로그로, Redo 로그와는 달리 sql statement 에 대응되는 논리적인 로그이다.  Redo 로그는 트랜잭션 커밋 전에 플러시되기만 하면 트랜잭션 시작 후 언제 쓰여지고 플러시되어야 하는지 정해져 있지 않지만, binary log 는 트랜잭션이 커밋되기 전에 한번에 쓰여져야 한다. 따라서 어느정도의 성능 저하를 불러오므로 replication 이 필요하지 않은 경우 비활성화하는 것이 좋다. redo log -> binary log 순서대로 써지고, 

복구시에 redo log 가 커밋되었더라도 binary log 쓰기가 완료되지 않았다면 해당 트랜잭션은 롤백 대상이 된다.

 

 

참조: DBMS는 어떻게 트랜잭션을 관리할까? (naver.com)