Amazon RDS for PostgreSQL에서 "No space left on device" 또는 "DiskFull" 오류가 발생하는 이유는 무엇입니까?

7분 분량

PostgreSQL 데이터베이스를 위한 작은 Amazon Relational Database Service(Amazon RDS)가 있습니다. DB 인스턴스의 사용 가능한 스토리지 공간이 줄어들고 있는데 다음과 같은 오류가 발생합니다. "Error message: PG::DiskFull: ERROR: could not extend file "base/16394/5139755": No space left on device. HINT: Check free disk space."

해결 방법

참고: 워크로드가 예측 가능한 경우 인스턴스의 스토리지 자동 조정을 활성화하십시오. Amazon RDS는 스토리지 자동 조정을 통해 사용 가능한 데이터베이스 공간이 부족할 때 스토리지를 자동으로 확장합니다.

스토리지 공간을 모니터링하려면 FreeStorageSpace Amazon CloudWatch 지표를 확인하십시오. 스토리지 여유 공간에 대한 CloudWatch 경보를 설정하면 공간이 줄어들기 시작할 때 알림을 받을 수 있습니다. 경보를 받으면 Amazon RDS DB 인스턴스 스토리지를 사용하는 다음 리소스를 확인하십시오.

PostgreSQL 트랜잭션에 의해 생성된 임시 테이블 또는 파일
데이터 파일
미리 쓰기 로그(WAL)
복제 슬롯
너무 오래 보관된 오류 파일과 같은 DB 로그
RDS DB 인스턴스의 일관된 상태를 지원하는 기타 DB 또는 Linux 파일

DB 인스턴스가 예상보다 스토리지를 많이 소비하는 경우 다음과 같은 문제 해결 조치를 취하십시오.

DB 로그 파일 크기 확인

기본적으로 Amazon RDS for PostgreSQL 오류 로그 파일의 보존 기간은 4,320분(3일)입니다. 대용량 로그 파일은 워크로드가 많거나 로깅이 너무 많기 때문에 더 많은 공간을 사용할 수 있습니다. 시스템 로그의 보존 기간을 변경하려면 DB 인스턴스와 연결된 DB 파라미터 그룹의 rds.log_retention_period 파라미터를 사용하십시오. 예를 들어 값을 1,440으로 설정하면 Amazon RDS는 로그를 하루 동안 보관합니다. 자세한 내용은 RDS for PostgreSQL 데이터베이스 로그 파일을 참조하십시오.

과도한 로깅을 줄이려면 DB 파라미터 그룹에서 오류 보고 및 로깅 파라미터를 변경하십시오. 이 작업을 수행하면 로그 파일 크기가 줄어듭니다. 자세한 내용을 보려면 PostgreSQL 웹 사이트의 19.8 오류 보고 및 로깅을 참조하십시오.

임시 파일 확인

임시 파일은 Amazon RDS가 각 백엔드 또는 세션 연결에 저장하는 파일입니다. Amazon RDS는 이러한 파일을 리소스 풀로 사용합니다. 임시 파일 통계를 검토하려면 다음 명령을 실행합니다.

psql=> SELECT datname, temp_files AS "Temporary files",temp_bytes AS "Size of temporary files" FROM pg_stat_database ;

중요: pg_stat_database 뷰의 temp_files 및 temp_bytes 열은 집계 통계를 수집합니다. Amazon RDS는 즉각적인 종료, 서버 장애 또는 시점 복구(PITR) 이후에만 이러한 카운터를 재설정합니다. 따라서 출력을 검토할 뿐만 아니라 파일 수와 크기가 커지는지 모니터링하는 것이 모범 사례입니다.

Amazon RDS는 정렬, 해시 및 임시 쿼리 결과를 위한 임시 파일을 생성합니다. 사용자 지정 파라미터 그룹에서 임시 테이블 또는 파일의 생성을 추적하려면 log_temp_files를 0으로 설정하여 모든 임시 파일 정보를 기록합니다. 기본적으로 log_temp_files는 -1로 설정되므로 Amazon RDS는 임시 파일을 기록하지 않습니다. log_temp_files를 양수 값으로 설정하면 Amazon RDS는 해당 킬로바이트 수보다 크거나 같은 파일만 기록합니다.

쿼리에 EXPLAIN ANALYZE를 사용하여 디스크 정렬을 검토하십시오. 로그 출력에서 쿼리가 생성한 임시 파일의 크기를 확인합니다. 자세한 내용은 work_mem을 사용한 PostgreSQL의 정렬 작업 조정을 참조하십시오.

트랜잭션 로그 디스크 사용량이 지속적으로 증가하는지 확인

트랜잭션 WAL이 사용하는 디스크 공간을 보려면 TransactionLogsDiskUsage 지표를 확인합니다. 다음과 같은 이유로 트랜잭션 로그 디스크 사용량이 증가할 수 있습니다.

