PostgreSQL塊損壞模擬修復

　　報錯信息：ERROR:   invalid page in block 10 of relation "base/13593/11025587"

　　測試環境

　　1、創建表測試

　　2、查看數據路徑

　　3、 checkpoint

　　記得做checkpoint，不然可能dd導出的數據是空的

　　4、備份數據文件

　　5、查看塊數據

　　我們查看第10塊的數據，總共有185條數據

　　6、導出塊數據

　　將第10個數據塊導出：

　　7、替換數據

　　8、對比

　　9、模擬文件損壞

　　將替換的數據寫入到數據文件中，來模擬數據文件損壞

　　需要加入conv=notrunc，保證只替換第10頁，不加的話10頁后面的數據都丟失了。

　　這樣表中就有兩條一樣的數據了，但是還是能查詢出來，表也沒報錯

　　神奇的是，該sql能走索引，而且查詢出來了。這里檢查了zero_damaged_pages=off，并未打開

　　11、重建索引報錯：

　　未能復現出ERROR:  invalid page in block 10 of relation 的報錯但是很明顯數據確實被破壞了，表中有重復的數據，而且索引重建沖突

　　上面還有一點，vacuum full沒有報錯，而reindex的時候報錯了，我們都知道vacuum是會清理掉索引膨脹的，單并沒有重建這個索引。上面替換進去的頁被正常查出來了，但是數據也是重復的。

　　從這篇文章來看要開啟checksum才會報頁面損壞，如果不開的話，很可能就是上面的情況，只是數據沖突，還是能繼續訪問。上面的測試基于pg12.3https://blog.csdn.net/weixin_43230594/article/details/123781575

　　打開checksum，然后使用dd模擬壞塊

　　1、查看checksum是否打開，0表示關閉，1表示打開

　　2、關閉數據庫，打開checksum

　　3、開啟checksum

　　4、模擬數據損壞

　　5、使用dd

　　打開checksum能夠復現出塊損壞的報錯

　　6、使用checksum檢查塊

　　停掉數據庫使用checksum檢查，可以可能出我開始手動損壞的塊都檢測出來了，但是查詢是正常的

　　7、轉換

　　將checksum報錯16進制轉換為2進制剛好能對上

　　8、打開zero_damaged_pages

　　打開checksum后能復現報錯，嘗試使用zero_damaged_pages來忽略壞塊

　　可以看到確實可以訪問表了，但是警告仍然存在，這給了我們操作空間，能訪問意味著我們可以備份這個表

　　1、關閉checksum

　　2、 啟動數據庫查詢數據，發現數據發生了錯誤

　　3、zero_damaged_pages

　　設置后還是有數據沖突的問題，當數據重復且能正常查詢出來的時候設置zero_damaged_pages這個參數已經沒有效果，因為數據已經正常只是索引里面沖突了，zero_damaged_pages不能解決數據沖突的問題

　　小結：也就是說沒有開啟checksum下的數據文件損壞，可能導致查詢到錯誤的數據

　　我們再次復現上面第一個例子，先打開checksum，看能檢查出報錯，另外就是備份數據文件，看能否從備份的數據文件中還原損壞的塊

　　1、我們用第一個模擬文件損壞來實驗

　　打開checksum以后復現：

　　也就是說如果一開始打開了checksum，那么檢測出損壞的塊，即使后面關掉checksum仍然會報錯

　　2、從讀庫還原壞塊

　　使用dd將備份的數據文件替換進去，加入11121060_bak是流復制中讀庫的數據

　　3、重啟數據庫

　　有高可用情況可以非常快速的恢復，且不丟失數據dd抹除

　　生產環境謹慎使用，如果沒有備份，可以抹除掉損壞的塊

　　1、dd抹除，conv=notrunc 會阻止 dd 截斷表的其余部分。

　　如果不加conv=notrunc，將會丟失大量數據

　　表示塊大小，seek標識第10塊，count=1標識總共處理1塊，if標識輸入的文件，of標識輸出的文件

　　抹除后執行vacuum

　　我們可以看到最開始插入的數據是20000001，剛好相差185條數據，也就是丟失了第10頁的數據導出正常數據

　　如果害怕dd使用有問題，那么我們可以考慮將正常的數據導出使用sql來處理，導出非壞塊的數據

　　1、根據報錯找到對應的壞塊

　　將數據分別插入到臨時表中

　　對整庫進行備份，讓運維人員對整個磁盤設備進行檢查是否有壞塊，并修復壞塊

　　另外看到說可以刪除壞塊的方式，測試發現不可行

　　如上打開checksum示例，我們可以打開這個參數來忽略壞塊，然后備份數據，當然某些情況下這個參數也不好使，還得用上面兩種方法

　　1、在沒有打開checksum的情況下塊損壞后還是能訪問，但是數據錯誤

　　2、如果報錯頁損壞invalid page in block of relation base ，那么可以設置zero_damaged_pages=on一般就可以訪問表，使用dump的方式將數據備份出來。

　　3、第2步如果不行那么就需要特殊處理

　　常見的方式有使用dd抹除損壞的這個頁，另外就是使用臨時表的方式將有用的數據導出來，然后還原數據

　　4、如果有做高可用，那么可以直接從備庫的數據文件中還原損壞的塊，此辦法較快

　　5、checksum可以檢查具體有那些塊是損壞的，然后針對全庫進行修復

　　6、做好備份，并且定期檢查備份的正確是很有必要的。塊損壞會導致備份失敗

　　zero_damaged_pages：檢測到損壞的頁頭通常會導致PostgreSQL報告錯誤，中止當前事務。設置為 on 會導致系統報告警告，將內存中損壞的頁面清零，然后繼續處理。這種行為會破壞數據，即損壞頁面上的所有行。但是，它確實允許您克服錯誤并從表中可能存在的任何未損壞的頁面中檢索行。如果由于硬件或軟件錯誤而發生損壞，它對于恢復數據很有用。在您放棄從表的損壞頁恢復數據的希望之前，您通常不應設置此選項。清零頁不會被強制寫入磁盤，因此建議在再次關閉此參數之前重新創建表或索引。默認設置為，并且只能由超級用戶更改。