안동민 개발노트

서버가 갑자기 죽었을 때, 데이터가 사라지지 않는 이유 — 데이터베이스의 복구(Recovery) 메커니즘 덕분입니다. 어떤 장애가 발생하더라도 커밋된 데이터는 살리고, 커밋되지 않은 데이터는 되돌리는 것이 복구의 목표입니다. 복구 시스템은 ACID 속성 중 원자성(Atomicity)과 지속성(Durability)을 보장하는 핵심 메커니즘입니다.

장애의 유형

데이터베이스 시스템에서 발생할 수 있는 장애는 크게 세 가지로 분류됩니다. 각 장애는 발생 빈도, 심각도, 복구 방법이 서로 다릅니다.

장애 유형	원인	빈도	심각도	복구 방법
트랜잭션 장애	논리 오류, 제약 위반, 데드락	빈번	낮음	ROLLBACK (Undo)
시스템 장애	정전, OS 크래시, 메모리 오류	가끔	중간	인스턴스 복구 (Redo + Undo)
디스크 장애	디스크 손상, 파일 시스템 손상	드문	높음	백업에서 복원 + 아카이브 로그

트랜잭션 장애

트랜잭션 장애(Transaction Failure)는 개별 트랜잭션이 정상적으로 완료되지 못하는 상황입니다. 가장 빈번하게 발생하지만, 복구도 가장 간단합니다.

트랜잭션 장애의 원인은 다양합니다.

논리적 오류: 0으로 나누기, 배열 범위 초과, 잘못된 데이터 입력 등 프로그램 로직의 오류입니다.
제약 조건 위반: 기본키 중복, 외래키 참조 위반, CHECK 제약 위반, NOT NULL 위반 등입니다.
데드락(Deadlock): 두 트랜잭션이 서로가 점유한 자원을 기다리며 무한 대기에 빠지는 상황입니다. DBMS가 데드락을 감지하면 한쪽 트랜잭션을 강제로 ROLLBACK합니다.
타임아웃: 트랜잭션이 지정된 시간 내에 완료되지 못한 경우입니다.
사용자 요청: 사용자가 명시적으로 ROLLBACK을 요청한 경우입니다.

트랜잭션 장애 예시

-- 제약 조건 위반
BEGIN TRANSACTION;
INSERT INTO students (student_id, name)
VALUES (2024001, '김철수');   -- ✓ 성공

INSERT INTO students (student_id, name)
VALUES (2024001, '이영희');   -- ✗ PK 중복! 트랜잭션 장애

ROLLBACK;
-- Undo 로그를 이용하여 김철수 INSERT도 취소

데드락 발생 시나리오

T1: LOCK accounts WHERE id = 'A'  → 성공
T2: LOCK accounts WHERE id = 'B'  → 성공

T1: LOCK accounts WHERE id = 'B'  → 대기 (T2가 점유 중)
T2: LOCK accounts WHERE id = 'A'  → 대기 (T1이 점유 중)

→ 서로 상대방을 기다림 → 데드락!
→ DBMS가 T2를 희생자로 선택하여 ROLLBACK
→ T1은 'B' 잠금 획득하여 진행

트랜잭션 장애의 복구는 Undo 로그를 이용한 ROLLBACK입니다. 시스템 전체에 영향을 주지 않으며, 해당 트랜잭션만 취소됩니다.

시스템 장애

시스템 장애(System Failure)는 데이터베이스 시스템 전체가 중단되는 상황입니다. 하드웨어 결함이나 소프트웨어 버그, 정전 등으로 인해 발생합니다.

시스템 장애의 핵심적인 특성은 메모리(휘발성 저장소)의 내용이 소실된다는 것입니다. 반면 디스크(비휘발성 저장소)의 데이터는 보존됩니다.

장애별 데이터 상태

정상 운영 중
  메모리(Buffer Cache):  최신 데이터 (아직 디스크에 안 쓸 수도)
  Redo 로그 파일:       변경 내역 기록 (디스크에 존재)
  데이터 파일:           이전 체크포인트 시점의 데이터

시스템 장애 발생 시
  메모리:  소실! (전원 꺼짐)
  Redo 로그:  살아 있음 (디스크)
  데이터 파일:  체크포인트 시점으로 뒤처져 있음

