PostgreSQL塊損壞模擬修復(fù)

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

　　測試環(huán)境

　　1、創(chuàng)建表測試

　　2、查看數(shù)據(jù)路徑

　　3、 checkpoint

　　記得做checkpoint，不然可能dd導(dǎo)出的數(shù)據(jù)是空的

　　4、備份數(shù)據(jù)文件

　　5、查看塊數(shù)據(jù)

　　我們查看第10塊的數(shù)據(jù)，總共有185條數(shù)據(jù)

　　6、導(dǎo)出塊數(shù)據(jù)

　　將第10個數(shù)據(jù)塊導(dǎo)出：

　　7、替換數(shù)據(jù)

　　8、對比

　　9、模擬文件損壞

　　將替換的數(shù)據(jù)寫入到數(shù)據(jù)文件中，來模擬數(shù)據(jù)文件損壞

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

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

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

　　11、重建索引報錯：

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

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

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

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

　　1、查看checksum是否打開，0表示關(guān)閉，1表示打開

　　2、關(guān)閉數(shù)據(jù)庫，打開checksum

　　3、開啟checksum

　　4、模擬數(shù)據(jù)損壞

　　5、使用dd

　　打開checksum能夠復(fù)現(xiàn)出塊損壞的報錯

　　6、使用checksum檢查塊

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

　　7、轉(zhuǎn)換

　　將checksum報錯16進(jìn)制轉(zhuǎn)換為2進(jìn)制剛好能對上

　　8、打開zero_damaged_pages

　　打開checksum后能復(fù)現(xiàn)報錯，嘗試使用zero_damaged_pages來忽略壞塊

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

　　1、關(guān)閉checksum

　　2、 啟動數(shù)據(jù)庫查詢數(shù)據(jù)，發(fā)現(xiàn)數(shù)據(jù)發(fā)生了錯誤

　　3、zero_damaged_pages

　　設(shè)置后還是有數(shù)據(jù)沖突的問題，當(dāng)數(shù)據(jù)重復(fù)且能正常查詢出來的時候設(shè)置zero_damaged_pages這個參數(shù)已經(jīng)沒有效果，因?yàn)閿?shù)據(jù)已經(jīng)正常只是索引里面沖突了，zero_damaged_pages不能解決數(shù)據(jù)沖突的問題

　　小結(jié)：也就是說沒有開啟checksum下的數(shù)據(jù)文件損壞，可能導(dǎo)致查詢到錯誤的數(shù)據(jù)

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

　　1、我們用第一個模擬文件損壞來實(shí)驗(yàn)

　　打開checksum以后復(fù)現(xiàn)：

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

　　2、從讀庫還原壞塊

　　使用dd將備份的數(shù)據(jù)文件替換進(jìn)去，加入11121060_bak是流復(fù)制中讀庫的數(shù)據(jù)

　　3、重啟數(shù)據(jù)庫

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

　　生產(chǎn)環(huán)境謹(jǐn)慎使用，如果沒有備份，可以抹除掉損壞的塊

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

　　如果不加conv=notrunc，將會丟失大量數(shù)據(jù)

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

　　抹除后執(zhí)行vacuum

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

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

　　1、根據(jù)報錯找到對應(yīng)的壞塊

　　將數(shù)據(jù)分別插入到臨時表中

　　對整庫進(jìn)行備份，讓運(yùn)維人員對整個磁盤設(shè)備進(jìn)行檢查是否有壞塊，并修復(fù)壞塊

　　另外看到說可以刪除壞塊的方式，測試發(fā)現(xiàn)不可行

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

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

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

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

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

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

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

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

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