PostgreSQL 53100 오류 원인과 해결 방법 완벽 가이드

53100
2026년 09월 18일 | DBMS Error 가이드

이 글에서 다루는 내용

53100 에러의 원인 분석, 해결 SQL, 예방 방법을 실무 관점에서 정리합니다.

53100 disk full 는?

PostgreSQL 에러 코드 53100 disk full은 데이터베이스 서버가 데이터를 디스크에 기록하려는 순간, 해당 파일시스템의 여유 공간이 완전히 소진되었을 때 발생하는 치명적인 운영 에러입니다. 이 에러는 단순히 쿼리 하나가 실패하는 수준을 넘어, 트랜잭션 롤백은 물론 최악의 경우 데이터베이스 클러스터 자체가 비정상 종료될 수 있는 매우 위험한 상황을 초래합니다. 주로 대용량 데이터 적재, 인덱스 재구성, VACUUM 작업, WAL(Write-Ahead Log) 아카이빙 지연 등 다양한 상황에서 예고 없이 나타나기 때문에 운영 중인 DBA라면 반드시 사전 대비책을 마련해 두어야 합니다.

주요 발생 원인

1. WAL(Write-Ahead Log) 파일의 과도한 누적

WAL 아카이빙이 지연되거나 복제(Replication) 슬롯의 소비자가 중단된 경우, WAL 파일이 pg_wal 디렉토리에 무제한으로 쌓이면서 디스크를 가득 채우는 일이 발생합니다. 특히 논리 복제(Logical Replication) 슬롯은 슬롯을 소비하는 구독자(Subscriber)가 연결되지 않으면 WAL을 절대 삭제하지 않기 때문에, 운영 중 슬롯 관리에 각별한 주의가 필요합니다.

2. 테이블 팽창(Table Bloat) 및 임시 파일 누적

PostgreSQL은 정렬(Sort), 해시 조인(Hash Join), 집계(Aggregation) 등의 작업이 work_mem을 초과할 경우 디스크에 임시 파일(pgsql_tmp)을 생성합니다. 대형 쿼리가 동시에 다수 실행되거나, 잦은 UPDATE/DELETE로 인해 데드 튜플이 회수되지 않고 테이블이 과도하게 부풀어오른 경우에도 디스크 공간을 급격히 소모하게 됩니다.

3. 대용량 데이터 적재 및 인덱스 생성 작업

COPY, INSERT ... SELECT 같은 대량 적재 작업이나 CREATE INDEX, CLUSTER 명령은 작업 도중 대량의 임시 공간과 WAL 로그를 동시에 생성합니다. 디스크 여유 공간에 대한 사전 검토 없이 이런 작업을 진행하면, 작업 중간에 53100 에러가 발생하여 트랜잭션이 롤백되고 이미 생성된 임시 파일이 정리되지 않아 이중으로 공간 낭비가 생길 수 있습니다.

해결 방법

1. 현재 디스크 상태 및 WAL 슬롯 점검

먼저 서버에서 디스크 사용량을 확인하고, 불필요한 복제 슬롯을 식별합니다.

-- 복제 슬롯 상태 확인 (inactive 슬롯이 WAL을 잡고 있는지 확인)
SELECT slot_name,
       slot_type,
       active,
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS retained_wal_size
FROM pg_replication_slots
ORDER BY retained_wal_size DESC;

-- 사용하지 않는 복제 슬롯 삭제 (주의: 복제 구성 확인 후 실행)
SELECT pg_drop_replication_slot('사용하지_않는_슬롯명');

2. 임시 파일 및 테이블 팽창 진단

-- 현재 생성 중인 임시 파일 크기 확인
SELECT datname,
       temp_files,
       pg_size_pretty(temp_bytes) AS temp_size
FROM pg_stat_database
ORDER BY temp_bytes DESC;

