今天業務系統遭遇了一起資料庫故障.

資料庫端報了一些錯誤.[code]
2017-07-24 00:16:25.514 CST,"pcauto","pcauto",24404,"192.168.11.60:49721",5974c895.5f54,1,"SELECT",2017-07-24 00:02:29 CST,4/149911010,0,ERROR,58P01,"could not access status of transaction 909258544","Could not open file ""pg_clog/0363"": No such file or directory.",,,,,
[/code]

從報錯日誌上看好像是事務日誌缺失了. 好大件事.

然後發現對這個表的全部掃描也失敗了.因為繞不過跟這個事務相關的幾十行記錄.

然後發現這個事務涉及的sql 在從庫上是可以執行.

為了不阻塞業務, 於是啟動了ha 切換.

然後回來處理這個問題. 發現這個問題很棘手. 目前還沒有成熟快速的套路.

借鑑了同行們的幾個方案均失敗. 會跳過這個事務報錯. 但是會報另一個錯誤. block head 損壞.

最終還是無法解決.

終極的解決方法. truncate table 或者drop table 然後從備份集中恢復資料回去.

我們保留了現場: 然後進行了各種演練. 最終都是無解.

參考方案:

根據 BRUCE 大神在郵件列表中的一個回覆:

根據我們主從之間是sync 同步的.

我們初步認為 .這是一個資料庫中行資料的物理損壞, 對應於oracle 的資料塊的物理損壞.

oracle 中會有一個比較完善的報錯,診斷機制. 會報 block 損壞.

pg 這裡的這個報錯.我麼猜測是資料的物理損壞導致 min max 的事務狀態的記錄溢位 .

因為報錯中請求的應該存在於去年的clog 目錄下面才對.

我們最小的clog 檔案 03D1 是2017年一月9號的. 這其中已經過了 8個多月了. 對一個頻繁訪問的業務表.

去年丟的某個日誌, 不應該到現在才報錯. 然後同步的從庫是沒有問題. 從庫也沒有0363 這個檔案,但是卻可以訪問這些記錄.

這業驗證了.這個錯誤可能是資料記錄物理損壞了.如果是邏輯出錯的話,應該會透過事務日誌傳遞到從庫.

PG 資料庫遭遇 pg_clog file missing 故障.

相關文章