234. Redo (재실행) - 장애 발생 후 커밋된 트랜잭션 롤포워드(Roll-forward) 영속성(Durability) 보장 로그 기반 회복 데이터베이스 복구

핵심 인사이트: (233번 회복의 첫 번째 칼날) 내가 쇼핑몰에서 100만 원짜리 명품백 결제 버튼을 눌렀다. 화면에 "결제 완료!(COMMIT)"가 떴다. 나는 기분 좋게 폰을 껐다. 근데 그 찰나의 순간, 네이버 서버실에 벼락이 떨어져서 정전(시스템 장애)이 됐다!! 10분 뒤 켜진 서버의 하드디스크를 까봤더니, 아까 "결제 완료" 쳤던 내 영수증이 디스크에 안 적혀있고 증발해 버렸다?! 내가 돈 낸 기록이 날아갔다!! 빡친 DB 엔진이 소리친다. "야 ㅆㅂ!! 196번 영속성(Durability) 원칙 잊었냐?! '고객한테 한 번 COMMIT 도장 찍어줬으면, 1초 뒤에 지구가 반으로 갈라져도 그 데이터는 하드디스크에 영구 보존되어야 한다'고!! 당장 구석탱이에 몰래 적어둔 블랙박스 일기장(로그 파일) 다 뒤져!! 아까 '결제 완료'라고 적어둔 놈 찾아서, 걔가 쳤던 100만 원 뺄셈 쿼리 처음부터 끝까지 똑같이 **다시 실행(Redo)**시켜서 쇳덩어리에 기어코 억지로 쑤셔 박아 영원히 살려내라!!" 억울하게 죽은 성공자를 예토전생시키는 불사의 부활술, Redo다.

Ⅰ. 디스크와 메모리의 치명적 속도 차이 (왜 날아갈까?)

• 우리가 UPDATE를 치고 COMMIT 도장을 쾅 찍어도, DB는 멍청하고 느린 쇳덩어리 하드디스크(Data File)에 그 즉시 글씨를 새겨 넣지 않습니다. 속도가 너무 느려서 서버가 터지기 때문입니다.
• 대신, 번개처럼 빠른 메모리(RAM) 버퍼에만 쓱 수정해 놓고 "완료!"라고 구라를 칩니다. 그리고 모아뒀다가 나중에 한가할 때 디스크로 스윽 내보냅니다(Flush).
• 비극의 틈새: 이 메모리에만 떠 있고 디스크에 닿기 전의 아슬아슬한 그 찰나의 순간에 서버에 **벼락(정전)**이 치면?! 방금 전 COMMIT 쳤던 수만 건의 성공한 데이터들이 메모리와 함께 허공으로 영구 증발해 버리는(영속성 박살) 대재앙이 터집니다.

Ⅱ. Redo (재실행 / Roll-forward)의 개념 🌟

• 개념: 시스템 장애로 뻗었다가 재부팅 되었을 때, 장애 발생 직전까지 성공적으로 'COMMIT(완료)' 도장을 찍었음에도 불구하고, 물리적 디스크에 데이터가 미처 기록되지 못하고 메모리상에서 억울하게 증발해 버린 트랜잭션들을 찾아내어, 로그(Log) 파일의 기록을 똑같이 '다시 100% 똑같이 재실행(Redo)'함으로써 디스크에 강제로 데이터를 덮어쓰고 쇳덩어리를 최신 상태로 밀고 나가는(Roll-forward) 회복 기법입니다.

Ⅲ. Redo의 절대 임무: 영속성(Durability) 사수 🌟 핵심 기출 🌟

• 트랜잭션 ACID 원칙 중 **영속성(Durability)**을 지켜내는 유일하고도 절대적인 무기입니다. (시험에서 Redo = 영속성 매칭은 100% 나옵니다.)

Ⅳ. 어떻게 부활시킬까? (블랙박스 로그의 마법)

• 메인 메모리가 날아갔는데 어떻게 과거의 쿼리를 똑같이 재실행(Redo) 할까요?
• DB는 잔머리의 대가입니다. 메인 엑셀은 하드디스크에 늦게 적더라도, "나 방금 100만 원 뺐음" 이라는 한 줄짜리 메모(Log Record)만큼은 하늘이 두 쪽 나도 무조건 디스크 구석의 딴딴한 블랙박스(Log File)에 가장 먼저 빛의 속도로 꽂아 넣습니다. (이게 236번 WAL 규약입니다.)
• 재부팅 된 DB는 눈을 뜨자마자 이 블랙박스 로그부터 뒤집니다.
• Redo 검사 로직: "로그에 <T1, START>는 찍혀있는데... 쭉 보니까 <T1, COMMIT> 도장도 찍혀있네?! 근데 디스크를 까보니 T1이 쓴 100만 원 데이터가 없잖아!! 이 억울한 놈!! 로그에 적힌 100만 원 빼기 명령을 지금 즉시 똑같이 Redo(재실행) 해서 디스크에 쾅 박아버려라!!"
• 이렇게 일기장(로그)을 보고 똑같이 앵무새처럼 따라 하며 앞으로 쫙쫙 밀고 나가서(Roll-forward) 현재 시간으로 데이터 복원을 끝마칩니다.

📢 섹션 요약 비유: **Redo(재실행)**는 화재 현장에서 불타버린 소설책을 **'작가의 비밀 일기장을 보고 토시 하나 안 틀리고 다시 타이핑해 내는 미친 복원 작업'**입니다. 소설가(트랜잭션)가 "소설 1장 끝!(COMMIT 완료)"을 외쳤습니다. 근데 인쇄소로 넘기기 전에 출판사(메인 메모리)에 불이 나서 소설 원고가 재가 되어 날아갔습니다(시스템 장애). 소설 1장은 영원히 역사에 남아야(영속성 Durability) 하는데 큰일 났습니다. 이때 편집자(DB 엔진)가 작가가 평소에 몰래몰래 매일 문장을 적어두던 **'절대 타지 않는 티타늄 비밀 일기장(로그 파일)'**을 금고에서 찾아냅니다. 편집자는 일기장을 펼쳐보고, 작가가 불타기 직전까지 "1장 끝(COMMIT)"이라고 적어놓은 부분을 확인합니다. "이 문장들은 완성이 끝난 진짜 문장들인데 억울하게 탔네!" 편집자는 일기장에 적힌 글씨를 보고 워드 프로세서에 토시 하나 안 틀리고 똑같이 처음부터 끝까지 미친 듯이 타자(Redo 재실행)를 쳐서 복구해 냅니다. 과거의 조각을 모아 죽기 전의 완성된 미래 상태로 쫙 밀어붙이는(Roll-forward 전진 복구), 단 1바이트의 성공한 데이터도 우주에서 허투루 증발시키지 않겠다는 DB의 집념 어린 헌신입니다.