[PostgreSQL] PANIC 체크포인트 레코드 오류

PANIC: could not locate a valid checkpoint record

유형: 일반오류형 · 시스템 레벨 치명 오류 (DB 프로세스 기동 불가)

1️⃣ 대표 오류 메시지

PANIC: could not locate a valid checkpoint record

2️⃣ 언제 발생하나

이 오류는 PostgreSQL 재기동 시점에 발생합니다.
서버 프로세스가 시작되면서 WAL을 기반으로 마지막 체크포인트부터 Redo(재적용)를 수행해야 하는데, 유효한 체크포인트 레코드를 찾지 못하면 즉시 PANIC 상태로 중단됩니다.

• WAL 파일 손상 또는 일부 유실
• 스토리지 장애(디스크 오류, 컨트롤러 문제)
• fsync 보장이 깨진 파일시스템/마운트 옵션
• CIFS / NFS / NAS 등 PostgreSQL 비권장 스토리지 사용

중요한 특징
- DB가 “조금 이상”한 상태가 아님
- PostgreSQL이 데이터 무결성을 보장할 수 없다고 판단하여
- 스스로 기동을 거부하는 상황

3️⃣ 왜 이 오류가 고급 장애인가

이 문제는 SQL, 설정 파라미터, 세션 문제가 아닙니다.
PostgreSQL 내부의 WAL → Checkpoint → Redo 흐름이 구조적으로 깨졌음을 의미합니다.

고급 포인트
- 데이터 파일보다 WAL/체크포인트 무결성이 핵심
- DB는 “일부 데이터 손상”보다 “전체 중단”을 선택
- 복구 절차를 잘못 선택하면 영구 데이터 손실 발생

즉, 이 단계의 오류는 DB 내부 구조를 이해하지 못한 상태에서 조치하면 안 되는 영역입니다.

4️⃣ 운영자가 절대 하면 안 되는 행동

❌ WAL 파일을 무작정 삭제
→ 체크포인트 이전/이후의 변경 이력을 완전히 잃을 수 있음

❌ 의미 없이 pg_resetwal 실행
→ “DB가 뜨는 것”과 “데이터가 안전한 것”은 전혀 다른 문제
→ 마지막 체크포인트 이후 모든 변경 사항 손실 가능

❌ 여러 번 재기동 반복 시도
→ 손상된 WAL을 반복 스캔하며 상황 악화 가능

5️⃣ DBA가 봐야 하는 본질

• 스토리지가 fsync를 실제로 보장했는가
• 파일시스템/마운트 옵션에 write-back 캐시 위험이 없는가
• 네트워크 스토리지의 장애 이력/지연/끊김 여부
• 최근 OS 크래시, 전원 장애, 강제 종료 여부

대부분의 경우, 이 오류는 PostgreSQL 문제가 아니라 스토리지 신뢰성 문제에서 시작됩니다.

6️⃣ DBA 레벨 대응 전략

① 스토리지 신뢰성 검증
- 로컬 디스크 vs 네트워크 스토리지 확인
- fsync, barrier, cache 설정 검증
- CIFS/NFS 사용 시 공식 지원 여부 재검토

② 백업 기반 복구(PITR) 판단
- 최신 Base Backup 존재 여부 확인
- 아카이브 WAL 보존 상태 점검
- “복구 가능한 시점”을 기준으로 손실 범위 판단

③ pg_resetwal 사용 여부 결정
- 최후의 수단으로만 고려
- 마지막 체크포인트 이후 데이터 손실을 명확히 인지
- 테스트/포렌식 목적 외에는 신중하게 결정

7️⃣ 기본 오류 대응 4단계

1) 상황 고정: 추가 쓰기/재기동 중단
2) 원인 확인: 스토리지·WAL·체크포인트 상태 분석
3) 복구 판단: PITR 가능 여부 vs resetwal 손실 감수 여부
4) 재발 방지: 스토리지 교체·구성 변경·백업 체계 강화

8️⃣ 반드시 기억해야 할 결론

👉 이 오류는 “DB 설정 문제”가 아님
👉 스토리지 신뢰성과 WAL 무결성의 문제
👉 pg_resetwal은 해결책이 아니라 데이터 손실을 감수하는 선택

PANIC 단계에서 PostgreSQL은 이미 “안전한 복구가 불가능하다”고 판단한 상태입니다.
이 시점의 조치는 기술적 판단 + 비즈니스 손실 판단이 함께 가야 하며, DBA 단독 판단으로 성급히 진행해서는 안 됩니다.