聊聊PG資料庫的防誤刪除問題

做DBA這二十多年裡，誤刪除資料是處理起來最麻煩的事情。早期遇到過一個案例，當時的一個視覺化開發工具是把所有程式碼都儲存在一個Oracle資料庫裡的，而這個資料庫放在一臺普通的PC機上，並未做任何備份。有一次一不小心，被人把一個使用者的資料全刪了。這下子這個政府部門的業務系統都跑不起來了。後來我花了幾天時間才恢復了大部分資料，湊合讓大部分應用都恢復了。

Oracle的各種防誤刪除的方法已經被國內的第三方服務企業都研究的比較透了，這些年大部分的此類問題，都能夠透過一些工具或者特殊的方法實現恢復。不過現在很多企業都在將資料庫轉移到開源與國產化的環境。在這些新環境下，資料恢復依然是作為剛需存在的。今天我們來簡單聊聊PG資料庫的誤刪除恢復問題，因為目前很多國產資料庫都與PG同源，或者是基於PG社群版定製的。

防誤操作的底線是用備份恢復資料，資料庫備份也是資料庫運維的底線。如果實在沒辦法在線上庫中恢復資料的時候，使用備份集來恢復資料是十分重要的。可能有朋友會說了，我們有主備庫，是不是不需要備份了。這個觀點是錯誤的，主備庫只是高可用的方案，不能替代備份。當你誤刪一張表的時候，備庫也會被誤刪。只有備份才能透過離線恢復來恢復你所需要的所有資料。為了確保備份集的可靠性，至少保留兩個全備也是十分必要的。

除了備份之外，我們還可以透過規範一些操作來實現比較方便的誤刪恢復。與Oracle不同的是，PG的DDL是可以rollback的。在PG資料庫中，TRUNCATE、DROP等操作開始的時候，還會保留原有的檔案。比如TRUNCATE TABLE的時候，首先會建立一個新檔案作為資料儲存，原來的檔案還保留著。當你執行rollback的時候，原來的資料可以很方便地恢復。不過一旦COMMIT，那麼老的資料檔案就會被從OS層面刪除。

基於此，要想實現PG資料庫被DROP/TRUNCATE的資料能夠恢復，還需要考慮作業系統的恢復問題。我們在選擇檔案系統的時候，一定要選擇一個可恢復的帶日誌的檔案系統，比如XFS/EXT等。並且要開啟並設定好日誌。開啟檔案系統日誌，可能會對寫操作有一些效能影響，不過對於絕大多數系統來說，這點影響完全是可以接受的，為了確保安全，啟用日誌十分有必要。

除此之外，我們還要把OS層面的UNDELETE工具準備好，一旦遇到需要恢復資料的事情，立馬透過UNDELETE工具恢復被刪除的資料檔案。一旦資料檔案被恢復回來了，那麼從檔案中匯出資料就是十分容易的事情了。目前在GIT上，有大量的開源工具可以用來從PG資料檔案中下載資料。因此對於有個企業來說，在部署PG資料庫的時候，應該考慮準備好undelete工具，並在有比較靠譜的undelete工具的檔案系統上部署PG資料庫。

實際上在使用比較複雜的方式恢復資料之前，我們還有更好的解決方法，比如使用psql工具的時候，把自動提交關閉，這樣的話在第一時間，我們還可以透過DDL ROLLBACK來實現最簡單的恢復。養成好的習慣或者規範化操作行為也是避免出大事的最好的方法。

最後一點，相對於Oracle資料庫的段管理的模式，PG的整個後設資料相對還是有點繞的。有時候如果我們手頭有完整的後設資料的歷史資訊，那麼在資料恢復的時候，可以很快的找到需要恢復的檔案，從而可以在備份集中快速找到要恢復的資料，並用工具完成快速恢復。因此為了避免恢復資料時過於複雜，定期備份PG的關鍵後設資料也十分重要。