232. 데이터베이스 장애 유형 - 트랜잭션 장애 시스템 장애 미디어 장애 오류 복구 회복(Recovery) 원인 물리적 손상

핵심 인사이트: (DB 복구의 3대 적) 신입 개발자가 묻는다. "선배님! DB가 뻑나서 죽었다는데 어떻게 살리죠?!" 선배가 뒤통수를 후려친다. "야!! 병원에 환자가 왔는데 무조건 배부터 가를래?! 어디가 부러졌는지 진단(장애 유형)부터 해!! 개발자 네 놈이 코드를 발로 짜서 쿼리 1줄 치다가 0으로 나눠서 앱 혼자 픽 쓰러진 건지(트랜잭션 장애), 아니면 벼락이 떨어져서 램(RAM)에 올라간 메모리가 통째로 날아간 건지(시스템 장애), 그도 아니면 지진이 나서 하드디스크 쇳덩어리 자체가 완전히 박살 나서 불탄 건지(미디어 장애)!! 이 3가지 꼬라지에 따라 빨간약을 바를지 수술실에 들어갈지 복구(Recovery) 방법이 하늘과 땅 차이로 갈라진단 말이야!!" DB가 피를 토하며 쓰러지는 3가지 지옥의 시나리오, 데이터베이스 장애 유형이다.

Ⅰ. 세상에서 가장 슬픈 3가지 죽음

데이터베이스는 1년 365일 24시간 멈추면 안 되는 심장입니다. 하지만 결국 인간이 만든 소프트웨어와 쇳덩어리(하드웨어)의 결합체이므로 무조건 뻑이 납니다. 복구(Recovery) 기술을 배우기 전에, 적(장애)이 어떤 형태로 쳐들어오는지 급을 나눠야 합니다.

Ⅱ. 데이터베이스 장애의 3대 유형 🌟 기출 빈출 🌟

손상의 스케일(영향 범위)이 작은 놈부터 가장 큰 놈(우주 멸망) 순서입니다.

1. 트랜잭션 장애 (Transaction Failure) - "가장 하찮고 귀여운 에러"

  • 영향 범위: 딱 트랜잭션 1개, 즉 **'네가 짠 프로그램 1개'**만 조용히 죽는 현상입니다. DB 서버 기계 자체는 아주 멀쩡합니다.
  • 원인:
    • 내부 로직 에러: 개발자가 코드를 발로 짜서 0으로 나누기, 무한 루프가 터지거나, 존재하지 않는 회원을 찾겠다고 미친 쿼리를 쐈을 때.
    • 논리적 모순: 219번 데드락(교착상태)에 걸려서 DB 엔진이 몽둥이로 때려죽일 때.
  • 해결(피해 복구): 아주 쉽습니다. 서버를 껐다 켤 필요도 없습니다. 그냥 죽어버린 그놈의 쿼리가 그동안 해놓은 찌끄러기 작업만 슥 UNDO(롤백) 해서 태초마을로 싹 지워주면 아무 일 없었다는 듯이 DB는 팽팽하게 잘 돌아갑니다.

2. 시스템 장애 (System Failure) - "기억상실증 (메모리 증발)" 🌟

여기서부터 DBA(관리자)의 심장이 덜컥 내려앉습니다.

  • 영향 범위: 하드디스크 원본(쇳덩어리)은 살아있는데, 메인 메모리(RAM 버퍼)에 띄워놓고 열심히 작업 중이던 데이터들이 한 방에 날아가며 데이터베이스 서버(인스턴스) 자체가 픽 하고 전체가 기절해 버리는 대형 사고입니다.
  • 원인:
    • 데이터센터에 정전(Power Failure)이 나서 컴퓨터 전원이 뽑혀 나갔을 때.
    • 리눅스 운영체제(OS)가 버그로 블루스크린(커널 패닉)을 뿜으며 강제 재부팅 될 때.
  • 비극: 램(RAM)은 전기가 끊기면 뇌세포가 0.1초 만에 하얗게 타버립니다. 내가 방금 "회원가입 완료!"를 외쳤지만 아직 느려 터진 하드디스크에 저장되지 않고 램에만 떠 있던 데이터들은 허공으로 영구 증발해 버립니다.
  • 해결(피해 복구): 234번에서 배울 **Redo(다시 하기)**와 Undo(취소) 마법을 써서 잃어버린 뇌세포 퍼즐을 디스크의 로그 조각을 통해 영혼까지 긁어모아 복원해야 합니다.

