455. 리두 (Redo) 로그와 아카이브 (Archive)

⚠️ 이 문서는 서버에 벼락이 떨어지거나 하드디스크가 물리적으로 불타 없어지는 대재앙 속에서도 데이터베이스가 "지금까지 네가 저장했던 모든 데이터를 다시 살려내 주마!"라고 큰소리칠 수 있게 해주는 궁극의 생명줄, '리두 로그'와 '아카이브 로그'의 복구 메커니즘을 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: 리두(Redo) 로그는 트랜잭션이 변경한 '새로운 값(New Value)'들을 시간순으로 무조건 적어두는 블랙박스 같은 파일이다.
  2. 가치: 정전 등으로 서버가 꺼졌을 때, 이 로그를 처음부터 끝까지 비디오 테이프 재생하듯이 쫙 돌려보면(Roll Forward) 서버가 죽기 직전의 완벽한 최신 상태로 100% 복구(Recovery)할 수 있다.
  3. 아카이브 로그: 리두 로그 파일이 꽉 차서 덮어쓰기 전에, 그 내용을 안전한 다른 디스크나 테이프(Tape)에 영원히 보관해 두는 '로그의 복사본'이다. 디스크 자체가 타버리는 물리적 장애 시 필수적이다.

Ⅰ. 개요: 잃어버린 기억을 찾는 법 (Context & Necessity)

"어젯밤 12시에 DB 서버 전원이 나갔어. 데이터 살려내!"

  • 다행히 메모리(RAM)에 있던 최신 데이터가 날아가기 전에, DB는 0.1초마다 **'리두 로그(Redo Log)'**라는 하드디스크 파일에 "누가 1만 원 입금했음", "누가 5만 원 출금했음"이라고 다 적어두었다 (WAL 방식 - 456번 문서).

DB를 다시 켜면 회복(Recovery) 관리자가 출동한다.

  • 1단계: "자, 어제저녁 6시 백업본(Data File) 가져와."
  • 2단계: "그 백업본 위에다가, 저녁 6시부터 밤 12시까지 쌓인 리두 로그를 비디오테이프 틀듯이 처음부터 끝까지 그대로 다시 실행(Redo)해!"
  • 결과: 서버는 벼락 맞기 직전인 밤 12시의 상태로 완벽하게 타임머신을 타고 돌아온다.

📢 섹션 요약 비유: 리두 로그는 헨젤과 그레텔이 숲속에 떨어뜨려 둔 **'하얀 조약돌'**과 같습니다. 갑자기 길을 잃거나 눈앞이 캄캄해져도, 떨어뜨린 조약돌(로그)만 순서대로 주워가면서 걸어가면(Redo) 원래 목적지에 완벽하게 도착할 수 있습니다.

Ⅱ. 언두(Undo)와 리두(Redo)의 역할 분담 ★

DB 장애 복구 시, 언두와 리두는 완벽한 파트너십을 보여준다.

  • 정전 발생 시점
    • T1: 이미 COMMIT을 완료함.
    • T2: 열심히 데이터 고치는 중이었음 (COMMIT 안 함).
  • 복구 과정
    1. Redo (다시 실행): 일단 리두 로그를 다 긁어모아서 T1이든 T2든 가리지 않고 메모리에 다 때려 부어서 정전 직전의 상태로 똑같이 만든다. (무조건 직진)
    2. Undo (취소): 가만 보니 T2는 COMMIT 도장을 안 찍고 죽었다. T2의 변경 사항은 언두 로그(454번 문서)를 보고 취소(Rollback)시켜서 다시 옛날 값으로 빼버린다.
  • 결론: COMMIT된 T1만 살아남고, 덜 끝난 T2는 완벽하게 사라진다. (ACID 완벽 보장)

Ⅲ. 아카이브 로그 (Archive Log): 최후의 보루

