244. LSN (Log Sequence Number) - 로그 레코드 고유 식별 번호 ARIES 복구 데이터베이스 회복 시간 순서 추적 Redo Undo

핵심 인사이트: (243번 ARIES 복구를 가능하게 하는 마법의 번호표) "야! 243번에서 로그 일기장을 거꾸로 읽으면서 Undo(취소) 청소를 한다며? 근데 로그 파일이 100억 줄인데 '홍길동 10만 원 입금' 찌끄러기를 무슨 수로 귀신같이 찾아서 지우냐?! 똑같은 10만 원 입금 로그가 수만 개일 텐데 헷갈려서 엉뚱한 거 지우면 은행 파산이야!! DB 엔진이 천재라고? 천재가 아니라 **'절대 번호표(LSN)'**의 노예일 뿐이야!! 네가 엑셀을 한 칸 고치고 로그를 1줄 쏠 때마다, DB는 그 로그 1줄에다가 '00001번, 00002번, 15301번' 하고 절대 겹치지 않는 무한대의 일련번호(LSN) 도장을 쾅쾅 찍어버려!! 심지어 그 번호표를 쇳덩어리 엑셀 원본(Data Page) 이마에도 똑같이 박아놔!! 그럼 나중에 서버가 터져도 '어? 엑셀 이마엔 15301번이라고 적혀있는데, 내 로그 번호는 15305번이네? 아, 4줄이 디스크에 반영 안 되고 날아갔구나!' 하고 1초 만에 파악해서 Redo/Undo의 정확한 좌표를 조준 타격할 수 있잖아!!" 로그와 디스크를 묶어내는 절대 좌표이자 시간의 나침반, LSN이다.

Ⅰ. 거대한 로그 바다의 미아 (어디까지 복구했지?)

  • 로그(Log) 파일에는 1초에 수만 줄의 변경 기록이 쌓입니다.
  • 서버가 뻗었다가 재부팅하고 복구(Redo)를 하려는데, "내가 100억 줄의 로그 중에 도대체 '몇 번째 줄' 로그까지 디스크에 안전하게 덮어쓰고 뻗었더라?" 기억이 안 납니다. 위치를 놓치면 이미 저장된 걸 또 Redo해서 값이 중복(모순)되거나, 해야 할 걸 빼먹게 됩니다.

Ⅱ. LSN (Log Sequence Number)의 개념 🌟

  • Log (로그) + Sequence (순차적인) + Number (번호)
  • 개념: 데이터베이스 시스템에서 생성되는 **모든 로그 레코드(일기장 1줄 1줄)에 부여되는 '절대 중복되지 않고 영원히 1씩 증가하기만 하는 고유한 일련번호(식별자)'**입니다.
  • 존재 이유: 이 번호표 덕분에 DB는 수백억 줄의 로그 속에서 트랜잭션의 정확한 시간적 선후 관계(누가 먼저 일어났나)를 완벽하게 추적하고 식별할 수 있습니다.

Ⅲ. LSN이 멱살 잡고 캐리하는 3대 기적 🌟 핵심 🌟

LSN은 단순한 로그 번호가 아니라, 디스크(원본)와 로그(블랙박스)를 이어주는 '마법의 끈'입니다.

1. 페이지(디스크)와의 찰떡 동기화 (Page LSN)

  • 내가 엑셀의 3번 페이지를 뜯어고쳐 '5만 원'으로 바꿉니다.
  • 이때 로그 파일에 <15000번(LSN): 5만 원으로 바꿈> 이라는 1줄이 적힙니다.
  • 핵심 기술: DB는 진짜 디스크(원본)의 3번 페이지 꼭대기 귀퉁이(Header)에도 "나를 마지막으로 건드리고 간 로그 번호는 '15000번'이다 (Page LSN = 15000)" 라고 무조건 쾅! 박아둡니다. 원본 데이터 자체에 번호표 문신을 새기는 짓입니다.

2. Redo(재실행) 헛발질 원천 차단 🌟 기출 🌟

