☰

減少主/基地神秘堆積物的大小

tag-icon • tag-icon postgresql postgresql-9.3
減少主/基地神秘堆積物的大小

使用 PostgreSQL 9.3。我有一個長時間運行的查詢，更新了大約 800 萬行。顯然出了什麼問題。 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就我而言，是資料庫的 oid。你可以看到它是哪個資料庫，如下所示：

SELECT oid, * FROM pg_database

裡面的每個檔案都以 pg 類型（表或其他）的 oid 命名。最大的文件可能來自最大的表。連接到資料庫並從pg_class集合中選擇以找出哪個。

現在我正在使用將資料庫移至自訂表空間

ALTER DATABASE mydb SET TABLESPACE mytablespace;

我很確定這會解決我的問題。

相關內容