-- 테이블별 팽창(bloat) 확인
SELECT schemaname,
       tablename,
       pg_size_pretty(pg_total_relation_size(schemaname || '.' || tablename)) AS total_size,
       n_dead_tup,
       n_live_tup,
       round(n_dead_tup::numeric / NULLIF(n_live_tup + n_dead_tup, 0) * 100, 2) AS dead_ratio_pct
FROM pg_stat_user_tables
WHERE n_dead_tup > 10000
ORDER BY n_dead_tup DESC
LIMIT 20;

-- 팽창된 테이블 VACUUM 수행
VACUUM VERBOSE ANALYZE public.your_bloated_table;

-- 심각한 경우 VACUUM FULL (잠금 발생 주의)
VACUUM FULL public.your_bloated_table;

3. 디스크 공간 확보 및 WAL 설정 조정

-- WAL 보관 크기 설정 확인 및 조정 (postgresql.conf)
SHOW wal_keep_size;
SHOW max_wal_size;

-- 아카이빙 상태 확인
SELECT * FROM pg_stat_archiver;

-- pg_wal 디렉토리 수동 정리 (PostgreSQL 중지 후 아래 명령 실행 권장)
-- 절대로 pg_wal 파일을 직접 삭제하지 말 것! pg_archivecleanup 사용
-- pg_archivecleanup /var/lib/postgresql/14/main/pg_wal <최신_WAL_파일명>

-- 대용량 작업 전 남은 디스크 공간 확인
SELECT pg_size_pretty(
    (SELECT setting::bigint * 1024
     FROM pg_settings
     WHERE name = 'block_size') *
    (SELECT setting::bigint
     FROM pg_settings
     WHERE name = 'max_wal_size')
) AS max_wal_size_bytes;

4. 비상 시 즉각 조치 쿼리

-- 현재 실행 중인 쿼리 중 임시 파일을 많이 쓰는 쿼리 식별
SELECT pid,
       usename,
       application_name,
       state,
       pg_size_pretty(temp_blks_written * 8192) AS temp_written,
       query
FROM pg_stat_activity
JOIN pg_stat_statements USING (queryid)
WHERE state = 'active'
ORDER BY temp_blks_written DESC
LIMIT 10;

-- 긴급하게 특정 세션 종료 (디스크 추가 사용 방지)
SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE state = 'active'
  AND query_start < now() - interval '1 hour'
  AND query NOT LIKE '%pg_terminate%';

예방 방법

1. 디스크 사용량 모니터링 자동화 및 알림 설정

단순히 OS 레벨에서 df -h를 주기적으로 확인하는 것을 넘어, PostgreSQL 내부에서도 데이터베이스 크기, WAL 크기, 임시 파일 크기를 자동으로 수집하는 모니터링 체계를 구축해야 합니다. Prometheus + postgres_exporter, Zabbix, 또는 자체 스크립트를 활용하여 디스크 사용량이 70% 도달 시 경고, 85% 도달 시 긴급 알림이 발송되도록 임계값을 설정하고, 아래 쿼리를 정기 수집 대상에 포함시키는 것을 강력히 권장합니다.

-- 정기 모니터링용 데이터베이스 크기 수집 쿼리
SELECT datname,
       pg_size_pretty(pg_database_size(datname)) AS db_size,
       pg_database_size(datname) AS db_size_bytes
FROM pg_database
WHERE datname NOT IN ('template0', 'template1')
ORDER BY pg_database_size(datname) DESC;

2. 복제 슬롯 및 VACUUM 정책 정기 점검

논리/물리 복제 슬롯은 소비자가 중단되는 순간부터 WAL 축적이 시작되므로, 매일 pg_replication_slots 뷰를 점검하여 active = false인 슬롯이 존재할 경우 즉시 조치하는 운영 루틴을 확립해야 합니다. 또한 autovacuum이 비활성화된 테이블이 없는지, 테이블 단위 autovacuum_vacuum_scale_factor 설정이 과도하게 높지 않은지 정기적으로 검토하여 데드 튜플로 인한 테이블 팽창을 사전에 방지하세요.