→ Redo 로그로 메모리에 있던 변경 복원 가능

시스템 장애 발생 시, 메모리에만 존재하던 데이터는 세 가지 상태 중 하나입니다.

커밋 완료 + 디스크 미반영: COMMIT은 했지만 데이터 파일에 아직 기록되지 않은 변경. Redo가 필요합니다.
커밋 미완료: 아직 COMMIT하지 않은 트랜잭션의 변경. Undo가 필요합니다.
커밋 완료 + 디스크 반영: 이미 데이터 파일에 기록된 변경. 복구 불필요합니다.

시스템 장애 후 트랜잭션 분류

시간축:
  체크포인트          장애 발생
      │                  │
──────┼────T1──COMMIT─────┼──── T1: Redo 필요 (커밋됨, 디스크 반영 불확실)
──────┼──T2──────────COMMIT┼──── T2: Redo 필요 (커밋됨)
──────┼────T3─────────────┼──── T3: Undo 필요 (커밋 안 됨)
   T4─COMMIT──────────────┼──── T4: 복구 불필요 (체크포인트에 포함)
──────┼───────T5──────────┼──── T5: Undo 필요 (커밋 안 됨)

디스크 장애

디스크 장애(Disk Failure)는 데이터 파일이 저장된 디스크가 물리적으로 손상되는 상황입니다. 가장 드물지만 가장 심각한 장애입니다.

디스크 장애에서는 데이터 파일 자체가 소실되므로, Redo 로그만으로는 복구할 수 없습니다. 별도 장소에 보관된 백업(Backup)과 아카이브 로그(Archive Log)를 이용하여 복구합니다.

디스크 장애 복구 과정

1. 백업에서 데이터 파일 복원 (백업 시점으로 되돌아감)
2. 아카이브 로그 적용 (백업 이후의 변경 사항을 순차적으로 재적용)
3. 온라인 Redo 로그 적용 (가장 최근의 변경 사항 재적용)
4. Undo 실행 (복구 시점에 커밋되지 않은 트랜잭션 롤백)

백업 시점                  장애 발생
  │                           │
  │◀── 아카이브 로그 적용 ───▶│
  │                           │
  └── 이 구간의 모든 커밋된 변경을 복원

디스크 장애를 대비하기 위한 전략은 다음과 같습니다.

RAID: 디스크 미러링(RAID 1)이나 패리티(RAID 5/6)로 디스크 1개가 고장나도 데이터 손실을 방지합니다.
정기 백업: 전체 백업(Full Backup)과 증분 백업(Incremental Backup)을 주기적으로 수행합니다.
아카이브 로그: Oracle의 ARCHIVELOG 모드, MySQL의 binlog 등으로 모든 변경 이력을 디스크에 보관합니다.
이중화(Replication): 실시간으로 다른 서버에 데이터를 복제하여 주 서버 장애 시 즉시 전환합니다.

Redo와 Undo

복구의 두 축은 Redo(재실행)와 Undo(취소)입니다. 이 두 연산은 데이터베이스 복구의 근본 메커니즘입니다.

구분	Redo	Undo
목적	커밋된 변경을 재적용	커밋 안 된 변경을 되돌림
저장 위치	Redo 로그 파일	Undo Segment / Undo 로그
보장 속성	지속성 (Durability)	원자성 (Atomicity)
동작 시점	장애 복구 시 롤포워드	장애 복구 시 롤백
기록 내용	변경 후의 값 (After Image)	변경 전의 값 (Before Image)
방향	과거 → 현재 (앞으로)	현재 → 과거 (뒤로)

Redo 상세

Redo(재실행)는 커밋된 트랜잭션의 변경 사항을 다시 적용하는 연산입니다. "이 변경이 커밋되었으니, 다시 해라"입니다. 롤포워드(Roll Forward)라고도 합니다.

Redo 로그에는 변경 후의 값(After Image)이 기록됩니다. A를 100에서 200으로 변경했다에서 200으로 변경이라는 정보입니다.

Redo 로그 레코드 구조

