Aurora PostgreSQL orphaned file 발생 관련 정리

메이저 버전 업그레이드를 운영 환경에서 진행한 이후 급작스럽게 volume usage가 늘어나는 현상이 발생하였다.
DB 레벨에서의 사이즈는 volume usage와 비슷하였지만 테이블+인덱스 사이즈들의 총합이 특정 db에서만 큰 차이가 확인되어(약 900기가~1테라) temp 사용 부분을 확인해보아도 용량이 맞지가 않던 부분들이 확인되었었다.

 

해당 작업 관련하여 clone db 생성하여 동일한 업그레이드 테스트 진행시에 발생하지 않았던 부분이었기에 원인 분석을 aws 측에 요청하였다.

다행히 auto provision이 되는 aurora 특성상 장애 포인트로 이어지지는 않지만, RDS PostgreSQL 사용중이었다면 대응을 해야 할 정도로 빠른 증가폭을 보였다.(증가 시점 시간당 200기가씩 증가하였음.)

 

약 900GB 정도 데이터베이스 사이즈가 늘어난 뒤에는 더 이상 늘어나지 않았고, 관련하여 원인을 kafka 연동이나 DMS로의 연결에 필요한 logical decoding 관련 이슈가 발생한 것으로 의심하고 있지만, 아직까지 aws측의 원인 분석은 받지 못한 상황이다.

 

다만, 발생하는 것 자체를 인지하기 힘들기도 하고 실제 데이터가 늘어나는 것인지, 이렇게 조치를 취해야 하는 상황인지를 파악하기 위한 쿼리를 작성하여 아래 내용에 정리해놓는다. 해당 쿼리를 .psqlrc에 정의하여 간단하게 매일 확인이 가능하도록 조치하고 있으며 데이터독 custom metric으로도 활용 가능.

 

aws 에서 해당 쿼리들에 대한 결과로 현재 상황에 대한 파악을 마친 뒤에는 내부 팀에 연락하여 oid가 존재하지 않는 orphaned file들을 정리하는 작업을 진행하여 현재는 볼륨 관련 이슈는 일단락은 된 상태이다.

 

• 아래의 쿼리는 aurora에서 제공하는 aurora_stat_file() 함수를 통해 OS 레벨 접근이 되지 않는 BASE 디렉토리 내의 파일 목록을 가져와서 실제 pg_class에 존재하는 oid인지 비교 후 실제 pg_class에 존재하지 않는 oid라면 orphaned file이라고 인지하고 이 값들의 sum 값을 더해서 결과를 돌려주는 쿼리이다.

  with cte as (
  select
      filename,
      split_part(filename,'/',2) as doid,
      split_part(split_part(split_part(filename,'/',3),'_',1),'.',1) as toid,
      sum(allocated_bytes) as size,
      count(split_part(split_part(filename,'/',3),'_',1)) filecount
    from aurora_stat_file()
   where (split_part(filename,'/',2) is not null and split_part(filename,'/',2)!='')
     and split_part(filename,'/',2) ='16404' -- 해당하는 db oid 입력
   group by filename,doid,toid
  )
  select pg_size_pretty(sum(size))
    from cte ct
    left join pg_class pc
      on pc.oid::text=ct.toid
   where pc.relname is not null
  ;
  
   pg_size_pretty
  ----------------
   1002 GB
  (1 row)

---

 

참조:
https://www.dbi-services.com/blog/can-there-be-orphaned-data-files-in-postgresql/