Postgresホットスタンバイおよびスレーブでの長時間実行クエリ

Question

質問：ホットスタンバイモードでスレーブ（スレーブロールはレポーティングDBサーバ）にWALアップデートが適用されている間に長時間実行されるクエリ（30秒以上） ？現在動作している方法は、長時間実行しているクエリを殺すように下のパラメータを設定するか、WALの更新を適用できるか、WALの更新を無期限に延期して適用するクエリが実行されなくなるまでです。私たちは両方を持つことができますか？長い実行クエリとWAL更新が同時に適用されていますか？

ケース実装：現在、ホットスタンバイモードを使用して、1つのマスターから1つのスレーブへの変更を同期します。スレーブの役割は、クエリが絶え間なく同時に実行されているレポートDBサーバーです（ms単位で、数秒単位で、数分で ）。スレーブでアクティブなクエリが実行されていないというギャップはほとんどありません。

max_standby_archive_delay = -1 # max delay before canceling queries 
max_standby_streaming_delay = -1 # max delay before canceling queries 

し、リストメーリングリストはpostgresで我々に似てアーカイブされたメールの質問を見て：

http://www.postgresql.org/message-id/AANLkTinLg+bpzcjzdndsnGGNFC=D1OsVh+hKb85A-s=n@mail.gmail.com

我々は、ホットスタンバイの長いクエリを許可するために、これらの2つのparamsを調整しています

クエリの実行中に スレーブにWAL更新が適用されないようにするという考え方を理解しています。しかし、MVCCを使用して、 WALアップデートが適用されている間に、スレーブ（長時間実行、30秒+）のアクティブクエリが の読み取り/書き込みを1つのバージョン/スナップショットから実行できると思ったので、 以降のクエリはWALそのWALトランザクションが がコミットされたときに更新されます。私はPostgreSQLで使用されているMVCCモデルを完全には消化していませんが、 [https://devcenter.heroku.com/articles/postgresql-concurrency]だから、これは です。テーブルが削除されても/WALの更新中に切り捨てられても、現在の実行中のクエリはそのまま動作するはずです。クエリしているテーブルのバージョン/スナップショット を使用していますか？

概要：とにかくあります（でも、サードパーティの拡張機能で）私たちはマスターからスレーブ を同期すると、任意の実行時間のせるクエリを継続しながら、マスターからこれらの更新がすぐに スレーブに適用することができスタンバイ/スレーブで完了するまで実行すると になりますか？ Hot Standbyでそれができない場合は、 この状況で何をお勧めしますか？我々のシナリオでは、WAL 更新が適用される時間はほとんどなくなり、クエリが常に同時に実行されている がポストグルに当たっている（ ミリ秒のうちのいくつかは秒単位で、数分単位で数えられます）。 Bucardoを使用しましたが、 のデータベース以外の40以上のデータベースも含めて、 のビューを含む200以上のテーブルが同期されているため、このシナリオでは の選択肢がありません。

ご協力いただければ幸いです。

ありがとうございました！

Answer 1

PostgreSQLはほとんどのクエリがテーブルをロックしないという点で、非常に優れたデータベースエンジンです。内部的には、テーブルの行ごとにリビジョンシステムの種類があります。つまり、他の読取りトランザクション中にWALを書き続けることができます。

ログはまた、遅延に非常に強く、大量のトラフィックがなければ、常にある時点で追いつきます。

ロックコマンドを使用していないことを確認しても問題ありません。

Answer 2

おかげでギヨームあなたの答えのために、幸いにも、PostgreSQLの9.1以降では、PostgreSQLは文句を言わない、長時間実行クエリを殺すとするWALの更新を可能にしますhot_standby_feedbackオプション（あなたはpostgresql.confの中にスタンバイサーバ上でこれを設定）を持っていますスタンバイサーバ。この回答のクレジットは、PostgreSQLのメールリスト（Raja/Albe/Scott）の3人に送られ、そのメールスレッドで私を助けました。うまくいけば、これはstackoverflowでこの答えを探している人に役立つ可能性があります。電子メールのスレッドはここで見つけることができます：

http://www.postgresql.org/message-id/D274E3C1.1113E8%awilliams@dresourcesgroup.com

http://www.postgresql.org/docs/9.1/static/hot-standby.html

抜粋：スタンバイ問合せキャンセルの数が受け入れられないことが判明した場合

救済の可能性が存在します。最初のオプションは、パラメータhot_standby_feedbackを設定することです。これにより、VACUUMは最近使用しなかった行を削除できないため、クリーンアップの競合は発生しません。これを行うと、プライマリ上の不本意な行のクリーンアップが遅れ、望ましくない表の膨らみが発生する可能性があることに注意してください。ただし、クリーンアップ状況は、スタンバイ・クエリがプライマリ・サーバー上で直接実行されていても、スタンバイ・サーバーへの実行負荷が軽減されている場合よりも悪くありません。遅延したWALファイルには、目的のスタンバイクエリと競合するエントリがすでに含まれている可能性があるため、この場合はmax_standby_archive_delayを大きく保つ必要があります。

ソリューションの実装：

はここにあなたのpostgresql.confがスタンバイサーバ上に設定する必要がありますものです：

max_standby_archive_delay = -1 
max_standby_streaming_delay = -1 
hot_standby_feedback = on