벼락치기 개발공부

🚨 PostgreSQL WAL 1.8TB 폭증 + Archive Storage Full 장애 대응기

운영 환경에서 대규모 마이그레이션 작업을 진행하던 중 예상하지 못한 상황을 경험했습니다. DB 전체 스토리지는 약 7TB였고 실제 데이터는 약 5.6TB 수준이었습니다.표면적으로 보면 여유가 있는 상황이었지만, 어느 순간 WAL 사용량이 급격히 증가하여 pg_wal 영역이 1.8TB까지 커지는 상태가 발생했습니다. 확인해보니 archive storage 3TB가 이미 100% 가득 찬 상태였고,그 영향으로 WAL이 정상적으로 정리되지 못하고 계속 쌓이고 있었습니다. DB는 즉시 다운되지는 않았지만조금만 더 진행되었다면 실제 서비스 쓰기 장애로 이어질 수 있는 매우 위험한 상황이었습니다.이번 글에서는 이 상황이 왜 발생했는지, 실제로 어떤 위험이 있었는지, 그리고 어떻게 해결했는지까지 운영 경험 기반으로 ..

데이터베이스를 사용하다 보면 자연스럽게 이런 궁금증이 생깁니다.“INSERT나 UPDATE를 하면 데이터는 바로 디스크에 저장되는 걸까?” 하는 질문인데요. 실제로 대부분의 RDBMS는 이런 방식으로 동작하지 않습니다.성능과 안정성을 동시에 확보하기 위해 데이터 변경은 먼저 메모리에서 처리하고, 변경 사실은 로그에 기록한 뒤 실제 디스크 반영은 이후 시점에 수행하는 구조를 사용합니다. 이번에 이러한 구조를 가진 RDBMS 의 디스크 활용법에 대해서 알아보겠습니다! 🚀 RDBMS는 데이터를 바로 디스크에 저장하지 않는다? Oracle, MySQL(InnoDB), PostgreSQL 같은 주요 RDBMS들은구현 방식이나 내부 명칭은 조금씩 다르지만이러한 메모리 기반 처리 + 로그 기반 안정성 확보 구조를..