추가 WAL을 생성하는 쓰기 및 업데이트로 인한 높은 DB 부하
동일한 AWS 리전의 복제본 또는 가득 찬 스토리지 상태의 읽기 전용 복제본에 대한 스트리밍 읽기 복제본 지연
복제 슬롯

AWS Database Migration Service(AWS DMS)는 논리적 디코딩의 일부로 복제 슬롯을 생성할 수 있습니다. 논리적 복제의 경우 rds.logical_replication 슬롯 파라미터는 1로 설정됩니다. 복제 슬롯은 외부 소비자가 파일을 사용할 때까지 WAL 파일을 유지합니다. 소비자의 예로는 pg_recvlogical, 추출, 전환, 로드(ETL) 작업과 AWS DMS가 있습니다.

rds.logical_replication을 1로 설정하면 Amazon RDS는 wal_level, max_wal_senders, max_replication_slots 및 max_connections 파라미터를 설정합니다. 이러한 파라미터 변경은 WAL 생성을 증가시킬 수 있습니다. 논리적 슬롯을 사용하는 경우에만 ** rds.logical\ _replication ** 파라미터를 설정하는 것이 모범 사례입니다. 보관된 WAL 파일의 소비자가 없는 경우 트랜잭션 로그의 디스크 사용량이 증가하고 사용 가능한 스토리지 공간은 계속해서 감소합니다.

복제 슬롯이 있는지, 크기는 얼마인지 확인하려면 다음 쿼리를 실행합니다.

PostgreSQL v9:

psql=> SELECT slot_name, pg_size_pretty(pg_xlog_location_diff(pg_current_xlog_location(),restart_lsn)) AS replicationSlotLag, active FROM pg_replication_slots ;

PostgreSQL v10 이상:

psql=> SELECT slot_name, pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(),restart_lsn)) AS replicationSlotLag, active FROM pg_replication_slots ;

출력 예시:

slot_name                                                      | replicationslotlag | active---------------------------------------------------------------+--------------------+--------
xc36ujql35djp_00013322_907c1e0a_9f8b_4c13_89ea_ef0ea1cf143d    | 129 GB             | f
7pajuy7htthd7sqn_00013322_a27bcebf_7d0f_4124_b336_92d0fb9f5130 | 704 MB             | t
zp2tkfo4ejw3dtlw_00013322_03e77862_689d_41c5_99ba_021c8a3f851a | 624 MB             | t

활성 상태가 f(false)로 설정된 복제 슬롯은 사용되지 않습니다. 이 예에서 xc36ujql35djp_00013322_907c1e0a_9f8b_4c13_89ea_ef0ea1cf143d 슬롯은 f 활성 상태입니다. 이 슬롯은 활발하게 사용되지는 않지만 129GB의 트랜잭션 파일을 사용합니다.

사용하지 않는 슬롯을 삭제하려면 다음 쿼리를 실행합니다.

psql=> SELECT pg_drop_replication_slot('YOUR_SLOTNAME');

참고: YOUR_SLOTNAME을 슬롯 이름으로 바꾸십시오.

출력 예시:

psql=> SELECT pg_drop_replication_slot('xc36ujql35djp_00013322_907c1e0a_9f8b_4c13_89ea_ef0ea1cf143d');

더 이상 필요하지 않은 AWS DMS 작업이 소비자인 경우, 작업을 삭제하고 복제 슬롯을 수동으로 삭제하십시오.

리전 간 또는 동일 리전 읽기 복제본의 상태 확인

참고: PostgreSQL 14.1 이상에서 실행되는 경우에만 동일 리전 읽기 복제본에 대해 다음 해결 방법을 사용할 수 있습니다.

리전 간 또는 동일 리전 읽기 복제를 사용하는 경우 Amazon RDS는 기본 인스턴스에 물리적 복제 슬롯을 생성합니다. 읽기 복제본 실패는 기본 DB 인스턴스의 스토리지 공간에 영향을 미칠 수 있습니다. 이 상황은 WAL 파일이 읽기 복제본에 복제되지 않을 때 발생합니다. OldestReplicationSlotLag 및 TransactionLogsDiskUsage 지표를 확인하여 지연이 가장 심한 복제본보다 얼마나 뒤쳐져 있는지 확인하십시오. 또한 WAL 데이터가 사용하는 스토리지의 양도 확인할 수 있습니다.

읽기 복제본의 상태를 확인하려면 다음 쿼리를 실행합니다.

psql=> SELECT * FROM pg_replication_slots;

pg_replication_slots에 대한 자세한 내용은 PostgreSQL 웹 사이트의 52.19 pg_replication_slots를 참조하십시오. 출력의 활성 상태가 f로 설정된 경우 슬롯은 복제에 사용되지 않습니다.

또한 소스 인스턴스의 pg_stat_replication에서 복제의 통계를 확인할 수 있습니다. 자세한 내용은 PostgreSQL 웹 사이트의 표 27.14. pg_stat_replication 뷰를 참조하십시오.

