去年我寫過一篇文章《PG數據庫離企業級數據庫還有多遠》，實際上對PG了解得越深入，這個問題就越值得我們去思考。前幾天一個做數據庫高可用架構的朋友在我的公眾號上留言，說在PG數據庫中，如果刪除了某一個數據文件，PG數據庫居然不報錯，還能查出數據來，不過查出來的數據是錯的。這一點我以前倒是沒有注意到，數據庫丟失數據文件不報錯是正常現象，不過查詢數據的時候，如果掃描到了這部分內容，按理說應該是會報錯的，比如Oracle就是如此。昨天下班前我正好有點時間，就做了個小實驗。實驗內容有點長，我先講一些結論性的東西，有興趣了解細節的朋友看完結論性的分析后再去看實驗的詳情吧。

數據文件的完整性檢查是一個開銷十分巨大的操作，因此幾乎沒有數據庫會隨時對數據文件的完整性做檢查。連Oracle這種段頁式結構，以表空間為組織模式的數據庫都不會隨時去檢查數據文件的完整性和可用性。只有在訪問某個數據文件的時候才會通過文件頭去做一些校驗。不過對于數據文件中的數據的一致性仍然不會去做檢查。這是一種更大開銷的操作。只有訪問到相關數據的時候才會去做一致性和完整性的檢查（并不是所有的訪問操作都會做）。不過不管如何，RDBMS系統要盡可能保證查詢出來的數據的邏輯一致性，確保數據一定是正確的。

對于Oracle這樣的數據庫，文件的屬性被記錄在control file中，新增一個文件或者文件的大小發生變化的時候，會自動更新數據。對于PG這樣的每張表都會有多個文件來存儲數據的數據庫來說，登記每個使用過的文件是一種十分高成本的操作，一個上TB的表可能就會擁有上千個數據文件。這是一種一致性對于性能的妥協，這種妥協為PG數據庫的數據一致性帶來了巨大的隱患。昨天我的實驗的結論是：“當PG數據文件出現丟失的時候，PG數據庫不一定會因為文件丟失而報錯，而是會直接返回錯誤的數據”。這是一種十分恐怖的特性，對于關鍵性的企業級應用來說，錯誤的數據比丟失數據還要可怕。

下面請大家看我的實驗過程,我使用的PG版本是12.6，如果PG數據庫在新版本中已經修復了我今天實驗中的問題，也請朋友留言告知。先創建一張表，寫入部分數據。從pg_class里可以看到relfilenode是16399。    

圖片

圖片

可以看出目前數據文件存儲在3個文件里。同時有一個fsm文件記錄了空閑空間的情況。我們做個簡單的count查詢。

圖片

沒錯，我剛才寫入了1000萬條數據。然后我們開始作妖，刪除16399.1文件看看會出現什么情況。

圖片

在另外一個窗口用rm命令刪除了文件后，我們查一下這張表的數據：

圖片

這里是報錯了，確實發現了剛才被刪除的文件丟失了。在多次實驗中，我發現有時候不會報錯，可以直接成功。我們先不管不報錯的場景，后面我會補充這方面的數據，現在我們重啟一下數據庫，再來看看。    

數據庫重啟后，居然查詢成功了，只不過數據似乎不太對，少了一些數據，而且少的還不是16399.1里的所有數據，似乎重啟數據庫的時候做了RECOVER。

圖片

回到目錄中再去查看一下。十分奇怪，剛才被刪除的文件又回來了。

圖片

從數據庫的日志中我們可以看到，RDBMS是做了RECOVER，自動恢復了被刪除的文件。不過這個恢復并不完整，但是系統也沒有報錯，這種機制會給我們帶來錯覺，導致業務數據的錯亂，是十分可怕的。于是我再做一次刪除，然后重啟數據庫試試。十分奇怪的是，這回數據庫重啟沒有像上回那樣RECOVER了丟失的數據文件，這種行為的不確定性也說明了PG數據庫在數據一致性檢查方面存在一定的缺陷，不能保持某些恢復行為的一致性，對于企業級數據庫來說，這也是十分致命的。

圖片

圖片

從文件系統上看，這回丟失的文件也沒有恢復。

圖片

我再查詢數據，發現丟失了一半的數據，只有一半數據了。接下來再試試CTAS，完整拷貝這張表的全部數據。這個操作居然成功完成，沒有任何報錯，這說明RDBMS認為當前的數據是完整的，而實際上數據已經產生了嚴重的丟失。接下來測試下寫入數據，這個測試也成功了。

圖片

這是一個十分恐怖的實驗，在我的理解里，FSM里起碼會記錄空塊的情況，丟失文件的問題應該能從查找FSM文件的時候被發現。不過這沒有發生，不過也很容易理解，因為INSERT數據的時候，只需要查空塊就可以了，不一定會發現問題。目前我還沒有從PG的源碼上去分析這個問題，因此還不是很清晰這方面的機理。不過從目前的實驗上看，PG確實存在誤刪文件后不會被發現，導致數據出現錯誤的問題。這種缺陷是十分恐怖的，很多時候不怕丟數據，而是怕丟了數據你不知道。因為對于核心業務系統來說，數據準確性是最為關鍵的。

這回我們換一個玩法，首先我們創建好表數據，然后我們關閉數據庫，再刪除某個文件。重啟數據庫。    

圖片

上圖中黃線后面的操作是我重啟數據庫后做的，發現被刪除的文件沒有被恢復。再看看查詢結果。

圖片

如預期的那樣，沒有報錯，但是結果是錯誤的，少了400多萬條數據。剛才刪除文件前我備份了該文件，把該文件直接拷貝回來看看。

圖片

仍然沒有報錯，正確的結果回來了，是不是很神奇！！！。從上面的實驗可以看到，如果在PG數據庫中丟失某個數據文件，那么數據庫的行為可能是不確定的，不過大概率會給你返回錯誤的數據。這種特性會對于關鍵的企業級應用帶來困難。因此我們必須在盡可能不影響數據庫性能的前提下彌補這個缺陷。至于如何彌補，可能需要對源代碼做一些解讀后才能想辦法。今天的實驗先到這里吧，源代碼的解讀隨后有時間再做。有興趣的朋友也可以去閱讀分析一下。