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を持ち、表xの主キーである外部キー・フィールドaと、表bの非NULL外部キー制約を使用してリンクされています。データベースサーバーは仮想マシンでホストされます。サーバーは唯一のノードであり、他のサーバーへの複製はありません。システムがクラッシュすることはありませんでした。クラッシュするサーバーやポストグルサービスがインデックスを破損する可能性があることはわかっていますが、ポストグラムサービスは利用できなかった非常に長い時間の間、この問題が明らかになる前に立ち上がった。

このすべてのデータは、問題がインデックスが正しく機能していなかったことを示しています。破損したインデックスに関する私の研究は、一般的に2つの原因、postgresqlのバグ、またはハードウェアの障害を指しています。

ハードウェアの不具合やデータベース自体の不具合の解決策は、ハードウェアの購入とインデックスの整合性をチェックし、必要に応じて修正するためのプログラムの作成という根本的に異なる技術を使用して解決されます問題点。

各理論（ハードウェアの故障とソフトウェアのバグ）の証拠として、どのような証拠を収集できますか？

Answer 1

ハードウェアの問題を防ぐには、クラスタを作成するときに--data-checksumsオプションをinitdbに設定してページチェックサムを有効にします。
しかし、それは過去の問題を調査するのには役に立たず、データベースクラスタのダンプ/リロードが必要です。

物理バックアップ（pg_basebackupまたはpg_start_backup()とpg_stop_backup）を使用すると、状況が最後のバックアップを見つけることが面白いでしょう。それは面倒かもしれませんが、問題を探すために窓を狭めるでしょう。

fsync = offまたはfull_page_writes = offがありますか？またはunreliable storageを使用していますか？バグがなくてもハードウェアが正常であっても、クラッシュによってデータベースが破損する可能性があります。データベースログでクラッシュがないかどうか確認してください。

ハードウェアの問題があるかどうかを確認するには、オペレーティングシステムのログファイルを見て、ハードウェアテストを実行します。

既知のソフトウェアの問題を確認するには、release notesを参照してください。インデックスが壊れている場合は、pgsql-hackers mailing listにヘルプを依頼することができます。