[Database] DBA급 개발자로 - #19 Database Logging

이전 3개의 포스팅을 통해 DBMS가 어떻게 트랜잭션 동시성을 제어하는지 살펴봤습니다. 이번 포스팅에서는 database logging에 대해 살펴보겠습니다. 

Database Logging 

데이터베이스는 다음과 같은 특성을 보장해야 합니다. 

• 트랜잭션이 abort 된 경우 데이터가 부분적으로 영구 저장소에 저장되면 안 됩니다. 
• 트랜잭션이 commit 된 경우 데이터는 영구 저장소에 영구 저장돼야 합니다.

DBMS는 위와 같은 특성을 보장하기 위해 undo와 redo 기능을 제공합니다. 

• Undo: 성공적으로 commit 되지 않거나 abort 된 트랜잭션에 의한 변경사항을 되돌립니다. 
• Redo: Commit된 트랜잭션에 의한 변경사항을 영구저장소에 다시 반영할 수 있습니다. 

DBMS의 이런 기능이 어떻게 구현됐는지 살펴보기 위해 DBMS의 대표적인 정책인 steal policy와 force policy에 대해 알아보겠습니다. 

Steal Policy 

Steal policy는 uncommitted 트랜잭션에 의한 변경사항이 영구 저장소에 저장된(commit 된 이전 트랜잭션에 의해 쓰인) 데이터를 덮어씌울 수 있는지 결정하는 정책입니다. 

• Steal: Uncommitted 트랜잭션에 의한 변경사항은 영구 저장소의 데이터를 덮어씌울 수 있습니다. 
• No-Steal: Uncommitted 트랜잭션에 의한 변경사항은 영구 저장소의 데이터를 덮어씌울 수 없습니다. 

Force Policy 

Force policy는 트랜잭션의 commit 시점 직전에 모든 변경사항이 영구 저장소에 기록돼야 하는지의 여부를 결정합니다. 

• Force: 트랜잭션의 commit 시점 이전에 해당 트랜잭션에 의한 변경사항은 모두 영구 저장소에 기록돼야 합니다. 
• No-Force: 트랜잭션의 commit 시점 이전에 해당 트랜잭션에 의한 변경사항이 모두 영구 저장소에 기록될 필요가 없습니다. 

다음으로는 위의 steal과 force 정책을 DBMS에서 어떻게 조합해서 사용하는지 살펴보겠습니다. 

No-Steal && Force 

No-Steal과 Force 정책을 준수하면 uncommitted 트랜잭션은 영구 저장소의 데이터를 덮어씌울 수 없고 force 정책에 의해 commit 이전에 영구저장소에 데이터를 저장해야 합니다. 이 정책을 준수한 DBMS의 특징은 다음과 같습니다. 

• 트랜잭션이 abort 하는 경우 undo 과정이 불필요합니다. Abort 된 트랜잭션은 uncommitted 상태이기 때문에 no-steal 정책에 의해 영구 저장소의 데이터를 수정할 수 없기 때문입니다. 
• Redo 과정이 불필요합니다. Commit이 수행되기 전에 영구 저장소에 변경사항이 모두 반영됐기 때문입니다. 

No-Steal과 Force 정책을 준수하는 구현 기법 중 대표적인 것으로는 shadow paging이 있습니다. Shadow paging은 데이터베이스를 master과 shadow로 구분해서 관리합니다. 

• Master: Commit이 완료된 트랜잭션에 의한 변경사항만 반영된 페이지 테이블입니다. 
• Shadow(slave): Commit이 완료되지 않은 트랜잭션에 의한 변경사항이 반영된 페이지 테이블입니다. 

트랜잭션은 slave에만 변경을 수행합니다. 트랜잭션이 commit 되는 경우 slave의 변경사항을 영구 저장소에 플러시하고 해당 변경사항을 기록한 slave가 새로운 master가 되도록 지시합니다. Shadow paging에서 undo는 slave를 제거함으로써 수행할 수 있고 redo의 경우 commit 시점 이전에 slave에 반영된 변경사항이 모두 영구 저장소에 flush 되므로 불필요합니다. 

Shadow paging은 구현의 난이도가 비교적 쉽다는 장점이 있지만 단점도 있습니다. Slave를 유지하기 위한 비용이 크고 트랜잭션의 커밋 시점마다 영구저장소에 데이터를 플러시 해야 하므로 그 오버헤드가 작지 않습니다. 또한 변경사항을 저장할 때 random write이 발생하므로 처리시간이 깁니다. 이러한 단점을 극복할 수 있는 방법으로 write ahead logging 기법이 있습니다. 

Steal && No-Force 

Write ahead log(WAL) 기법은 대표적인 steal과 no-force 정책을 활용한 기법입니다. DBMS의 data file 이외에 별도의 log file을 사용합니다. 이 log file은 메모리가 아닌 영구 저장소에 저장되고 undo와 redo 작업에 필요한 데이터를 모두 기록합니다. Steal policy를 따르므로 uncommitted 트랜잭션이 log를 남길 수 있습니다. 트랜잭션 커밋 이전 data file에 저장된 실제 파일의 데이터를 수정하지 않아도 commit이 가능하므로 no-force policy를 따른다고 볼 수 있습니다. 

 

마무리 

이번 포스팅에서는 steal과 force 정책에 대해, 그리고 두 정책의 조합을 어떻게 DBMS에서 구현하는지 간략하게 살펴봤습니다. 다음 포스팅에서는 DBMS에서 WAL를 활용해서 어떻게 복구를 수행하는지 살펴보겠습니다.