Aurora PostgreSQL 호환 DB 인스턴스의 로컬 스토리지 문제를 해결하려면 어떻게 해야 합니까?

간략한 설명

Amazon Aurora의 스토리지에는 두 가지 유형이 있습니다. 공유 클러스터 볼륨과 같은 영구 데이터용 스토리지, 그리고 각 DB 인스턴스용 로컬 스토리지의 두 가지입니다.

로컬 스토리지 크기는 인스턴스 클래스에 좌우됩니다. 스토리지 크기는 더 큰 DB 인스턴스 클래스로 이동하는 경우에만 변경할 수 있습니다. Aurora PostgreSQL 호환은 오류 로그와 임시 파일을 저장하기 위해 로컬 스토리지를 사용합니다. 시스템은 T 외의 시스템 인스턴스 유형인 경우 로그를 전용 볼륨에 작성하며, 이 볼륨은 시스템이 자동으로 정리합니다.

Aurora DB 인스턴스 또는 노드와 연결된 로컬 스토리지 공간을 모니터링하려면 Amazon CloudWatch 지표 FreeLocalStorage를 사용하십시오. 이 지표는 각 DB 인스턴스에서 사용 가능한 로컬 스토리지의 양을 보고합니다.

해결 방법

‘No space left on device’ 오류 해결

‘could not write block ###### of temporary file: No space left on device’ 오류 메시지는 남은 임시 스토리지가 없을 때 표시됩니다. 이 오류는 다음 작업에서 발생할 수 있습니다.

• 대형 테이블 변경
• 대형 테이블에 인덱스 추가 또는 REINDEX 수행
• 복잡한 JOINs, GROUP BY 또는 ORDER BY 절을 사용해 대규모 SELECT 쿼리 수행
• VACUUM FULL 또는r pg_repack 실행

임시 파일 크기 확인

임시 파일의 세부 정보를 확인하려면 Aurora PostgreSQL 호환 DB 인스턴스에서 log_temp_files 파라미터를 활성화하십시오. 그런 다음, 임시 파일을 FreeLocalStorage 지표와 비교합니다.

log_temp_files 파라미터는 지정된 킬로바이트 수보다 큰 각 임시 파일을 기록합니다. 값이 0이면 모든 임시 파일 정보가 기록됩니다. 값이 양수이면 지정된 킬로바이트 수와 같거나 그보다 큰 파일만 로깅합니다. 기본값은 -1이며, 임시 파일 로깅을 비활성화합니다. log_temp_files 파라미터를 활성화하면 Aurora PostgreSQL 호환 DB 인스턴스에 과도한 로깅이 발생할 수 있습니다.

log_temp_files를 활성화하기 전에 Aurora PostgreSQL 호환 로그 파일의 크기를 확인하는 것이 좋습니다. 로그 파일이 로컬 스토리지의 최대 공간을 사용하는 경우 rds.log_retention 값을 줄여 공간을 확보하십시오. rds.log_retention의 기본값은 3일입니다.

임시 파일 크기를 검토하려면 다음 명령을 여러 번 실행합니다.

maxiops=> select datname, temp_files , pg_size_pretty(temp_bytes) as temp_file_size FROM  pg_stat_database order by temp_bytes desc;

참고: 후속 실행 이후 변경된 출력을 사용하십시오.

pg_stat_database 뷰의 temp_files 및 temp_bytes 열은 임시 파일을 언제 만들었는지와 관계없이 모든 임시 파일의 누적된 값에 대한 통계를 수집합니다. 값을 재설정하려면 pg_stat_reset() 함수를 사용하거나 DB 인스턴스를 다시 시작합니다. 자세한 내용은 PostgreSQL 웹 사이트의 추가 통계 함수를 참조하십시오.

Aurora PostgreSQL 호환 10 이후 버전을 사용하는 경우, Performance Insights를 사용해 temp_bytes 및 temp_files를 모니터링할 수 있습니다. Performance Insights는 DB 엔진의 내부 지표 및 대기 이벤트에 대한 기본 카운터를 제공합니다. 또한 Performance Insights를 활성화하고 Database Insights를 사용하여 데이터베이스 로그를 모니터링할 수 있습니다.