부팅 후 243번 ARIES 알고리즘의 Redo 페이즈가 돌아갑니다.

  • 엔진이 로그 15000번 줄을 읽었습니다. "오, 3번 페이지에 5만 원 적으래(Redo)!"
  • 엔진이 디스크의 3번 페이지를 찾아가 이마를 봅니다.
  • 경우 1: 이마에 Page LSN = 14999 라고 적혀있습니다. ➜ "아! 로그는 15000번인데 디스크는 14999번으로 옛날 거네! 벼락 맞아 못 적었구나! 당장 5만 원으로 Redo 덮어써라!"
  • 경우 2: 이마에 Page LSN = 15000 (또는 더 큰 번호)이라고 적혀있습니다. ➜ "어? 이미 15000번 로그까지 완벽하게 디스크에 저장되어 있네! 굳이 헛수고할 필요 없지! 이 로그는 스킵(Redo 무시)하고 다음 로그로 넘어가!" (극강의 복구 최적화)

3. Undo(취소) 역추적의 완벽한 족적 (Prev LSN)

  • 하나의 트랜잭션 T1이 엑셀을 10번 고치면, 로그도 10줄(LSN 1번, 5번, 99번...)이 띄엄띄엄 생깁니다.
  • 뻗은 T1을 통째로 Undo(취소) 하려면? 로그 1줄마다 꼬리에 꼬리를 무는 **"내 앞전 작업의 로그 번호는 5번이었어(Prev LSN = 5)"**라는 포인터 사슬을 남겨둡니다. DB 엔진은 이 꼬리표(LSN)만 쥐고 거꾸로 미친 듯이 점프하며 역추적해, 10개의 찌끄러기를 0.001초 만에 완벽하게 박살 냅니다.

Ⅳ. 236번 WAL (Write-Ahead Logging)과의 만남

  • WAL 원칙의 진짜 정의는 이겁니다. "어떤 페이지(디스크)를 덮어쓰기 전에, 그 페이지 이마에 적힌 Page LSN 번호보다 '작거나 같은' 모든 로그 파일들이 무조건 물리적인 하드디스크에 안전하게 쓰여(Flush) 있어야만 한다!" 이것이 깨지면 복구가 불가능해집니다.

📢 섹션 요약 비유: **LSN(로그 일련번호)**은 택배 상하차 알바(DB 엔진)를 구원하는 **'화물칸 무적의 누적 바코드 스티커'**입니다. 알바생이 창고(메모리)에서 트럭(하드디스크)으로 택배 상자 10만 개를 나르고 있습니다. 상자마다 무조건 '1번, 2번, 3번(LSN)' 순서대로 바코드 스티커를 붙이고, 똑같은 바코드를 사무실 장부(로그 파일)에도 찍습니다. 어느 날 알바생이 100번 상자를 들고 가다 지진이 나서 뻗어버렸습니다(시스템 장애). 10분 뒤 깨어난 알바생은 멘붕에 빠집니다. "내가 트럭에 상자를 몇 번까지 싣고 뻗었더라?" 만약 스티커(LSN)가 없었다면 상자 10만 개를 일일이 까보며 대조(미친 Redo 시간)해야 합니다. 하지만 알바생은 트럭(디스크) 맨 위에 실린 상자의 바코드를 봅니다. "어? 트럭에 마지막으로 실린 게 '90번(Page LSN)' 상자네? 근데 사무실 장부(로그)를 보니 난 '100번' 상자까지 옮겼다고 적어놨었잖아! 아하, 91번부터 100번 상자까지 10개가 지진 나서 트럭에 못 실리고 땅에 떨어졌구나!!" 알바생은 1번~90번 장부는 거들떠보지도 않고 스킵한 뒤(Redo 패스), 오직 91번 상자부터 100번 상자까지만 정확히 조준 타격하여 트럭에 다시 실어(최적화된 Redo 복구) 복구 작업을 단 1초 만에 완벽하게 끝마치는 궁극의 나침반 번호표입니다.