☰

메인/베이스 미스터리 빌드 크기 감소

tag-icon • tag-icon postgresql postgresql-9.3
메인/베이스 미스터리 빌드 크기 감소

PostgreSQL 9.3을 사용합니다. 약 8M 행을 업데이트하는 장기 실행 쿼리가 있었습니다. 분명히 뭔가 잘못되었습니다. 2일 후 디스크 공간 부족 경고를 받았습니다. 쿼리를 중단했는데 이것이 제가 본 것입니다.

root@server:/var/lib/postgresql/9.3/main# du -BM * | sort -n
1M  global
1M  pg_notify
1M  pg_serial
1M  pg_snapshots
1M  pg_stat
1M  pg_stat_tmp
1M  pg_tblspc
1M  pg_twophase
1M  PG_VERSION
1M  pg_xlog/archive_status
1M  mydb.opts
1M  mydb.pid
3M  pg_subtrans
7M  base/1
7M  base/12030
7M  base/12035
11M base/22029472
21M pg_clog
72M pg_multixact/offsets
315M    pg_log
444M    pg_multixact/members
516M    pg_multixact
625M    pg_xlog
3493M   base/pgsql_tmp
61851M  base/22053373
65372M  base

참고하세요:61851M base/22053373

내 실제 데이터는 다른 볼륨에 저장된 테이블스페이스에 있으므로 이는 일시적인 트랜잭션 항목이 쌓인 것으로 추정됩니다.

비슷한 문제에 대한 온라인 게시물이 있지만 내가 찾은 정식 해결책은 없습니다. 일반적으로 조언은 "VACUUM FULL 실행"이며 때로는 축적된 찌꺼기가 사라지는 경우도 있습니다. 지금 하고 있는 일이 시간도 걸리고 남은 디스크 공간(3GB)을 다 채워서 모든 것이 다운될까 봐 걱정됩니다.

누구든지 이것에 대한 경험이 있습니까? 여기에는 무엇이 저장되어 있나요? 이 공간을 빠르게 확보할 수 있는 안전한 방법이 있습니까? 아니면 적어도 다른 곳으로 옮기세요(테이블스페이스 디스크에 충분한 공간이 있습니다).

답변1

나는 그것을 알아. 내 실수야. 이것은 사용자 정의 테이블스페이스 대신 동료가 기본 테이블스페이스에 생성한 새 데이터베이스입니다.

비슷한 문제를 겪고 계신 분들을 위해 제가 조사하면서 배운 몇 가지 사항을 알려드리겠습니다. base/22053373내 경우에는 데이터베이스가 필요합니다. 다음과 같은 db를 확인할 수 있습니다.

SELECT oid, * FROM pg_database

내부의 각 파일은 pg 유형(테이블 또는 기타)의 oid 이름을 따서 명명됩니다. 가장 큰 파일은 아마도 가장 큰 테이블에 있을 것입니다. 데이터베이스에 연결하고 pg_class컬렉션에서 선택하여 어떤 것이 있는지 알아보세요.

지금은 다음을 사용하여 DB를 사용자 정의 테이블스페이스로 이동하고 있습니다.

ALTER DATABASE mydb SET TABLESPACE mytablespace;

나는 이것이 내 문제를 해결할 것이라고 확신합니다.

관련 정보