[LSN: 1001] [TxID: T1] [Table: accounts] [Row: A]
            [Operation: UPDATE] [Column: balance]
            [After Image: 200]
            [Timestamp: 2024-06-15 14:30:01]

[LSN: 1002] [TxID: T1] [COMMIT]
            [Timestamp: 2024-06-15 14:30:02]

LSN (Log Sequence Number): 로그 레코드의 순번
TxID: 트랜잭션 식별자
After Image: 변경 후의 값

Undo 상세

Undo(취소)는 커밋되지 않은 트랜잭션의 변경 사항을 이전 상태로 되돌리는 연산입니다. "이 변경은 커밋되지 않았으니, 원래대로 돌려라"입니다. 롤백(Rollback)이라고도 합니다.

Undo 로그에는 변경 전의 값(Before Image)이 기록됩니다. A를 100에서 200으로 변경했다에서 원래 값은 100이었다라는 정보입니다.

Undo 로그 레코드 구조

[TxID: T2] [Table: accounts] [Row: B]
           [Operation: UPDATE] [Column: balance]
           [Before Image: 50]
           (→ 'Undo 시 balance를 50으로 되돌려라')

Redo와 Undo의 복구 과정

Redo와 Undo의 역할

트랜잭션 T1: UPDATE A = 100 → 200  →  COMMIT
트랜잭션 T2: UPDATE B = 50 → 80    →  (아직 COMMIT 안 함)

    ── 시스템 장애 발생! ──

복구 절차
  1단계 Redo (롤포워드)
    Redo 로그의 모든 변경을 재적용
    → A = 200 (T1 변경 복원)
    → B = 80  (T2 변경도 일단 복원)

  2단계 Undo (롤백)
    커밋 안 된 트랜잭션의 변경을 되돌림
    → B = 50  (T2는 커밋 안 했으므로 원복)

결과
  A = 200 (커밋됨 → 살림) ✓
  B = 50  (커밋 안 됨 → 되돌림) ✓

왜 Redo가 먼저인가

복구 과정에서 Redo를 먼저 수행하고 그 다음에 Undo를 수행하는 이유가 있습니다. 이 순서는 매우 중요합니다.

첫째, Undo 정보 자체도 Redo 로그에 의해 보호되기 때문입니다. Undo Segment(또는 Undo 로그)는 메모리에 있을 수도 있고, 디스크에 있을 수도 있습니다. 시스템 장애 시 메모리의 Undo 정보가 소실될 수 있습니다. Redo 로그에는 Undo Segment에 대한 변경도 기록되어 있으므로, Redo를 먼저 수행하면 Undo Segment가 복원됩니다. 그래야 커밋 안 된 트랜잭션을 정확하게 롤백할 수 있습니다.

둘째, 어떤 변경이 디스크에 반영되었는지 알 수 없기 때문입니다. 장애 발생 시점에 어떤 데이터가 Buffer Cache에만 있었고 어떤 데이터가 이미 디스크에 기록되었는지 정확히 알 수 없습니다. 가장 안전한 방법은 Redo 로그의 모든 변경을 재적용하는 것입니다. 이미 디스크에 반영된 변경에 대해 Redo를 적용해도 결과는 동일하므로(멱등성, Idempotency), 문제가 되지 않습니다.

Redo 먼저의 논리

1. Redo 적용 → 모든 데이터를 장애 직전 상태로 복원
   (커밋된 것 + 커밋 안 된 것 모두 포함)
   → Undo Segment도 복원됨

2. Undo 적용 → 커밋 안 된 트랜잭션만 골라서 되돌림
   → Undo Segment가 온전해야 이 작업이 가능

순서를 바꾸면?
  Undo 먼저 → Undo Segment가 불완전할 수 있음
  → 어떤 트랜잭션을 롤백해야 하는지 모름
  → 불완전한 복구!

WAL (Write-Ahead Logging)

WAL(Write-Ahead Logging)은 데이터베이스 복구의 기본 원칙입니다. "데이터를 변경하기 전에, 변경 내역을 로그에 먼저 기록한다"는 원칙입니다.

WAL 원칙을 두 가지 규칙으로 정리할 수 있습니다.

