回答:
PostgreSQLには組み込みの整合性チェックコマンドまたはツールはありません。
一般的な見方では、高品質のハードウェア/ソフトウェアスタックでは破損や不整合が発生する可能性がないため、1つにする必要はありません。問題が発生した場合、どのような種類の整合性チェックでも問題が検出される保証はないため、誤った安心感が生じるだけです。私はその意見には同意しませんが、これがpgsql-hackersで定期的に議論されているときに出てくるようです。
いつものように、根本的な問題は、当面のニーズを満たすために整合性チェッカーツールを特に必要としないということです。そのため、かゆみを掻くために時間を費やして開発したり、商用契約や社内ベースで開発に資金を提供したりする人がいません。ボランティア?:p
PostgreSQL(9.3まで)は、ブロックレベルのチェックサムをサポートしていませんでした。そのため、検証に慣れている主なものの1つが存在しないため、検証できませんでした。すべての関係をスキャンしてチェックサムを検証するツールはPostgreSQL 9.3には存在しませんが、追加することが望ましく、将来のバージョンで表示される可能性があります。それSELECT *
までは、各リレーションから個別に実行できますが、PostgreSQLがオペレーティングシステムのバッファキャッシュを読み取りに使用しているため、実際に基盤となるディスクブロックの読み取りを強制する保証はありません。これを行うには新しいツールが必要になります。
PostgreSQLは可能な限り情報を重複して保存することを避ける傾向があるため、多くの場合、確認するものがなく、単一の信頼できるソースのみです。一貫性チェッカーは、同じ情報が表示されるか、複数の異なる場所から派生する場合を除いて、多くのことを行うことはできません。
また、まだビジーでアクティブなデータベースに対して、あらゆる種類の便利なチェックを同時に実行することも非常に困難です。ほとんどのインストールでは、なんらかの整合性チェックを実行するために、データベース全体または少なくともいくつかの主要な関係を一度にロックするつもりはありません。そのため、チェッカーは、同時変更の対象となるデータベースを操作できる必要があり、書き込みをさらに困難にし、より少ない問題を確実に検出できるようにする必要があります。
バリデータツールが記述されている場合、特に複数のリレーション排他ロックを許可されている場合、バリデータツールで実行できることはまだたくさんあります。
すべてのテーブルスペースがディスク上に存在することを確認してください。
各pg_class
エントリに対応するファイルrelfilenode
が正しいテーブルスペースにあることを確認します。
可視性マップ、フリースペースマップなどを検査し、それらが必要なときに存在し、読み取り可能で、関連付けられている関係と一致しているように見えることを確認します。
孤立したディスク上のファイルノードを報告します。(これらは、トランザクションDDLと遅延リンク解除のために正常ですが、チェッカーは、積極的なリンク解除を強制し、チェックを実行する前にすべての関係をロックする可能性があります)。
各関係のすべてのブロックを読み、明らかな問題を探します。次のようなヒープ関係の場合:
xmin
より大きいxmax
(XIDラップアラウンドを考慮後)_in
、_out
機能も変更しないか、エラーをスローするデータムNULL
NOT NULL
テーブル属性に設定されたビットマップフィールドCHECK
制約の再実行が失敗する関連するすべてのテーブルをロックした後、外部キーと除外制約を再確認します
...と、おそらく多くは、より多くの私は、このような破損ページを検出しようと、Bツリー構造の検証、正気チェックGINとGiSTインデックス、健全性のチェックなどを把握するためのPG根性、について十分に知らないpg_control
、そしてより多くの私はいないだろうどこから始めればよいかがわかります。
このようなツールを使いたいと思っている場合、最善の方法は、それがどのように機能するかについて具体的な提案を考え出すために十分に学習することです。開発。
個人的に私はのための特別な起動モード使用して停止し、データベースクラスタをチェックすることができ、何か持って実際にはかなり満足していると思いますpostgres
私は(多少)物理データベースで撮影したコピーを検証できたバックエンドを、のでpg_basebackup
、でpg_start_backup()
、rsyncをしてpg_stop_backup
、ファイル・システム・レベルでの、アトミックスナップショットなど
または、ハードウェアとソフトウェアのスタックが堅牢で適切に構成されていることを確認し、適切なバックアップを保持し、ログを監視します。サーバーを稼働させる前にスタック全体を適切にテストすること、および物理(ストリーミング/ PITR)と論理(ダンプ)の両方を適切にバックアップすることに代わるものはありません。信頼できるI / Oサブシステムが実際にあることを確認するために、稼働する前に、読み込まれたデータベースでプラグプルテストを繰り返し実行します。複数の形式のバックアップを使用します。
pgFoundry にはpgCheckというプロジェクトがあります。ただし、開発ステータスは「アルファ」です。
最後の活動は2012年の初めだったようです。
ほとんどの人は、データベース全体のバキュームを組み合わせて使用するか、各テーブルからselect *を実行します。すなわち。どういうわけかすべての行をスキャン/処理してみてください