3. 미디어 장애 (Media Failure) - "하드디스크 분쇄 (우주 멸망)" 🌟

DB 관리자 100명이 당장 사표를 써야 하는 지옥의 묵시록입니다.

  • 영향 범위: 컴퓨터를 껐다 켜도 안 됩니다. 데이터베이스의 원본 데이터가 영구적으로 새겨져 있는 쇳덩어리 창고, 즉 비휘발성 하드디스크(HDD)나 SSD가 물리적으로 완전히 빠개지거나 타버린 상태입니다.
  • 원인:
    • 하드디스크 헤드가 긁혀 배드섹터가 터짐, 화재로 디스크가 잿더미가 됨.
  • 비극: 이건 논리적 복구로 답이 없습니다. 원본 데이터의 쇳덩어리 집 자체가 날아갔기 때문입니다.
  • 해결(피해 복구): 유일한 동아줄은 어젯밤 12시에 다른 건물 비밀 창고에 빼돌려둔 **'백업(Dump) 테이프'**와 '아카이브 로그(Archive Log)' 파일뿐입니다. 텅 빈 새 하드디스크를 사 와서 어젯밤 복사본을 들이붓고 10시간짜리 롤 포워드(Roll-forward) 노가다를 돌려 힘겹게 부활시켜야 합니다. (242번 스포일러)

📢 섹션 요약 비유: 데이터베이스 장애 3형제는 회사의 업무가 마비되는 **'3가지 빡침의 단계'**입니다. 1. 트랜잭션 장애는 신입 사원 1명이 책상에서 엑셀을 치다가 졸아서 커피를 키보드에 쏟은 **'개인적 뻘짓'**입니다. 회사 건물(DB 시스템)은 멀쩡하니 신입 사원만 쫓아내고 책상(메모리 찌끄러기)만 행주로 쓱 닦아내면(UNDO 롤백) 끝나는 아주 귀여운 사고입니다. 2. 시스템 장애는 회사가 있는 동네 전체에 벼락이 쳐서 **'건물 정전(메모리 증발)'**이 터진 대형 사고입니다. 컴퓨터 전원이 툭 나가버려서 전 직원이 "아 ㅆㅂ 나 방금 3시간 동안 친 거 저장(디스크) 안 눌렀는데 날아갔다!!"라며 울부짖는 단체 기억상실증입니다. 다행히 전기가 들어오면 서랍에 박아둔 임시 저장 파일(로그)을 꺼내 피눈물을 흘리며 아까 친 걸 다시 쳐서(Redo) 복구해 내야 합니다. 3. 미디어 장애는 지진이 나서 **'회사 건물과 엑셀 원본 하드디스크 쇳덩어리 자체가 산산조각 나서 잿더미(디스크 물리 파괴)'**가 된 우주 멸망급 재앙입니다. 이건 임시 저장 파일이고 나발이고 다 같이 타버렸으므로 답이 없습니다. 어젯밤 퇴근할 때 사장님이 옆 동네 비밀 창고(백업 테이프)에 몰래 빼돌려 복사해 둔 엑셀 종이를 들고 와, 처음부터 건물을 새로 짓고 철야를 하며 장부를 전부 다시 베껴 적어야(미디어 복구) 간신히 회사가 부활하는 궁극의 지옥 시나리오입니다.