규칙 1 (Undo Rule): 데이터 파일에 변경 사항을 기록하기 전에, Undo 정보(Before Image)를 로그에 먼저 기록해야 합니다. 이 규칙이 없으면 변경된 데이터가 디스크에 기록된 후 장애가 발생했을 때, 원래 값을 알 수 없어 롤백이 불가능합니다.

규칙 2 (Redo Rule): 트랜잭션을 커밋하기 전에, 해당 트랜잭션의 모든 Redo 로그 레코드를 디스크에 기록(flush)해야 합니다. 이 규칙이 없으면 커밋 후 장애가 발생했을 때, 변경 내역을 재적용할 수 없어 지속성이 보장되지 않습니다.

WAL 원칙의 동작

트랜잭션 실행 과정
  1. BEGIN TRANSACTION
  2. 데이터 변경 (Buffer Cache에서)
  3. Redo 로그 레코드 생성 (Log Buffer에)
  4. COMMIT 요청
  5. Log Buffer → 디스크의 Redo 로그 파일 (flush) ← WAL!
  6. COMMIT 완료 응답 (사용자에게 "성공" 통보)
  7. 변경된 데이터는 나중에 체크포인트 시 디스크에 기록

핵심:
  - 로그가 데이터보다 항상 먼저 디스크에 기록됨
  - COMMIT 시점에 로그만 디스크에 쓰면 됨 (데이터는 나중에)
  - 이것이 "Write-Ahead"의 의미

WAL의 성능상 이점은 매우 큽니다. 데이터 파일은 테이블의 여러 위치에 랜덤하게 흩어져 있어 랜덤 I/O가 필요하지만, 로그 파일은 항상 끝에 순차적으로 추가되므로 순차 I/O만 필요합니다. 순차 I/O는 랜덤 I/O보다 훨씬 빠르므로, 커밋 시 로그만 디스크에 쓰는 것이 데이터 파일을 직접 쓰는 것보다 훨씬 빠릅니다.

랜덤 I/O vs 순차 I/O

데이터 파일 쓰기 (랜덤 I/O)
  디스크: [ ][A][ ][ ][B][ ][C][ ][ ]
  → A, B, C가 흩어져 있어 디스크 헤드가 이동 필요
  → 느림 (수 ms/회)

로그 파일 쓰기 (순차 I/O)
  디스크: [로그1][로그2][로그3][로그4]→
  → 항상 끝에 이어서 기록
  → 빠름 (디스크 헤드 이동 불필요)

체크포인트 (Checkpoint)

체크포인트(Checkpoint)는 Buffer Cache의 변경된 데이터를 모두 디스크에 기록하는 시점입니다. 체크포인트를 기록해두면, 복구 시 체크포인트 이전의 Redo 로그는 재적용할 필요가 없어 복구 시간이 단축됩니다.

체크포인트의 효과

체크포인트 없이 복구:
  DB 시작 시점부터 장애 시점까지의 모든 Redo 로그를 재적용
  → 로그가 몇 GB라면 복구에 매우 오랜 시간 소요

체크포인트 있는 복구:
  마지막 체크포인트 이후의 Redo 로그만 재적용
  → 복구 시간 대폭 단축

시간축:
  ──────CP1──────CP2──────CP3──────장애──
                                    │
  체크포인트 없으면: ◀───────전부 Redo──│
  체크포인트 있으면:          CP3 이후만│
                              ◀─Redo─│

체크포인트의 종류는 두 가지입니다.

풀 체크포인트(Full Checkpoint)는 Buffer Cache의 모든 Dirty Page를 디스크에 기록합니다. 이 동안 새로운 트랜잭션의 실행이 잠시 중단될 수 있어, 실시간 시스템에서는 부담이 됩니다.

퍼지 체크포인트(Fuzzy Checkpoint)는 Dirty Page를 점진적으로 디스크에 기록합니다. 트랜잭션 실행을 중단하지 않으므로, 대부분의 현대 DBMS가 이 방식을 사용합니다.

로그 기반 복구 알고리즘

실제 DBMS에서 사용하는 대표적인 복구 알고리즘을 살펴보겠습니다.

즉시 갱신 (Immediate Update)

