7. 회복 시스템

Posted Dec 7, 2025

By noir1458

15 min read

7. 회복 시스템

회복(Recovery)의 개념

시스템 장애 발생 시 데이터베이스를 장애 이전의 일관된 상태로 복원하는 것. ACID의 원자성(Atomicity)과 지속성(Durability)을 보장한다.

장애 유형

1. 트랜잭션 장애 (Transaction Failure)
   - 논리적 오류: 잘못된 입력, 데이터 미존재
   - 시스템 오류: Deadlock 등으로 트랜잭션 중단
   - 해당 트랜잭션만 Rollback

2. 시스템 장애 (System Failure)
   - 전원 차단, OS 오류, 하드웨어 오류 (비휘발성 저장 장치 무사)
   - 메모리(버퍼) 내용 소실
   - 모든 활성 트랜잭션 Rollback, 커밋된 트랜잭션 Redo

3. 미디어 장애 (Media/Disk Failure)
   - 디스크 손상으로 데이터 소실
   - 백업으로부터 복원 후 로그 적용
   - 가장 심각한 장애

로그 (Log)

로그란?

트랜잭션의 모든 갱신 활동을 기록하는 파일

로그 레코드 종류:
  <Ti, start>         : 트랜잭션 Ti 시작
  <Ti, X, old, new>   : Ti가 X를 old → new로 변경
  <Ti, commit>        : Ti 커밋 완료
  <Ti, abort>         : Ti 중단
  <checkpoint, L>     : 체크포인트 (L: 활성 트랜잭션 목록)

예:
  <T1, start>
  <T1, A, 1000, 900>    -- A: 1000 → 900
  <T1, B, 2000, 2100>   -- B: 2000 → 2100
  <T1, commit>

WAL (Write-Ahead Logging)

핵심 원칙: 데이터를 디스크에 쓰기 전에 반드시 로그를 먼저 디스크에 기록

규칙:
1. Undo 규칙: 데이터 페이지를 디스크에 쓰기 전에
   해당 로그 레코드를 먼저 디스크에 기록
   → Undo(취소) 가능하도록

2. Redo 규칙: 트랜잭션 커밋 시
   모든 로그 레코드를 디스크에 기록
   → Redo(재실행) 가능하도록

→ 장애 시 로그만 있으면 DB를 복구 가능

회복 기법

지연 갱신 (Deferred Update / No-Undo/Redo)

원리:
  - 트랜잭션 커밋 전까지 실제 DB 변경을 지연
  - 로그에만 기록하고, 커밋 시점에 실제 반영
  - 커밋 전 장애 → 로그 무시 (Undo 불필요)
  - 커밋 후 장애 → 로그로 Redo

회복 과정:
  1. 로그를 역순으로 스캔
  2. <Ti, commit>이 있는 트랜잭션: Redo
  3. <Ti, commit>이 없는 트랜잭션: 무시 (아직 DB에 미반영)

장점: Undo 불필요 (단순)
단점: 커밋 지연 (모든 변경을 커밋 시점에 반영)

즉시 갱신 (Immediate Update / Undo/Redo)

원리:
  - 트랜잭션 실행 중에도 DB를 즉시 변경
  - 변경 전 로그를 먼저 기록 (WAL)
  - 커밋 전 장애 → Undo (이전 값으로 복원)
  - 커밋 후 장애 → Redo (변경 다시 적용)

회복 과정:
  1. 로그를 스캔하여 Redo 대상과 Undo 대상 분류
  2. Redo: 커밋된 트랜잭션의 변경을 재적용 (순방향)
  3. Undo: 미완료 트랜잭션의 변경을 취소 (역방향)

장점: 커밋 지연 없음 (실시간 반영)
단점: Undo와 Redo 모두 필요 (복잡)

비교

구분	지연 갱신	즉시 갱신
DB 반영 시점	커밋 시	실행 중
Undo	불필요	필요
Redo	필요	필요
복잡도	단순	복잡
커밋 지연	있음	없음
실제 사용	이론적	대부분의 DBMS

