운영 환경에서 대규모 마이그레이션 작업을 진행하던 중 예상하지 못한 상황을 경험했습니다.
DB 전체 스토리지는 약 7TB였고 실제 데이터는 약 5.6TB 수준이었습니다.
표면적으로 보면 여유가 있는 상황이었지만, 어느 순간 WAL 사용량이 급격히 증가하여 pg_wal 영역이 1.8TB까지 커지는 상태가 발생했습니다.
확인해보니 archive storage 3TB가 이미 100% 가득 찬 상태였고,
그 영향으로 WAL이 정상적으로 정리되지 못하고 계속 쌓이고 있었습니다.
DB는 즉시 다운되지는 않았지만
조금만 더 진행되었다면 실제 서비스 쓰기 장애로 이어질 수 있는 매우 위험한 상황이었습니다.
이번 글에서는 이 상황이 왜 발생했는지, 실제로 어떤 위험이 있었는지, 그리고 어떻게 해결했는지까지 운영 경험 기반으로 정리해보았습니다!
📊 당시 스토리지 상황
- DB 전체 스토리지: 약 7TB
- 실제 데이터 파일: 약 5.6TB
- WAL 영역: 2TB 중 1.8TB 사용
- Archive Storage: 3TB / 100% Full
- 계기: 대규모 마이그레이션 작업 진행
즉 DB 데이터 영역은 남아 있었지만
WAL과 archive 흐름이 막히면서 시스템 안정성이 크게 흔들리는 상태였습니다.
⚡ WAL이 1.8TB까지 증가한 이유
마이그레이션 작업에서는 대량 데이터 변경이 발생합니다.
- 대량 INSERT / UPDATE
- 인덱스 생성 및 변경
- 배치 트랜잭션 반복
- Checkpoint 부담 증가
PostgreSQL은 데이터 변경을 바로 디스크에 반영하는 것이 아니라
먼저 WAL(Write-Ahead Log)에 기록하는 구조입니다.
따라서 작업량이 많아질수록 WAL 생성량도 함께 증가합니다.
이번 케이스에서는 생성된 WAL을 archive storage로 지속적으로 전송해야 했지만
archive 저장소가 가득 차면서 archive_command가 실패하기 시작했습니다.
archive에 성공하지 못한 WAL은 PostgreSQL 입장에서 제거할 수 없는 파일이 되며,
이 상태가 지속되면서 pg_wal 사용량이 계속 증가하게 되었고,
결과적으로 WAL 영역이 1.8TB까지 커지는 상황이 발생했습니다.
🚨 이 상태가 위험했던 이유
1️⃣ WAL 영역 Full 시 DB 쓰기 장애 가능
PostgreSQL은 모든 변경 작업을 WAL에 먼저 기록합니다.
따라서 WAL 저장 공간이 부족해지면
- INSERT 실패
- UPDATE 실패
- 트랜잭션 오류 증가
같은 문제가 실제로 발생할 수 있습니다.
데이터 파일 공간이 남아 있어도
WAL 영역이 막히면 서비스 장애로 이어질 수 있습니다.
2️⃣ PITR 및 백업 복구 신뢰성 저하
archive 실패가 지속되면 특정 시점 복구 체인이 불안정해질 수 있습니다.
즉 장애 발생 시
“백업은 있지만 원하는 시점으로 복구하지 못하는 상황”이 발생할 수 있습니다.
3️⃣ 복제 환경 영향 가능성
환경에 따라 standby replay 지연이나 replication slot retention과 겹치면
WAL 적체는 더 심각해질 수 있습니다.
따라서 WAL 급증 상황에서는 archive뿐 아니라
replication 상태도 반드시 함께 확인해야 합니다.
🛠 실제 대응 과정
문제를 해결하기 위해 먼저 archive 상태를 확인했습니다.
SELECT * FROM pg_stat_archiver;archive 실패 횟수가 증가하고 있었고 archive storage 사용량은 이미 100%였기 때문에
이후 다음 항목을 함께 점검했습니다.
- replication slot 상태
- standby replay 지연 여부
- backup 진행 여부
- 장기 트랜잭션 존재 여부
주요 원인이 archive storage 포화라는 점을 확인한 뒤
복구 정책 기준에 따라 오래된 archive WAL cleanup을 진행했습니다.
archive 공간 확보 이후 archive가 정상 동작하기 시작했고
PostgreSQL이 필요 없는 WAL부터 순차적으로 recycle하면서 사용량이 점진적으로 감소했습니다.
필요한 경우 checkpoint를 수행하여 WAL 정리 사이클을 앞당겼습니다.
📌 운영 경험에서 얻은 포인트
✔ DB 데이터 공간과 WAL 공간은 별개로 관리해야 합니다
데이터 영역이 남아 있다고 해서 안전한 상태는 아닙니다.
WAL 영역이 막히면 실제 서비스 장애로 이어질 수 있습니다.
✔ WAL 급증은 대부분 retention 문제와 연결됩니다
대표적으로 확인해야 할 항목은 다음과 같습니다.
- archive 실패 여부
- replication slot restart_lsn
- standby replay 지연
- backup 미완료
✔ archive storage 모니터링은 반드시 필요합니다
다음 지표는 운영 모니터링에 포함하는 것이 좋습니다.
- archive filesystem usage
- pg_wal usage
- archiver failed_count
- last_archived_time
✔ 대량 작업 전 WAL 증가량 예측이 중요합니다
마이그레이션이나 대량 배치 작업 전에는
- 예상 WAL 생성량
- archive 적재 속도
- storage 여유
- retention 정책
까지 함께 점검해야 합니다.
✍️ 마무리
이번 이슈는 단순한 디스크 용량 문제가 아닌
PostgreSQL의 WAL 생명주기 전체 흐름이 막히면서 발생한 운영 장애였습니다!
archive cleanup 이후 정상화를 진행할 수 있었지만
이 경험을 통해 WAL과 archive는 단순 로그가 아니라 운영 안정성을 좌우하는 핵심 요소라는 점,
그리고 대량 작업 전 archive 용량과 retention 정책을 함께 점검하는 것이 얼마나 중요한지 깨닫게 되는 좋은 경험이였습니다!
'개발지식 > DB' 카테고리의 다른 글
| RDBMS의 디스크 활용법 (0) | 2026.03.16 |
|---|---|
| PostgreSQL 이중화 환경에서 성능 이슈 해결 하기 (0) | 2026.01.16 |
| [DB] PostgreSQL 이란 무엇인가?! (0) | 2025.12.30 |
| index 가 뭔지, 동작원리에 대해 설명해보세요(실제 기술면접 질문) (0) | 2024.02.13 |