web-dev-qa-db-ja.com

「postgresが120秒以上ブロックされました」-私のデータベースはまだ一貫していますか？

XenServerホストで実行されている複数の仮想マシンのOpen-Eストレージシステムでiscsiボリュームを使用しています。場合によっては、仮想マシン（したがってストレージシステム）のディスクI/O負荷が非常に高い場合、VMコンソールに次のエラーメッセージが表示されます。

[2594520.161701] INFO: task kjournald:117 blocked for more than 120 seconds.
[2594520.161787] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[2594520.162194] INFO: task flush-202:0:229 blocked for more than 120 seconds.
[2594520.162274] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[2594520.162801] INFO: task postgres:1567 blocked for more than 120 seconds.
[2594520.162882] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

このエラーメッセージは、カーネルがこれらのプロセスが120秒間実行されていないことを通知するために発生することを理解しています。おそらく、ストレージシステムへのディスクアクセスがまだ処理されていないためです。

しかし、プロセスへの影響は何ですか。たとえば、postgresプロセスは、ストレージシステムが数分後に再びアイドル状態になったときに最終的にデータを書き込み、すべてのデータの一貫性を維持しますか？または、書き込みを中止して、一部のテーブルを一貫性のない状態のままにしますか？

私は確かに前者が当てはまると思います-ディスクアクセスが遅い場合、postgres（または他の影響を受けるプロセス）はそれがかかる限り待つべきです。アプリケーションを数分間ぶら下げたまま生きることができます。しかし、データが破損する可能性がある場合、これらのエラーのいずれかは本当に悪いニュースです。

ここで何をすべきかアドバイスしてください。

linuxvirtualizationpostgresqlkernel
1
nn4l

DBが一貫性を保つというあなたの直感はず 120秒のハングの理由がディスク自体の障害である場合を除いて、正しいです。根本原因が実際に高いI/Oである場合、PostgreSQLは、データをディスクにコミットする順序によって、データが破損していないことを確認します。

以前、SATAディスクに障害が発生すると、I/O操作が完了するのを待ってハングし、このカーネルエラーが発生する傾向がありました。その時点では、おそらくそのディスク上のデータをあまり信頼できないでしょう。120秒のハングは、破損の根本的な原因ではなく、単なる副作用です。

2
natacado

トランザクションを使用している場合は、トランザクションの終了時にデータが確実に保持されるため、安全です（トランザクションはオールオアナッシング操作です）。トランザクションを使用していない場合、一部のデータが失われたり、部分的に更新されたりする可能性があります。 トランザクションの詳細

1
FINESEC

一貫性が心配な場合は、_diskchecker.pl_などのツールを使用して、ディスクがフラッシュを受け入れていることを確認することを検討してください。また、_pg_test_fsync_を使用して、非常に高速なパワーアンドクラッシュセーフライトバックキャッシュがあることがわかっていない限り、安全でない書き込みキャッシュを示す可能性のある疑わしいほど高いfsync（）レートが発生していないかどうかを確認できます。

書き込みの信頼性に関するPostgreSQLのドキュメントを参照 これらのツールおよびその他のオプションについては。

ストレージが信頼できるものでなければならないプロパティは次のとおりです。

  • 書き込みがfsync()、書き込みバリア、_O_SYNC_などでフラッシュされたら、停電、OSクラッシュ、ゲストVMまたはホストのクラッシュなど。

  • fsync()リクエストの順序を尊重する必要があるため、コミットA、B、およびCが書き込まれた順序で発生する場合、それらのデータもこの順序で耐久性のあるストレージにフラッシュされます。 CとBの書き込みをAの書き込みにブレンドしてパフォーマンスを向上させることにより、システムが最適化することは許可されていません。データが順不同で書き込まれ、WALの再生が信頼できない方法。

  • ブロックがfsync()でフラッシュされると、ストレージから取得できる必要があります。書き込み専用ストレージまたは指定した値とは異なる値を返すストレージはあまり良くありません。

ストレージにこれらの2つのプロパティがある場合、ストール、書き込みの並べ替え（バリア/同期を超えない限り）、キャッシュ書き込み（キャッシュフラッシュを尊重する限り）、等.

プラグプルテストに勝るものはありません。それはまさにそれが言っていることです。承認/展開前のテスト中に、システムに負荷がかかっているときにシステム全体の電源を切り、再起動して、DBがログを再生し、正常に回復することを確認します。繰り返す。

0
Craig Ringer