排查PostgreSQL WAL日誌堆積 - ApsaraDB RDS

在業務繁忙時，PostgreSQL中的WAL產生量非常大。checkpointer進程會定期清理到期的WAL日誌，但在實際生產中，一些不恰當的使用方式可能導致WAL日誌未被清理，從而佔用大量儲存空間。本文介紹主庫和唯讀庫發生WAL日誌堆積問題時的排查方法。

背景資訊

WAL是PostgreSQL中確保資料安全、提高系統可靠性和效能的關鍵組件。通過WAL機制，PostgreSQL能夠在各種故障情況下保證資料不丟失，並且能夠可靠地進行恢複。

WAL日誌堆積問題發生在主庫時，可以進行以下排查。

複製槽（replication slot）是PostgreSQL高可用性和災難恢複策略的關鍵工具，其最主要的作用是防止WAL被刪除，從而避免複製中斷。然而，當複製槽處於非活躍狀態時，未被清理的WAL日誌會不斷累積，導致日誌增長過快。
消費端未及時上報LSN時，會導致WAL日誌不斷增長。

通過系統檢視表pg_replication_slots可以查看複製槽的各種資訊（包括LSN資訊）。例如，可以通過以下SQL語句來判斷複製槽延遲刪除WAL日誌的大小。

SELECT slot_name, pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_insert_lsn(), restart_lsn)) AS delay_size
FROM pg_replication_slots;

如果查詢得到的結果較大或與WAL日誌堆積量匹配，請根據業務需求評估並刪除相應的複製槽。

wal_keep_segments、wal_keep_size和max_wal_size參數設定過大都可能會導致執行個體保留大量WAL日誌，請檢查這些參數配置並根據業務需求進行調整。

VACUUM風暴通常是指在資料庫中同時發生大量的自動或手動VACUUM操作，這些操作可能會產生大量WAL日誌，從而導致I/O負載顯著增加，影響資料庫效能，同時也可能導致WAL無法被及時清理。建議您根據業務需求合理配置VACUUM參數，規劃VACUUM操作的執行時間。

大規模寫入時出現的情況與VACUUM風暴相似，請根據業務需求合理安排資料寫入。

WAL日誌堆積問題發生在唯讀庫時，可以進行以下排查。

比較常見的是WAL日誌在唯讀庫上的replay延遲，可能的原因有：

唯讀庫上有長時間啟動並執行事務，與WAL日誌的replay產生衝突。請根據業務需求評估並調整相關參數（hot_standby_feedback和max_standby_streaming_delay）。
例如，在hot_standby_feedback=off，且max_standby_streaming_delay設定較大時，唯讀庫上運行長事務可能會導致replay延遲。
主庫和唯讀庫的規格配置存在差異。如果唯讀庫的計算和儲存配置低於主庫，可能會導致複寫延遲，從而導致未replay的WAL無法清理。請根據業務需求評估並選擇合理的唯讀庫配置。

對於RDS PostgreSQL執行個體，如果上述排查後仍未解決WAL堆積的問題，可聯絡RDS PostgreSQL支援人員進行解決。