트랜잭션이 활동 중일 때도 변경 사항을 즉시 디스크의 데이터 파일에 기록하는 방식입니다. 커밋 전에도 디스크에 기록될 수 있으므로, 롤백 시 Undo가 필요합니다.

즉시 갱신 방식

T1: UPDATE A = 100 → 200
  → Redo 로그 기록
  → 데이터 파일에 즉시 반영 가능 (A = 200)
  → COMMIT 전에 장애 발생하면?
  → 디스크에 이미 200이 기록되어 있음
  → Undo 필요: A를 100으로 되돌림

지연 갱신 (Deferred Update)

트랜잭션이 커밋될 때까지 데이터 파일에 기록하지 않는 방식입니다. 커밋 전에는 로그에만 기록하고, 커밋 시점에 데이터 파일에 반영합니다. 커밋 전 장애가 발생하면 디스크에 아무것도 기록되지 않았으므로 Undo가 필요 없고, Redo만 필요합니다.

지연 갱신 방식

T1: UPDATE A = 100 → 200
  → Redo 로그 기록 (A → 200)
  → 데이터 파일에는 아직 반영 안 함 (A = 100 유지)

T1: COMMIT
  → 이 시점에 데이터 파일에 반영 (A = 200)

COMMIT 전에 장애 발생하면?
  → 데이터 파일에는 A = 100 (원래대로)
  → Undo 불필요! (데이터 파일이 변경되지 않았으므로)
  → 다만 커밋되지 않았으므로 무시하면 됨

ARIES 알고리즘

ARIES(Algorithm for Recovery and Isolation Exploiting Semantics)는 IBM에서 개발한 복구 알고리즘으로, 현대 대부분의 DBMS가 이 알고리즘의 변형을 사용합니다. ARIES는 세 단계로 복구를 수행합니다.

ARIES 복구 3단계

1단계: Analysis (분석)
  → Redo 로그를 스캔하여 다음을 파악:
    - 마지막 체크포인트 위치
    - 장애 시점에 활동 중이던 트랜잭션 (Undo 대상)
    - 장애 시점에 커밋된 트랜잭션 (Redo 대상)
    - Dirty Page 목록

2단계: Redo (재실행)
  → 체크포인트 이후 Redo 로그의 모든 변경을 재적용
  → "역사를 반복한다" (Repeating History)
  → 커밋 여부와 관계없이 모든 변경을 재적용

3단계: Undo (취소)
  → 장애 시점에 커밋되지 않은 트랜잭션을 역순으로 롤백
  → Undo 로그를 이용하여 Before Image로 복원

ARIES의 핵심 원칙은 역사 반복(Repeating History)입니다. Redo 단계에서 커밋 여부와 관계없이 모든 로그 레코드를 재적용합니다. 이렇게 하면 장애 직전의 정확한 상태가 메모리에 복원되고, 그 상태에서 커밋 안 된 트랜잭션만 정확하게 Undo할 수 있습니다.

복구와 성능의 균형

복구 메커니즘은 데이터의 안전성을 보장하지만, 성능 비용을 수반합니다.

메커니즘	성능 비용	보장하는 것
Redo 로그 쓰기	매 DML마다 로그 기록	지속성
Undo 로그 쓰기	매 DML마다 이전 값 기록	원자성
COMMIT 시 flush	디스크 동기화 대기	지속성
체크포인트	Dirty Page 일괄 기록	복구 시간 단축

일부 DBMS는 성능을 위해 비동기 커밋(Asynchronous Commit)을 제공합니다. COMMIT 시 로그를 즉시 디스크에 쓰지 않고 잠시 버퍼에 모아두었다가 한꺼번에 쓰는 방식입니다. 지속성이 약간 희생되지만(장애 시 최근 몇 ms의 커밋이 소실될 수 있음), 성능은 크게 향상됩니다. PostgreSQL의 synchronous_commit = off, MySQL의 innodb_flush_log_at_trx_commit = 2 등이 이에 해당합니다.

백업과 복구 전략

디스크 장애에 대비하기 위한 백업 전략을 상세히 살펴보겠습니다.

백업의 종류

전체 백업(Full Backup)은 데이터베이스의 모든 데이터를 복사하는 방식입니다. 복구 시 전체 백업 하나만 있으면 되므로 복구가 간단하지만, 데이터가 클수록 백업 시간이 오래 걸리고 저장 공간이 많이 필요합니다.

