233. 회복 (Recovery) - 데이터베이스 복원 원자성 영속성 트랜잭션 오류 장애 복구 ARIES 재실행 취소

핵심 인사이트: (232번 지옥에서 DB를 살려내는 응급실) "야! 232번에서 정전이 나서 메모리가 타버리고 서버가 뻗었다(시스템 장애)! 재부팅 했더니 방금 전까지 고객들이 송금 누르던 돈 계산 데이터가 허공으로 싹 다 날아갔다! 어떡할래?! 은행 망했냐?!" "걱정 마라!! DB가 괜히 DB냐! DB 안에는 신이 내려준 **'회복(Recovery)'**이라는 심폐소생술 마법이 무조건 돌아가고 있어!! 서버가 다시 켜지는 순간, 1초의 틈도 없이 DB 엔진이 구석에 꽁꽁 숨겨둔 '블랙박스(로그 파일)'를 미친 듯이 뒤져서, 죽기 직전까지 송금 완료(COMMIT) 도장 찍었던 놈들은 억지로 멱살 잡고 끝까지 다시 반영(Redo)해 살려내고!! 덜 익은 채로 중간에 뻗어버린 찌끄러기(미완성) 놈들은 싹 다 파내서 원래 0원으로 완벽하게 지워(Undo) 버려!! 이 짓을 해야만 통장이 반갈죽 되지 않고 완벽한 모순 없는 상태(일관성)로 부활하잖아!!" 우주가 멸망해도 트랜잭션의 원자성과 영속성을 지켜내는 십자가, 회복(Recovery)이다.

Ⅰ. 회복이 없으면 ACID 헌법이 붕괴한다

• 데이터베이스는 193~196번에서 배운 트랜잭션 4대 특성(ACID)을 목숨 걸고 지켜야 합니다.
• 원자성(Atomicity): "All or Nothing". 10만 원을 빼고 10만 원을 넣는 도중에 서버가 죽으면? 빼기만 하고 넣지를 못해 10만 원이 증발합니다. 무조건 처음으로 100% 롤백(취소) 시켜야 원자성이 지켜집니다.
• 영속성(Durability): "한 번 COMMIT 치면 지구가 박살 나도 보존된다." COMMIT 쳤는데 하드디스크에 저장되기 직전에 정전으로 메모리가 증발했다? 무조건 다시 실행해서 하드에 새겨놔야 영속성이 지켜집니다.

Ⅱ. 회복 (Recovery)의 개념 🌟

• 개념: 데이터베이스 시스템에 232번과 같은 장애(트랜잭션, 시스템, 미디어 장애)가 발생하여 데이터가 훼손되거나 모순 상태에 빠졌을 때, 장애가 발생하기 이전의 100% 모순 없는 '안전하고 일관된 상태(Consistent State)'로 시스템을 완벽하게 되돌려 복원해 내는 데이터베이스 관리 시스템(DBMS)의 핵심 기능입니다.

Ⅲ. 회복을 멱살 잡고 캐리하는 2대 흑마법 (스포일러) 🌟 핵심 기출 🌟

DB가 기절했다가 눈을 번쩍 떴습니다. 어떻게 살려낼까요? 234번, 235번에서 단독 문서로 딥하게 팔 2가지 마법을 씁니다.

1. Redo (재실행 / 전진 복구 Roll-forward) - 영속성의 수호자

• 타겟: 불 꺼지기 0.1초 전에 "결제 완료(COMMIT)!" 도장은 쾅 찍었는데, 너무 급하게 죽느라 디스크(쇳덩어리 원본)에 글씨를 채 못 적고 메모리만 타버린 불쌍한 트랜잭션들.
• 조치: "야 ㅆㅂ 너 COMMIT 쳤잖아! 영속성(Durability) 지켜야지!" DB가 일기장(로그)을 보고 그 놈이 했던 덧셈 뺄셈 작업을 똑같이 **다시 재실행(Redo)**해서, 어떻게든 쇳덩어리 디스크에 억지로 기록을 쑤셔 넣어 영구 보존 시킵니다.

2. Undo (취소 / 후진 복구 Roll-backward) - 원자성의 수호자

• 타겟: 불 꺼지기 전에 열심히 엑셀을 고치고 있었는데, 아직 "결제 완료(COMMIT)" 도장을 못 찍은 덜 익은 미완성 상태로 같이 기절해 버린 쓰레기 트랜잭션들.
• 조치: "야! 너 아직 도장(COMMIT) 안 찍었잖아! 근데 중간에 쓴 더러운 데이터가 디스크에 묻었어? 원자성(Atomicity) 지켜야지! All or Nothing 이니까 너는 Nothing이야!" 일기장(로그)을 거꾸로 뒤지면서, 그놈이 덮어썼던 찌끄러기 흔적을 싹 다 파내어 수정하기 이전의 깨끗한 과거 상태로 완벽하게 취소(Undo) 시켜버립니다.

Ⅳ. 어떻게 기억해 낼까? (로그 파일의 절대성)

• 정전돼서 메모리가 날아갔는데 DB가 Redo와 Undo를 무슨 수로 귀신같이 알아내서 할까요?
• 236번에서 배울 **'WAL (Write-Ahead Logging)'**이라는 목숨 같은 룰 때문입니다. DB는 엑셀을 고치기 전에 하늘이 두 쪽 나도 "나 지금 이거 고친다!"라는 일기장(Log)부터 디스크 깊은 곳에 먼저 안전하게 써둡니다. 이 일기장이 바로 회복의 유일한 나침반입니다.

📢 섹션 요약 비유: 회복(Recovery) 기능은 끔찍한 교통사고가 났을 때 출동하는 **'시간 조작 구급대원 2인조'**와 같습니다. 고속도로(DB 서버)에서 트럭 10대가 달리다 연쇄 추돌이 나며 모든 차가 멈췄습니다(시스템 장애 발생). 10초 뒤, 헬기를 타고 '회복 구급대원'이 출동합니다. 구급대원은 차의 블랙박스(로그 파일)를 미친 듯이 뒤집니다. **1번 대원(Redo)**은 톨게이트 요금을 이미 다 냈는데(COMMIT 완료) 사고 여파로 톨게이트 밖으로 튕겨 나간 억울한 차들을 찾습니다. "너희는 요금 냈으니 통과야!" 라며 차의 시동을 억지로 걸어 기어코 목적지까지 밀고 가서 도착(영속성 보장)시켜버립니다. 반면 **2번 대원(Undo)**은 요금소에서 돈을 반쯤 내다 말고 사고가 나서 뻗어버린 미완성 차들을 찾습니다. "너희는 아직 결제 끝(COMMIT) 안 났어! 차 빼!" 라며 차에 사슬을 묶고 톨게이트 진입 1시간 전 과거의 톨게이트 밖으로 질질 끌어당겨(원자성 보장) 사고의 흔적 자체를 100% 깔끔하게 지워버립니다. 이 두 명의 무자비한 전진(Redo)과 후진(Undo) 교통정리 덕분에, 도로는 사고가 났었는지조차 모르게 다시 차들이 매끄럽게 쌩쌩 달리는 평화로운 일관성 상태(Consistent State)로 1초 만에 완벽 복원되는 것입니다.