本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
解決 Aurora PostgreSQL 中無法識別的清空封鎖程式
本節會探索其他可能阻止清空進行的原因。postgres_get_av_diag() 函數目前無法直接識別這些問題。
索引不一致
邏輯上不一致的索引可防止自動清空進行進度。在索引的清空階段或 SQL 陳述式存取索引時,會記錄下列錯誤或類似錯誤。
ERROR: right sibling's left-link doesn't match:block 5 links to 10 instead of expected 2 in indexix_name
ERROR: failed to re-find parent key in index "XXXXXXXXXX" for deletion target page XXX CONTEXT: while vacuuming indexindex_nameof relationschema.table
指引
在手動 INDEX_CLEANUP上使用 重建索引或略過索引VACUUM FREEZE。
- 
          使用 CONCURRENTLY 選項 – 在 PostgreSQL 第 12 版之前,重建索引需要唯一資料表鎖定,限制對資料表的存取。透過 PostgreSQL 第 12 版和更新版本,CONCURRENTLY 選項允許資料列層級鎖定,大幅改善資料表的可用性。以下是 命令: REINDEX INDEX ix_name CONCURRENTLY;雖然 CONCURRENTLY 的破壞性較低,但在忙碌的資料表上可能會變慢。如果可能,請考慮在低流量期間建立索引。如需詳細資訊,請參閱 PostgreSQL 文件中的 REINDEX 。 
- 
          使用 INDEX_CLEANUP FALSE 選項 – 如果索引較大且估計需要大量時間才能完成,您可以在排除索引的同時執行手動 VACUUM FREEZE 來解除封鎖自動清空。此功能可在 PostgreSQL 第 12 版及更新版本中使用。 略過索引可讓您略過不一致索引的清空程序,並減輕包裝問題。不過,這無法解決基礎的無效頁面問題。若要完全解決和解決無效的頁面問題,您仍然需要重建索引。 
異常高的交易率
在 PostgreSQL 中,高交易速率可能會大幅影響自動清空的效能,導致較慢的無效元組清除速度,並提高交易 ID 包圍的風險。您可以透過測量兩個時段max(age(datfrozenxid))之間的差異來監控交易速率,通常是每秒。此外,您可以使用 RDS Performance Insights 的下列計數器指標來測量交易速率 (xact_commit 和 xact_rollback 的總和),這是交易的總數。
| 計數器 | 類型 | 單位 | 指標 | 
|---|---|---|---|
| xact_commit | 交易 | 每秒遞交數 | db.Transactions.xact_commit | 
| xact_rollback | 交易 | 每秒轉返數 | db.Transactions.xact_rollback | 
快速增加表示交易負載很高,可能會壓倒自動清空,導致膨脹、鎖定爭用和潛在的效能問題。這可能會在幾個方面對自動清空程序產生負面影響:
- 
          資料表活動:正在清空的特定資料表可能遇到大量交易,導致延遲。 
- 
          系統資源 整體系統可能會超載,導致自動清空難以存取必要的資源以有效率地運作。 
請考慮下列策略,以允許自動清空更有效地運作並跟上其任務:
- 
          如果可能,請降低交易速率。考慮在可行的情況下批次或分組類似的交易。 
- 
          以經常更新的資料表為目標,在離峰時段內,每夜、每週或每兩週手動 VACUUM FREEZE操作一次。
- 
          考慮擴展執行個體類別以配置更多系統資源,以處理高交易量和自動清空。