Postgresql索引損壞的原因 - postgresql的錯誤或硬件故障

Question

我有postgresql 9.5.2生產服務器，有一些嚴重的索引問題。最強的證據支持這種說法是有些疑問的不一致：

select count(*) from x inner join y on x.a = y.a 
select *  from x inner join y on x.a = y.a 

的COUNT（*）查詢將返回不同數量比選擇*查詢，剛剛返回的行返回的行數。我嘗試的第一件事是真空分析，但這並沒有解決問題。最後，爲了讓服務器再次運行，刪除所有索引並重建它們，此時select *和select count（*）查詢之間的結果變得一致。

這兩個表都沒有任何觸發器。表x有170萬行，表y有690萬行和600,000行刪除，並且這些表使用外鍵字段a（它是表x中的主鍵）和表b中的非空外鍵約束。數據庫服務器位於虛擬機中。服務器是唯一的節點，並且不會複製到其他服務器。系統從來沒有崩潰，所以雖然我知道崩潰的服務器或postgres服務可能會損壞索引，但我沒有理由相信發生這些事件的原因之一，因爲：a）postgres服務從未不可用; b）服務器指出它有這個問題早在這個問題出現之前就已經存在很長時間了。

所有這些數據都表明問題是索引無法正常工作。我對損壞索引的研究通常指向兩個原因，postgresql中的錯誤或硬件故障。

硬件故障的解決方案和數據庫本身的錯誤是通過完全不同的技術來解決的，即一種涉及採購硬件，另一種涉及編寫程序來檢查索引的完整性，並在必要時採取適當的措施來糾正問題。

我可以收集哪些證據來支持每種理論（硬件故障與軟件錯誤）？

Answer 1

防止硬件問題的最佳防範措施是在創建羣集時通過使用initdb的--data-checksums選項啓用頁面校驗和。
但這不會幫助調查過去的問題，它需要轉儲/重新加載數據庫集羣。

如果你做物理備份（與pg_basebackup或pg_start_backup()和pg_stop_backup），這將是有趣的發現上一次備份，事情仍然正常。這可能很乏味，但它會縮小尋找問題的窗口。

您有fsync = off或full_page_writes = off？或者你使用unreliable storage？那麼即使沒有錯誤並且硬件沒問題，您的數據庫也可能會因崩潰而損壞。檢查數據庫日誌是否存在崩潰。

要了解您是否遇到硬件問題，請查看操作系統日誌文件並執行硬件測試。

要檢查已知的軟件問題，請查看release notes。如果您的索引損壞，您可以要求pgsql-hacker mailing list尋求幫助。