監控和處理 TOAST 膨脹的突然跳躍

我正在嘗試診斷我的一個數據庫（執行 11.4）中磁碟使用率的突然跳躍。通常，數據庫每天增長約 1 GB，但最近在 24 小時內增長了近 100 GB。

查看各種統計數據，我得出結論，增長來自特定的 TOAST 表。該表用於BYTEA儲存幾個 MB 的加密 blob 的列。大約有 1000 行，但 TOAST 表佔用 400 GB。

這些行在首次創建後的幾天內會頻繁更新，然後就不會再被觸及。

數據庫是多可用區 RDS 部署，所以我最好的假設是複制落後，導致一堆元組保持活動狀態，並使 TOAST 表突然增長。

這是一個合理的假設嗎？我如何確認是否是這種情況？有什麼可能的解決方法來避免這種情況再次打擊我們？

---

附加數據：

• 該pg_toast表有大約 900k 的活動元組
• 死元組今天早上為 5.2M，但現在為 1.7M
• 儘管基礎表上的活動仍在繼續，但該表在pg_table_size幾個小時內並未出現任何變化pg_toast

如果要檢查表的膨脹程度，應安裝pgstattuple擴展並pgstattuple()在可疑表上執行。如果表格很大，就像您的情況一樣，您可以使用它pgstattuple_approx()來獲得近似值。

關於您的假設，我認為多可用區不能解釋您的問題，因為 PostgreSQL 多可用區複製是同步的。主伺服器和備用伺服器之間的網路問題會停止主伺服器上的活動。

其他可能的解釋可能是：

1. Autovacuum 無法趕上許多刪除或更新。這可能是由於與該查詢無關的數據庫負載而發生的。查看您的日誌和 CloudWatch 指標以獲取線索
2. 如果您有一個正常的只讀副本（不是多可用區），那麼您的假設可以解釋發生了什麼。有一個顯示複製滯後的 CloudWatch 指標。

除了 autovacuum 無法跟上UPDATEs 的可能性之外，還可能是您有一個長時間執行的事務，使 autovacuum 無法清理死 TOAST 條目。

引用自：https://dba.stackexchange.com/questions/274100