"그런데 만약, DB가 들어있는 하드디스크 1번 자체가 불타서 완전히 박살 났다면?"

  • 1번 하드디스크 안에는 '원본 데이터(Data File)'도 있고 '리두 로그(Redo Log)'도 있었다. 둘 다 타버렸으니 복구가 불가능하다. (미디어 장애)

이때 등장하는 것이 **아카이브 로그 (Archive Log)**다.

  • 리두 로그 파일은 보통 3개 정도 만들어놓고 꽉 차면 1번부터 다시 덮어쓴다 (순환 방식).
  • **아카이브 모드(ARCHIVELOG Mode)**를 켜두면, 1번 리두 로그가 꽉 차서 2번으로 넘어가는 순간, 1번 리두 로그의 복사본을 **저 멀리 있는 안전한 2번 하드디스크(또는 외부 스토리지)**에 영구적으로 백업해 둔다.
  • 하드디스크 1번이 불타도, 새로 하드디스크를 사 와서 옛날 백업본을 깐 뒤 아카이브 로그 1년 치를 며칠 동안 밤새도록 Redo(재생)하면 데이터베이스는 기적처럼 살아난다.
┌──────────────────────────────────────────────────────────────┐
│           장애 복구 시 Redo (Roll-Forward) 과정 시각화                 │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│ [ 📦 지난주 일요일 백업본 (Data File) ]                            │
│           │                                                  │
│           ▼                                                  │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ 🚀 Roll-Forward (Redo 연산)                                │ │
│ │  + 월요일 아카이브 로그 재생 (김철수 가입 등)                    │ │
│ │  + 화요일 아카이브 로그 재생 (박영희 탈퇴 등)                    │ │
│ │  + 수요일 아카이브 로그 재생 ...                                │ │
│ │  + 오늘 아침 리두 로그(Redo Log) 재생                           │ │
│ └──────────────────────────────────────────────────────────┘ │
│           │                                                  │
│           ▼                                                  │
│ [ 🛡️ 오늘 장애 발생 직전의 완벽한 최신 DB 상태로 부활! ]               │
└──────────────────────────────────────────────────────────────┘

Ⅳ. 결론

"데이터를 지키는 비용은 비싸지만, 데이터를 잃는 비용은 회사를 파산시킨다." 리두 로그와 아카이브 로그는 DBA(데이터베이스 관리자)의 목숨과도 같은 시스템이다. 이 로그 시스템을 끄면 DB 쓰기 속도는 2배 이상 빨라진다 (No-logging 모드). 하지만 그 대가는 '장애 시 데이터 100% 영구 유실'이다. 따라서 실운영(Prod) DB에서는 어떤 일이 있어도 아카이브 로그 모드를 켜두어야 하며, 이 로그 파일들이 디스크 용량을 꽉 채워 DB가 뻗는 일이 없도록 주기적으로 테이프나 외부 스토리지(S3 등)로 백업하고 비워주는(Purge) 스크립트를 짜는 것이 인프라 운영의 핵심이다.

📌 관련 개념 맵

  • 관련 특성: 영속성 (Durability - 444번 문서)
  • 대칭 개념: Undo Log (언두 로그 - 454번 문서)
  • 보장 기법: WAL (Write-Ahead Logging - 456번 문서)
  • 장애 분류: 트랜잭션 장애 (Undo로 해결) vs 시스템/미디어 장애 (Redo/Archive로 해결)

👶 어린이를 위한 3줄 비유 설명

  1. 리두 로그는 체스 게임을 할 때, 내가 말(체스 피스)을 어떻게 움직였는지 종이에 순서대로 다 적어두는 '기보(기록장)'와 같아요.
  2. 동생이 장난치다 체스판을 엎어버렸어도, 그 종이(리두 로그)만 보고 똑같이 처음부터 말을 움직이면 원래 체스판을 완벽하게 다시 만들 수 있죠.
  3. 아카이브 로그는 그 기록장 종이가 다 차면 버리지 않고, 엄마 방에 있는 안전한 금고에 평생 보관해 두는 거랍니다!