작업을 수행하는 프로세스에 더 많은 메모리를 할당하려면 maintenance_work_mem 및 work_mem 파라미터를 늘리십시오. 이 방법은 작업에 더 많은 메모리를 사용하고 임시 디스크 스토리지를 적게 사용합니다. 이러한 파라미터에 대한 자세한 내용은 PostgreSQL 웹 사이트의 maintenance_work_mem 및 work_mem을 참조하십시오.

maintenance_work_mem 및 work_mem 값은 쿼리 또는 세션 수준에서 설정하는 것이 좋습니다. 이렇게 하면 DB 인스턴스의 메모리가 부족해지지 않습니다. 자세한 내용은 Amazon Aurora PostgreSQL 참조를 확인하십시오.

임시 테이블 크기 확인

다음 쿼리를 실행하십시오.

maxiops=> SELECT n.nspname as SchemaName
,c.relname as RelationName
,CASE c.relkind
WHEN 'r' THEN 'table'
WHEN 'v' THEN 'view'
WHEN 'i' THEN 'index'
WHEN 'S' THEN 'sequence'
WHEN 's' THEN 'special'
END as RelationType
,pg_catalog.pg_get_userbyid(c.relowner) as RelationOwner
,pg_size_pretty(pg_relation_size(n.nspname ||'.'|| c.relname)) as RelationSize
FROM pg_catalog.pg_class c
LEFT JOIN pg_catalog.pg_namespace n
  ON n.oid = c.relnamespace
WHERE c.relkind IN ('r','s')
AND (n.nspname !~ '^pg_toast' and nspname like 'pg_temp%')
ORDER BY pg_relation_size(n.nspname ||'.'|| c.relname) DESC;

애플리케이션을 면밀히 모니터링하고 임시 테이블을 만드는 트랜잭션을 확인하는 것이 좋습니다. 그러면 사용 가능한 로컬 스토리지 용량의 사용량을 관리할 수 있습니다. 또한 DB 인스턴스가 더 많은 가용 로컬 스토리지를 보유하도록 Aurora DB 인스턴스의 인스턴스 클래스를 변경할 수 있습니다.

버스트 가능한 성능 인스턴스 클래스 유형에서 로그 파일 확인

과도한 로깅으로 인해 db.t2, db.t3, db.t4g와 같은 버스트 가능한 성능 인스턴스 클래스 유형에 대해서만 DB 인스턴스의 로컬 스토리지가 부족해질 수 있습니다. 다음은 로컬 스토리지 공간을 사용할 수 있는 로깅 파라미터의 예입니다. 이 사용량이 발생하는 이유는 로깅이 과도하기 때문일 수도 있고, 시스템이 오류 로그를 오랫동안 유지하기 때문일 수도 있습니다.

과도한 로깅을 초래하는 파라미터를 알아보려면 다음 단계를 완료하십시오.

1. PostgreSQL 로그를 분석해 가장 큰 로그를 찾습니다.
2. 해당 로그에서 항목의 대부분을 차지하는 파라미터를 찾습니다.
3. 과도한 로깅을 초래하는 파라미터를 수정합니다.

파라미터 예시:

rds.log_retention_period
auto_explain.log_min_duration
log_connections
log_disconnections
log_lock_waits
log_min_duration_statement
log_statement
log_statement_stats

기본적으로, 실패하고 오류가 발생하는 쿼리를 반복해서 실행하면 PostgreSQL이 해당 오류를 PostgreSQL 오류 로그에 로깅합니다. 과도한 스토리지 사용을 방지하려면 로그에서 오류를 검토한 다음 실패하는 쿼리를 수정하십시오. 아니면 rds.log_retention의 기본값을 3일에서 줄여서 오류 로그가 사용하는 공간을 회수하는 방법도 있습니다.

과도한 로깅을 방지하려면 인스턴스 클래스를 더 큰 인스턴스 클래스로 변경하는 것이 좋습니다. 이렇게 하면 Aurora DB 인스턴스용으로 사용 가능한 로컬 스토리지가 더 많이 제공됩니다.

관련 정보

Amazon Aurora PostgreSQL의 모범 사례