증분 백업(Incremental Backup)은 마지막 백업 이후 변경된 데이터만 복사하는 방식입니다. 백업 시간과 저장 공간이 절약되지만, 복구 시 전체 백업 + 모든 증분 백업을 순차적으로 적용해야 합니다.

차등 백업(Differential Backup)은 마지막 전체 백업 이후 변경된 모든 데이터를 복사하는 방식입니다. 증분 백업보다 백업 크기는 크지만, 복구 시 전체 백업 + 마지막 차등 백업만 있으면 됩니다.

백업 전략 비교

일요일: 전체 백업 (100GB)
월요일: 10GB 변경
화요일: 15GB 변경
수요일: 8GB 변경
목요일: 장애 발생!

증분 백업 시
  백업 크기: 월(10GB) + 화(15GB) + 수(8GB) = 33GB
  복구: 전체(100GB) → 월(10GB) → 화(15GB) → 수(8GB) → 4단계

차등 백업 시
  백업 크기: 월(10GB) + 화(25GB) + 수(33GB) = 68GB
  복구: 전체(100GB) → 수(33GB) → 2단계

전체 백업만
  백업 크기: 매일 100GB+ = 300GB+
  복구: 수(100GB+) → 1단계

핫 백업과 콜드 백업

콜드 백업(Cold Backup)은 데이터베이스를 중지한 상태에서 수행하는 백업입니다. 데이터 일관성이 보장되지만, 백업 중 서비스를 이용할 수 없습니다. 소규모 시스템이나 정기 점검 시에 사용합니다.

핫 백업(Hot Backup, Online Backup)은 데이터베이스가 운영 중인 상태에서 수행하는 백업입니다. 서비스 중단 없이 백업이 가능하지만, 백업 중에도 데이터가 변경될 수 있으므로 일관성 보장을 위한 추가 메커니즘이 필요합니다.

핫 백업의 일관성 보장

핫 백업 중 데이터 변경
  백업 시작 ──────────────── 백업 완료
         │                     │
    [테이블 A 복사]  [변경 발생]  [테이블 B 복사]
    A: 시점 1의 데이터        B: 시점 2의 데이터
    → 불일치!

해결: 아카이브 로그 함께 백업
  백업 데이터 + 아카이브 로그 = 일관된 시점으로 복구 가능

PITR (Point-In-Time Recovery)

PITR(Point-In-Time Recovery)은 특정 시점으로 데이터베이스를 복구하는 기술입니다. "어제 오후 3시 상태로 돌려주세요"라는 요청에 대응할 수 있습니다.

PITR 과정

전체 백업 (일요일 00:00)
  ↓ 아카이브 로그 적용
월요일 00:00 상태
  ↓ 아카이브 로그 적용
화요일 00:00 상태
  ↓ 아카이브 로그 적용
화요일 15:00 상태  ← "이 시점까지만 복구하세요" (PITR 대상)
  ×  화요일 15:01 이후의 로그는 적용하지 않음

활용 사례
  - 화요일 15:01에 개발자가 실수로 DELETE FROM users 실행
  - 15:00 시점으로 PITR 수행
  - DELETE 실행 전 상태로 복구!

DBMS별 백업/복구 도구

DBMS	백업 도구	설명
MySQL	mysqldump	논리적 백업 (SQL 덤프)
MySQL	xtrabackup	물리적 핫 백업 (InnoDB)
PostgreSQL	pg_dump	논리적 백업
PostgreSQL	pg_basebackup	물리적 스트리밍 백업
Oracle	RMAN	통합 백업/복구 관리자
SQL Server	BACKUP DATABASE	내장 백업 명령

MySQL 백업/복구 명령

-- 논리적 백업 (mysqldump)
-- 모든 데이터를 SQL 문으로 출력
mysqldump -u root -p mydb > backup.sql

-- 복구
mysql -u root -p mydb < backup.sql

-- 바이너리 로그를 이용한 PITR
mysqlbinlog --stop-datetime="2024-06-15 15:00:00" \
  binlog.000042 | mysql -u root -p mydb