체크포인트 (Checkpoint)

필요성

문제: 장애 시 로그 전체를 스캔하면 시간이 너무 오래 걸림
해결: 주기적으로 체크포인트를 수행하여 회복 시작점을 제한

체크포인트 시 수행:
  1. 현재 메모리의 모든 로그 레코드를 디스크에 기록 (Log Flush)
  2. 수정된 모든 버퍼 블록을 디스크에 기록 (Buffer Flush)
  3. 체크포인트 레코드를 로그에 기록
     <checkpoint, {T1, T2, ...}>  -- 활성 트랜잭션 목록

체크포인트 기반 회복

시간축:
  ──┬─────┬──────┬──────┬──────┬──→
   T1    T2    CP     T3    장애

CP = 체크포인트

회복:
  - CP 이전에 커밋된 트랜잭션(T1): 무시 (이미 디스크에 반영)
  - CP 시점에 활성이었고 커밋된 트랜잭션(T2): Redo
  - CP 이후 시작되어 커밋된 트랜잭션: Redo
  - 미완료 트랜잭션(T3): Undo

→ 체크포인트 이전 로그는 스캔할 필요 없음!

Fuzzy Checkpoint

일반 체크포인트: 체크포인트 동안 트랜잭션 중단 → 성능 저하

Fuzzy Checkpoint:
  - 트랜잭션을 중단하지 않고 체크포인트 수행
  - 더티 페이지 목록만 기록
  - 실제 디스크 기록은 백그라운드에서 점진적 수행
  - 실무에서 사용하는 방식

ARIES (Algorithm for Recovery and Isolation Exploiting Semantics)

IBM에서 개발한 회복 알고리즘. 대부분의 상용 DBMS가 ARIES 기반 회복을 사용한다.

핵심 원칙

1. WAL (Write-Ahead Logging)
   - 데이터 변경 전 로그를 먼저 디스크에 기록

2. Repeating History During Redo
   - 장애 발생 직전 상태를 정확히 재구성
   - 커밋되지 않은 트랜잭션의 변경도 Redo

3. Logging Changes During Undo
   - Undo 작업도 로그에 기록 (CLR: Compensation Log Record)
   - Undo 중 장애 발생 시 반복 Undo 방지

ARIES 자료 구조

1. 로그 (Log)
   - 각 로그 레코드에 LSN (Log Sequence Number) 부여
   - LSN: 로그의 고유 식별자, 단조 증가

2. 트랜잭션 테이블 (Transaction Table)
   - 활성 트랜잭션 목록
   - 각 트랜잭션의 마지막 LSN (lastLSN)

3. 더티 페이지 테이블 (Dirty Page Table)
   - 메모리에서 수정되었지만 아직 디스크에 기록되지 않은 페이지
   - 각 페이지의 recoveryLSN (처음 더티가 된 시점의 LSN)

ARIES 회복 3단계

장애 발생 후 회복 과정:

Phase 1: 분석 (Analysis)
  ──────────────────────────→
  마지막 체크포인트부터 로그 끝까지 순방향 스캔
  - 트랜잭션 테이블 재구성 (활성 트랜잭션 파악)
  - 더티 페이지 테이블 재구성
  - Redo 시작점 결정: 더티 페이지 테이블의 최소 recoveryLSN

Phase 2: Redo (재실행)
  ──────────────────────────→
  Redo 시작점부터 로그 끝까지 순방향 스캔
  - 모든 갱신을 다시 적용 (Repeating History)
  - 커밋/미커밋 구분 없이 모두 Redo
  - 장애 직전 상태 재구성

Phase 3: Undo (취소)
  ←──────────────────────────
  로그 끝부터 역방향 스캔
  - 미완료 트랜잭션의 변경을 취소
  - CLR(Compensation Log Record) 기록
  - 모든 미완료 트랜잭션의 시작 레코드까지 Undo

시간축:
  ─────┬─────────────┬──────────────┬─→
    Checkpoint    Redo 시작점      장애
       ↑
  ←─ 분석 시작 ─→
  |←─────── Redo ─────────────────→|
                    |←──── Undo ───|