죽은 행의 팽창 또는 부적절한 제거 확인

표준 PostgreSQL 작업에서 PostgreSQL은 사용자가 삭제하거나 UPDATE로 인해 더 이상 사용되지 않는 죽은 행(튜플)을 테이블에서 제거하지 않습니다. 다중 버전 동시성 제어(MVCC) 구현의 경우 DELETE 작업을 수행할 때 데이터 파일에서 행이 즉시 제거되지 않습니다. 대신 PostgreSQL은 헤더의 xmax 필드를 설정하여 행을 삭제된 것으로 표시합니다. 먼저 삭제할 마크 행을 업데이트한 다음 삽입 작업을 수행합니다. 이를 통해 서로 다른 트랜잭션 간의 잠금을 최소화하면서 동시에 실행할 수 있습니다. 따라서 PostgreSQL은 MVCC 프로세스의 일부로 다양한 행 버전을 유지합니다.

정리되지 않은 죽은 행은 데이터 파일에 남아 있지만 트랜잭션에서는 보이지 않습니다. 이러한 행은 디스크 공간 문제를 일으킬 수 있습니다. 테이블에 DELETE 및 UPDATE 작업이 많으면 데드 튜플이 많은 양의 디스크 공간을 사용(팽창)할 수 있습니다.

VACUUM 작업을 사용하여 데드 튜플이 사용하는 스토리지를 비우십시오. VACUUM은 여유 스토리지를 파일 시스템에 릴리스하지 않는다는 점에 유의하십시오. 스토리지를 파일 시스템으로 릴리스하려면 VACUUM FULL을 사용합니다. 참고로 VACUUM FULL을 실행하면 PostgreSQL은 테이블에 액세스 전용 잠금을 적용합니다. VACUUM FULL은 새 테이블 복사본을 생성하고 작업이 완료될 때까지 기존 복사본을 릴리스하지 않기 때문에 이 방법에는 추가 디스크 공간이 필요합니다. 테이블에서 상당한 공간을 비워야 하는 경우에만 VACUUM FULL을 사용하는 것이 모범 사례입니다. 자주 업데이트하는 테이블에 대해 주기적으로 vacuum 또는 autovacuum 작업을 수행하는 것도 모범 사례입니다. 자세한 내용은 PostgreSQL 웹 사이트에서 VACUUM을 참조하십시오.

예상 데드 튜플 수를 확인하려면 pg_stat_all_tables 뷰를 사용합니다. 자세한 내용은 PostgreSQL 웹 사이트의 표 27.29. pg_stat_all_tables 뷰를 참조하십시오. 다음 예시 테이블에는 n_dead_tup 레코드에 1,999,952개의 데드 튜플이 있습니다.

psql => SELECT * FROM pg_stat_all_tables WHERE relname='test';
-[ RECORD 1 ]-------+------------------------------
relid               | 16395
schemaname          | public
relname             | test
seq_scan            | 3
seq_tup_read        | 5280041
idx_scan            |
idx_tup_fetch       |
n_tup_ins           | 2000000
n_tup_upd           | 0
n_tup_del           | 3639911
n_tup_hot_upd       | 0
n_live_tup          | 1635941
n_dead_tup          | 1999952
n_mod_since_analyze | 3999952
last_vacuum         |
last_autovacuum     | 2024-08-16 04:49:52.399546+00
last_analyze        | 2024-08-09 09:44:56.208889+00
last_autoanalyze    | 2024-08-16 04:50:22.581935+00
vacuum_count        | 0
autovacuum_count    | 1
analyze_count       | 1
autoanalyze_count   | 1


psql => VACUUM TEST;

분리된 파일 확인

데이터베이스 디렉터리에 있는 파일을 가리키는 객체가 없을 때 분리된 파일이 발생할 수 있습니다. 이 상황은 ALTER TABLE, VACUUM FULL 또는 CLUSTER와 같은 작업 중에 인스턴스의 스토리지가 부족하거나 엔진이 충돌할 때 발생합니다. 분리된 파일이 있는지 확인하려면 다음 단계를 완료하십시오.

각 데이터베이스의 PostgreSQL에 로그인합니다.

데이터베이스의 사용된 크기를 확인하려면 다음 쿼리를 실행합니다.

psql=> SELECT pg_size_pretty(pg_database_size('DATABASE_NAME'));

참고: DATABASE_NAME을 데이터베이스 이름으로 바꾸십시오.

데이터베이스의 실제 크기를 확인하려면 다음 쿼리를 실행합니다.

psql=> SELECT pg_size_pretty(SUM(pg_relation_size(oid))) FROM pg_class;

위 명령의 출력에서 데이터베이스의 사용된 크기와 실제 크기를 비교합니다. 차이가 크면 분리된 파일이 스토리지 공간을 사용하고 있는 것일 수 있습니다.