1. 오류 메시지 분석
PostgreSQL 서버 로그에서 다음과 같은 치명적인 오류 메시지를 발견했다면, 이는 일반적으로 디스크 공간 부족으로 인해 발생합니다.
2024-11-15 09:15:49.673 UTC [1] FATAL: could not write lock file "postmaster.pid": No space left on device이 오류는 PostgreSQL 서버가 시작할 때 필수적으로 생성하는 락(lock) 파일인 postmaster.pid를 디스크에 기록하지 못해 발생합니다. 'No space left on device' 메시지는 시스템이 파일을 생성할 충분한 공간이 없음을 명확히 알려줍니다.
2. 오류의 주요 원인
PostgreSQL 서버가 디스크 공간 부족으로 인해 시작하지 못하는 가장 흔한 원인들은 다음과 같습니다:
- 데이터베이스 파일의 과도한 증가: 데이터베이스 내 테이블, 인덱스, 임시 파일 등이 예상보다 빠르게 커져 디스크 공간을 모두 소모할 수 있습니다.
- 로그 파일의 누적: PostgreSQL 서버 로그(
pg_log)나 운영체제(OS) 로그 파일(예:syslog,journald)이 너무 오랫동안 관리되지 않아 용량이 비대해질 수 있습니다. - 임시 파일이나 백업 파일로 인한 공간 부족: 데이터베이스 백업 파일, 대용량 쿼리 실행 중 생성된 임시 파일, 또는 다른 애플리케이션의 임시 파일이 디스크 공간을 점유하고 있을 수 있습니다.
- 다른 애플리케이션이나 프로세스의 디스크 사용: PostgreSQL 서버가 사용하는 디스크 외에 같은 볼륨에 위치한 다른 애플리케이션의 데이터, 캐시, 로그 등이 공간을 차지하고 있을 가능성도 있습니다.
3. 즉각적인 해결 방안
이 오류를 해결하기 위해 다음 단계들을 순서대로 시도해 볼 수 있습니다.
-
3.1. 디스크 공간 확보
가장 먼저 할 일은 PostgreSQL 데이터 디렉토리 또는 시스템 전체에서 불필요한 파일을 찾아 삭제하거나 다른 디스크로 이동시켜 공간을 확보하는 것입니다.
# PostgreSQL 데이터 디렉토리 내 각 하위 디렉토리의 용량을 확인합니다. sudo du -sh /var/lib/postgresql/* | sort -rh # (주의!) PostgreSQL 데이터 디렉토리 내 오래된 로그 파일을 삭제합니다. # 이 명령은 .log 확장자를 가진 모든 파일을 삭제하므로, 실행 전 중요한 로그는 백업하세요. sudo find /var/lib/postgresql -type f -name "*.log" -delete시스템 전체의 디스크 사용량은
df -h명령어로 확인할 수 있습니다. 특히 PostgreSQL 데이터베이스가 설치된 파티션의 공간을 확인해야 합니다. -
3.2. 로그 파일 정리
운영체제 및 PostgreSQL의 오래된 로그 파일들을 압축하거나 삭제하여 공간을 확보할 수 있습니다.
# PostgreSQL 로그 디렉토리(/var/log/postgresql)에서 7일 이상 된 로그 파일을 gzip으로 압축합니다. # 압축 전, 중요한 로그 파일은 별도로 백업하는 것이 좋습니다. sudo find /var/log/postgresql -name "*.log" -mtime +7 -exec gzip {} \; # 시스템 로그도 함께 점검하고 정리할 수 있습니다. (예: journalctl --vacuum-time=1w) -
3.3. 데이터베이스 최적화 (PostgreSQL 시작 후)
PostgreSQL 서버가 다시 시작되면, 데이터베이스 내부의 불필요한 공간을 회수하기 위해 최적화 작업을 수행할 수 있습니다. 이 작업은 디스크 공간을 효과적으로 재활용하는 데 도움이 됩니다.
-- 모든 데이터베이스에 대해 VACUUM FULL을 실행합니다. -- 이 명령은 테이블을 재작성하므로, 상당한 I/O와 시간을 소모하며, 해당 테이블에 대한 Exclusive Lock을 겁니다. -- 서비스 중단이 필요한 작업이므로, 가능하면 유지보수 시간에 실행하세요. VACUUM FULL; -- 특정 데이터베이스만 최적화하려면 다음과 같이 연결 후 실행합니다. -- psql -d your_database_name -c "VACUUM FULL;" -- VACUUM FULL 대신, 더 가볍고 온라인 상태에서 가능한 VACUUM 명령을 주기적으로 실행하는 것을 권장합니다. -- AUTOVACUUM이 활성화되어 있다면, 수동 VACUUM FULL은 매우 드물게 필요합니다. -- VACUUM ANALYZE; -
3.4. 디스크 공간 모니터링 시스템 구축
이러한 문제를 예방하기 위해 디스크 사용량을 주기적으로 체크하고 임계치 도달 시 알림을 주는 모니터링 시스템을 구축하는 것이 매우 중요합니다. Prometheus, Grafana, Zabbix 등의 도구를 활용할 수 있습니다.
4. 향후 재발 방지 대책
동일한 오류가 반복되지 않도록 다음과 같은 예방 조치를 취하는 것이 좋습니다.
- 정기적인 데이터베이스 유지보수 일정 수립:
VACUUM,REINDEX등의 명령을 정기적으로 실행하여 데이터베이스의 성능을 유지하고 디스크 공간 낭비를 줄입니다. 특히AUTOVACUUM설정이 적절한지 확인합니다. - 자동화된 로그 로테이션 설정:
logrotate와 같은 도구를 사용하여 운영체제 및 PostgreSQL 로그 파일을 주기적으로 압축, 보관, 삭제하도록 설정합니다. 이는 로그 파일이 무한정 커지는 것을 방지합니다. - 디스크 공간 사용량에 대한 알림 시스템 구축:
디스크 사용량이 특정 임계치(예: 80% 또는 90%)에 도달했을 때 관리자에게 자동으로 알림을 보내는 시스템을 구축하여 사전에 대처할 수 있도록 합니다.
- 필요 시 디스크 용량 증설 계획 수립:
데이터 증가 추세를 지속적으로 모니터링하고, 예측되는 용량 부족에 대비하여 선제적으로 디스크 용량을 증설하는 계획을 세웁니다.
5. 전문가 팁
더욱 효율적인 PostgreSQL 운영과 디스크 공간 관리를 위한 추가 팁입니다.
- PostgreSQL의 autovacuum 설정 최적화:
postgresql.conf파일에서autovacuum관련 파라미터(예:autovacuum_vacuum_scale_factor,autovacuum_vacuum_threshold)를 워크로드에 맞게 조정하여 디스크 공간 사용을 효율적으로 관리하고 dead tuple이 쌓이는 것을 방지하세요. - WAL(Write-Ahead Logging) 설정 검토:
wal_level,max_wal_size,min_wal_size,wal_keep_segments등 WAL 관련 설정을 검토하여 불필요한 로그 생성을 줄이고, 아카이빙 전략을 최적화하여 디스크 공간을 절약하세요. - 데이터베이스 파티셔닝 고려:
매우 큰 테이블이 있다면, 데이터를 논리적으로 분할하는 파티셔닝(Partitioning)을 고려해 보세요. 이는 대용량 테이블의 관리 효율성을 높이고, 특정 파티션의 데이터를 독립적으로 정리하여 디스크 공간을 효율적으로 관리하는 데 도움이 됩니다.
- 클라우드 환경 자동 스케일링 활용:
AWS RDS, Google Cloud SQL, Azure Database for PostgreSQL 등 클라우드 데이터베이스 서비스를 사용 중이라면, 디스크 자동 스케일링(auto-scaling) 또는 용량 증설 옵션을 활용하여 디스크 공간을 동적으로 관리하고 수동 개입을 최소화할 수 있습니다.