CLR (Compensation Log Record)

Undo 연산을 기록하는 특수 로그 레코드

구조: <CLR, Ti, X, old_value, undoNextLSN>
- Ti: 트랜잭션 식별자
- X: 수정한 데이터
- old_value: 복원 값
- undoNextLSN: 다음에 Undo할 로그의 LSN

목적:
  - Undo 중 다시 장애 발생해도 이미 Undo한 것을 다시 하지 않음
  - 멱등성(Idempotency) 보장

백업과 복원

백업 유형

1. 물리적 백업 (Physical Backup)
   - 데이터 파일을 직접 복사
   - 빠르지만 같은 DBMS에서만 복원 가능

2. 논리적 백업 (Logical Backup)
   - SQL 형태로 데이터 추출 (mysqldump 등)
   - 느리지만 이식성 높음

3. 전체 백업 (Full Backup)
   - DB 전체를 백업
   - 복원이 간단하지만 시간/공간 비용 큼

4. 증분 백업 (Incremental Backup)
   - 마지막 백업 이후 변경된 부분만 백업
   - 빠르지만 복원 시 여러 백업 필요

5. 차등 백업 (Differential Backup)
   - 마지막 전체 백업 이후 변경된 부분
   - 증분보다 복원이 간단

복원 과정

미디어 장애 시:
  1. 가장 최근 전체 백업으로 DB 복원
  2. 증분/차등 백업 순서대로 적용
  3. 로그 파일의 변경 사항 Redo
  → 장애 직전 상태로 복원

┌──────────┬──────────┬──────────┬────────────┐
│ Full     │ Incr 1   │ Incr 2   │  로그 Redo  │
│ Backup   │ Backup   │ Backup   │            │
└──────────┴──────────┴──────────┴────────────┘
                                    ↑ 장애 시점

핵심 정리

회복 = 장애 후 DB를 일관된 상태로 복원
WAL: 데이터 변경 전 로그를 먼저 디스크에 기록
지연 갱신: No-Undo/Redo, 즉시 갱신: Undo/Redo
체크포인트: 회복 범위를 제한하여 효율적 복구
ARIES: 분석 → Redo → Undo (3단계)
CLR: Undo를 기록하여 반복 Undo 방지
백업: 전체/증분/차등 → 미디어 장애 대비

면접 포인트

자주 나오는 질문

Q1. WAL이란?

Write-Ahead Logging: 데이터를 디스크에 쓰기 전에 로그를 먼저 기록
Undo 규칙: 데이터 쓰기 전 로그 기록 → 취소 가능
Redo 규칙: 커밋 시 로그 기록 → 재실행 가능
대부분의 DBMS가 WAL 기반

Q2. 체크포인트의 역할은?

메모리의 변경 내용을 디스크에 강제 기록하는 시점
회복 시 체크포인트 이전 로그는 스캔 불필요 → 복구 시간 단축
Fuzzy Checkpoint: 트랜잭션을 중단하지 않고 수행

Q3. ARIES의 3단계를 설명하라.

분석(Analysis): 체크포인트부터 순방향, 활성 트랜잭션과 더티 페이지 파악
Redo: 모든 갱신을 순방향으로 재실행 (Repeating History)
Undo: 미완료 트랜잭션을 역방향으로 취소 (CLR 기록)

Q4. 지연 갱신과 즉시 갱신의 차이는?

지연 갱신: 커밋 전까지 DB 미변경, Undo 불필요, Redo만 수행
즉시 갱신: 실행 중 DB 변경, Undo와 Redo 모두 필요
실무에서는 즉시 갱신 방식 사용 (ARIES)

Q5. Redo와 Undo의 차이는?

Redo: 커밋된 트랜잭션의 변경을 다시 적용 (지속성 보장)
Undo: 미완료 트랜잭션의 변경을 취소 (원자성 보장)
Redo는 순방향, Undo는 역방향으로 수행

database

This post is licensed under CC BY 4.0 by the author.