阿里雲認證帳號購買 阿裡雲 RDS PostgreSQL 磁碟空間因 WAL 日誌堆積爆滿的緊急處理
一、先看結論：磁碟爆滿時，第一目標是先止血
阿裡雲 RDS PostgreSQL 的磁碟空間突然告急，很多時候不是業務資料暴增，而是 WAL 日誌持續堆積，把整個磁碟慢慢吃滿。這類問題最麻煩的地方，不在於它難理解，而在於它發作快、影響大、留給人的反應時間很短。一旦磁碟寫滿，資料庫可能先出現寫入失敗，接著是主從延遲升高、事務提交變慢，嚴重時甚至會引發服務不可用。
處理這種故障，順序非常重要。不是先急著看歷史配置，也不是一上來就重啟資料庫，而是先確認是不是 WAL 堆積，再立即採取能釋放空間的措施，同時保住資料安全和線上可用性。簡單說，正確思路是先保命，再找病因，最後做預防。
二、WAL 為什麼會把磁碟撐爆
阿里雲認證帳號購買 WAL 是 PostgreSQL 的事務日誌機制，全名是 Write-Ahead Logging。每一次資料變更，都會先寫入 WAL，再寫入資料頁。這樣做的好處是即使服務異常，也能靠日誌做恢復。問題在於，WAL 不只是用來恢復，還會被複製、歸檔、保留給備份或複製槽使用。一旦某個環節卡住，WAL 就不會被及時回收，於是磁碟空間開始被一點點吞掉。
常見的堆積原因主要有幾類：
- 長事務沒有提交，導致系統無法回收舊版本相關的 WAL。
- 複製槽長時間不消費，WAL 被強制保留，無法刪除。
- 備份或歸檔異常，造成 WAL 一直等待處理。
- 主從延遲嚴重，從庫追不上，主庫只能保留更多日誌。
- 業務短時間大量寫入，超過預期峰值，WAL 快速膨脹。
阿里雲認證帳號購買 很多人第一次遇到這種情況時，看到磁碟空間突然掉到危險線，會直覺認為是資料表暴增或索引膨脹。其實在 PostgreSQL 裡，真正的元兇往往不是資料本身，而是 WAL 的保留策略和下游消費速度出了問題。只要抓錯方向，就會把時間浪費在無效排查上。
三、緊急處理的原則：先確認風險，再恢復空間
當 RDS PostgreSQL 的磁碟快滿時，最怕的是操作順序錯誤。比如在不知道 WAL 還在被誰占用的情況下，直接刪檔、停庫、重啟，可能會讓情況更糟。正確的做法是先判斷當前還能不能安全寫入，再確定是哪些 WAL 佔著不放，最後再選擇釋放空間的手段。
實戰中可以按這個節奏處理：
- 先確認磁碟餘量是否已經低於安全線，是否存在寫入失敗風險。
- 立刻觀察 WAL 增長趨勢，判斷是不是持續上漲而不是短暫波動。
- 檢查是否存在異常複製槽、長事務、備份任務失敗或歸檔異常。
- 能安全清理的先清理，不能清理的先阻斷源頭，避免繼續膨脹。
- 必要時提升磁碟容量，為排查和恢復爭取時間。
很多緊急事故其實不是靠一次性修復解決的，而是靠先把現場穩住。只要磁碟空間已經逼近零，任何延遲都可能讓資料庫進入更危險的狀態。所以第一個動作不是追求完美，而是先讓系統恢復喘息空間。
四、排查重點：先找出是誰在保留 WAL
1. 複製槽是否失控
複製槽是 WAL 堆積的高風險點之一。只要某個槽一直不消費，主庫就必須替它保留對應的 WAL，哪怕這些日誌早就已經不再需要。這種情況常見於下游備庫故障、同步程序停止、應用端忘記釋放槽，或測試環境遺留了未清理的槽位。
如果發現某個複製槽長時間 inactive，或者它對應的 restart_lsn 落後得很嚴重，那它就是優先嫌疑人。此時要先確認這個槽還有沒有業務價值。若已經確定沒有用途，應盡快清理；若仍然在使用，則要優先恢復下游消費能力，而不是讓主庫無限制地保留 WAL。
2. 是否存在長事務
長事務是另一個常見卻容易被忽略的原因。當一個事務長時間不提交，資料庫需要為它保留可見性所需的舊版本資訊，很多清理動作也就無法順利進行。這類問題有時表面上看不出異常，實際上只是某個批次任務卡住了，或者某個應用連線忘記結束事務。
判斷長事務時，重點不是只看有沒有跑 SQL，而是看事務持續時間、狀態是否 idle in transaction、是否反覆佔用同一連線。當長事務和高寫入量同時存在時，WAL 會堆得特別快，因為新的變更在增加，而舊的日誌又不能回收。
3. 歸檔與備份鏈路是否卡住
如果資料庫配置了歸檔或依賴備份鏈路，WAL 也可能因為外部系統異常而保留過久。這種情況在日常看起來不一定立刻報警，但一旦堆積超過臨界點，磁碟壓力就會迅速上升。尤其是當備份任務失敗、對象存儲異常、網路抖動或權限配置錯誤時，WAL 清理節奏就會被打亂。
這類問題的特徵是：主庫內部沒有明顯長事務，複製槽也未必異常，但 WAL 目錄仍然持續增長。這時就要把注意力放到歸檔狀態、備份任務返回結果，以及雲平台上的相關監控和告警。
五、可落地的緊急處理步驟
1. 先擴容，給系統留出生命線
在磁碟已經逼近滿載時，最穩妥的第一步通常是先做容量擴展。對 RDS 來說，擴容往往比臨時手工清理更安全，也更符合線上操作邏輯。因為擴容不會直接改變資料結構，風險相對可控，卻能立刻降低寫入失敗的可能性。
需要注意的是，擴容不是解決問題本身，而是爭取時間。它的作用是把故障從立即爆炸，延後到可分析、可處理的狀態。沒有這一步，後面的排查很可能因為磁碟已滿而卡住，連查詢系統表都會變得困難。
2. 釋放無效 WAL 保留
如果確定是某個失效的複製槽、過期的測試槽位，或已經無價值的保留點占用了大量空間，就要果斷清理。這一步要非常謹慎，原則是先確認下游是否真的不再需要這些日誌。一旦誤刪仍在使用的槽位，雖然磁碟空間會回來，但下游同步可能直接斷鏈，甚至導致資料恢復風險上升。
如果是備份或歸檔鏈路失敗，應該先恢復鏈路，再觀察 WAL 是否開始回收。很多時候，當外部節點恢復正常後，主庫無需做過多手工動作，堆積的 WAL 就會逐步下降。
3. 立即處理長事務與異常連線
對於已經確認的長事務，最有效的方式通常是終止相關連線，讓事務盡快釋放資源。這一步要結合業務影響評估，不能只看資料庫角度。對線上核心交易來說，某些長事務背後可能是批次任務、報表導出或補償流程，終止前最好先確認會不會造成更大連鎖反應。
但在磁碟快滿的緊急情境中，猶豫的成本往往高於處理的成本。只要已經確認它是造成 WAL 無法回收的直接原因，而且繼續保留只會讓系統惡化，就應該及時處理。
阿里雲認證帳號購買 4. 控制新增寫入量
如果業務側正在進行大批量寫入，建議同步做限流或暫停部分非核心任務。原因很簡單：當系統已經處於危險邊緣時，繼續大量寫入只會讓 WAL 成倍增加，讓擴容和清理的效果被迅速抵消。這時候把流量壓下來，比事後補救更有效。
實務上，可以先暫停批次匯入、清理任務、報表同步、資料回補等非即時流程，優先保住核心交易路徑。等磁碟壓力解除、根因定位完成後，再逐步恢復。
六、處理後怎麼驗證是否真正恢復
故障處理完，不代表問題已經結束。真正的恢復要看三件事：磁碟是否停止下降、WAL 是否停止異常增長、下游同步是否回到正常節奏。如果只是臨時擴容，卻沒有把 WAL 堆積源頭清掉，那空間很快還會再被吃光。
驗證時可以持續觀察這些信號：
- 磁碟使用率是否從高位回落，且回落後保持穩定。
- WAL 目錄增長是否恢復到正常波動範圍。
- 複製槽是否還存在明顯滯後。
- 是否還有長事務持續存在。
- 備份、歸檔、同步任務是否全部恢復成功。
如果這些指標只是表面正常，但過一陣子又重新上漲，說明根因還沒處理乾淨。這種半恢復狀態最危險，因為它會給人一種錯覺，讓團隊以為問題已經解掉，實際上只是把爆點往後推了一點。
七、事後復盤：別讓同樣的故障重演
WAL 堆積導致磁碟爆滿，從結果看是空間問題，從本質看卻是運維治理問題。真正成熟的做法，不是每次出事都靠人工救火，而是把故障前的徵兆、處置流程和責任邊界都固定下來。這樣下次再遇到同類事件，就不會全靠某個人臨場判斷。
建議從以下幾個方向補強：
- 建立 WAL 增長與磁碟使用率的預警閾值，提前告警。
- 對複製槽做定期巡檢，清理無效槽位。
- 限制長事務持續時間，對 idle in transaction 設置監控。
- 把歸檔、備份、同步任務納入統一監控。
- 為高峰寫入場景預留足夠磁碟餘量，不要把容量規劃壓得太緊。
還有一點很重要：團隊要明確什麼情況下可以直接擴容，什麼情況下必須先處理業務風險。因為磁碟滿只是表象，真正的事故常常發生在判斷不一致的地方。有的人覺得先停業務，有的人急著重啟，有的人只想刪日誌，最後誰都動了，卻沒有人完整收尾。
阿里雲認證帳號購買 八、把這類故障變成標準作業
阿裡雲 RDS PostgreSQL 因 WAL 堆積而爆滿，並不是罕見事故，但它很考驗團隊的基本功。處理這類故障，最重要的是保持清醒：先確認是不是 WAL 問題，再用最小風險方式為系統騰出空間，接著快速定位保留源，最後把監控、告警和作業流程補上。
真正有價值的不是一次救回來，而是救回來之後，團隊下次不再用同樣的姿勢摔倒。只要把複製槽、長事務、歸檔備份和容量預警這幾個環節管住，WAL 堆積就不會再輕易把磁碟推到崩潰邊緣。對線上系統來說，穩定不是運氣，而是把每一次故障都轉成標準流程的結果。