복구 관련 설계 지침

실무에서 장애에 대비한 설계 지침을 정리합니다.

첫째, 백업은 반드시 별도의 물리적 장소에 보관해야 합니다. 같은 서버, 같은 디스크에 백업을 저장하면 디스크 장애 시 백업도 함께 소실됩니다. 클라우드 스토리지나 원격지 서버에 백업을 저장하는 것이 안전합니다.

둘째, 복구 테스트를 정기적으로 수행해야 합니다. 백업이 존재한다고 해서 복구가 반드시 성공하는 것은 아닙니다. 백업 파일이 손상되었거나, 복구 절차에 오류가 있을 수 있습니다. 정기적으로 백업에서 실제 데이터베이스를 복원해보는 DR(Disaster Recovery) 훈련이 필요합니다.

셋째, RPO와 RTO를 비즈니스 요구에 맞게 설정해야 합니다. RPO(Recovery Point Objective)는 "얼마나 최근까지의 데이터를 복구할 수 있는가"이고, RTO(Recovery Time Objective)는 "복구에 얼마나 시간이 걸리는가"입니다.

RPO와 RTO

RPO (Recovery Point Objective)
  "장애 시 최대 얼마만큼의 데이터 손실을 허용하는가?"
  RPO = 0:    실시간 복제 (동기 복제)
  RPO = 1분:  1분 간격 로그 전송
  RPO = 1시간: 1시간 간격 백업
  RPO = 24시간: 1일 1회 백업

RTO (Recovery Time Objective)
  "장애 발생 후 얼마 안에 서비스를 복구해야 하는가?"
  RTO = 0:    자동 페일오버 (Active-Standby)
  RTO = 5분:  준비된 대기 서버
  RTO = 1시간: 백업에서 복원 + 로그 적용
  RTO = 24시간: 수동 복구

비용:  RPO, RTO가 작을수록 → 비용 증가 (더 많은 인프라 필요)

넷째, 아카이브 로그 모드를 활성화해야 합니다. 아카이브 로그가 없으면 마지막 백업 이후의 데이터는 복구할 수 없습니다. 운영 환경에서는 반드시 아카이브 로그를 활성화해야 합니다.

다섯째, 복구 시나리오를 문서화해야 합니다. 장애 유형별로 복구 절차를 사전에 문서화해두면, 실제 장애 발생 시 당황하지 않고 체계적으로 대응할 수 있습니다. "트랜잭션 장애 시", "시스템 장애 시", "디스크 장애 시" 각각에 대한 복구 매뉴얼을 작성하고 정기적으로 업데이트해야 합니다.

장애 유형별 복구 요약

전체 장애 유형과 복구 방법을 한눈에 정리합니다.

장애 유형별 복구 전체 흐름

트랜잭션 장애 (빈번)
┌──────────────┐
│ Undo만 필요  │
│ (ROLLBACK)   │
└──────┬───────┘
       ▼
해당 트랜잭션만 취소
       ▼
시스템 영향 없음

시스템 장애 (가끔)
┌────────────────┐
│ Redo + Undo    │
│ (인스턴스 복구)│
└──────┬─────────┘
       ▼
메모리 소실 복원 + 미커밋 롤백
       ▼
자동 복구 (재시작)

디스크 장애 (드문)
┌────────────────┐
│ 백업 복원      │
│ + 아카이브 로그│
│ + Redo + Undo  │
└──────┬─────────┘
       ▼
전체 데이터 복원
       ▼
수동 개입 필요

데이터베이스의 복구 시스템은 최악의 상황에서도 데이터를 지킨다는 철학 위에 설계되었습니다. WAL로 로그를 먼저 기록하고, Redo로 커밋된 데이터를 살리며, Undo로 커밋 안 된 데이터를 되돌립니다. 체크포인트로 복구 시간을 단축하고, ARIES 같은 정교한 알고리즘으로 정확한 복구를 보장합니다. 정기적인 백업과 복구 테스트는 이 모든 메커니즘의 안전망입니다. 다음 절에서는 Redo 로그의 구조와 WAL(Write-Ahead Logging) 원칙의 구현 세부를 다루겠습니다.

장애의 유형과 복구 원리