[Database] Crash & Recovery

0. 개요

Transaction Manager는 Concurrency Control ( 병행 제어 )와 함께 장애 발생 시 Recovery(복구) 기능을 수행한다. 이는 다음의 Transaction - ACID 속성을 만족하기 위함이다.

1. Transaction의 ACID

• Atomicity
• Consistency
• Isolation
• Durability

Consistency와 Isolation을 보장하기 위해 C&C 를 사용

2. Recovery

1) Why Recovery?

• Atomicity와 Durability를 보장하기 위해

  e.g crash 발생 시점
  T1,T2,T3 : Transaction 완료 (commit 상태)
  T4, T5 : Transaction 실행 중 (abort 상태)

• T1, T2, T3 : redo (변경 후 값을 기억해서 재실행,disk에 변경 사항 반영)

• T4, T5 : undo (변경 전 값으로 세팅)

• redo하기 위해 log record에 기록 (before valuse & after value)
  update할 때마다 log record를 남겨야함.

따라서, log file이 Recovery의 핵심.

2) Buffer Manger vs Transaction Manager

① Force : 매 transaction마다 강제로, 즉시 disk에 WRITE
② Steal : 진행 중인 Transaction이 사용 중인 buffer frame을 다른 Transaction이 뺏어서 사용

• Buffer Manager goal

  ① minimize response time
  ② enhance throughput

• Buffer Manager Policy

  No force & Steal ( page replacement algorithm)

• Buffer manager의 "no force" 때문에 durability를 보장할 수 없으며 "steal" 때문에 atomicity를 보장하지 못함
  (buffer manager의 목표가 다르므로-처리율향상과 응답시간 단축을 위해)

=> 따라서 Transaction Manager는 log를 통해 Atomicity & Durability를 보장

3. Log

1) Log 파일

ordered list of Log Record

• Log Record = < XID , pageID, offset, length, old data, new data>

2) WAL protocol

• Write-Ahead Logging Protocol
  : 트랜잭션이 일어나기 전에 미리 log를 disk에 기록하여 redo/undo를 통해 회복하기 위한 프로토콜
  ① force log record for an update befor the corresponding data page gets to disk
  ② writes all log records before commit

flushedLSN >= pageLSN

• Disk에 반영된 로그 레코드의 LSN >= page를 마지막으로 업데이트한 로그 레코드의 LSN
• 즉 디스크에 로그 레코드가 먼저 반영!

3) WAL & log

• LSN : Log Sequence Number, log record의 고유 번호이며 1씩 증가하는 정수 값을 가짐
• pageLSN : data page(disk page)를 마지막에 업데이트한 log record의 LSN
• flushedLSN : 몇 번째 log record까지 disk page에 WRITE되었는지(flushed)를 기록

  M/M에서 CPU에 있는 log record가 data page(disk page)에 WRITE하여야함.

• WAL ? Transaction에의해 변경됟 page를 disk page에 쓰기 전에 pageLSN <= flushedLSN 을 만족한다. 심플하게 요약하면 log가 '먼저' disk에 반영

  • 하나의 transaction이 여러 개의 log record가 존재할 수 있음.
    => 같은 tranasaction의 log record를 연결하기 위해 prevLSN이 관리

4) Log Record

① Log Record Field

• < prevLSN , XID , type, pageID, length, offset, befor_val, after_val>

  prevLSN : 같은 Transaction에 속한 log record들의 LSN을 backwrard chaining을 통해 가지고 있음
  type : Update/Commit/Abort/End

② checkpoint : log record가 계속 증가하면 처음부터 해당 record를 찾아서 redo/undo하기 힘듬=> (주기적으로) 중간에 체크를 통해 end로 된 transaction를 모두 삭제(앞으로는 거기이후부터 검사하도록)
check point record의 마지막을 저장하는 master

③ CLR(compensation log record) : Undo 중간에 crash가 또 발생한다면? redo/undo를 하는 와중에도 log를 남김. 따라서 이 record로 처리
(추후에 다룸)

그렇다면 Log Record를 가지고 어떻게 redo/undo를 통해 Recovery를 실현할 수 있는가에 대해 다음글에서 자세히 다루겠다.