スレーブでのPostgresホットスタンバイおよび長時間実行クエリ
質問：スレーブ（スレーブの役割はレポートDBサーバーとして）にWAL更新を適用しながら、長時間実行されるクエリ（30秒以上）を実行できますか？ホットスタンバイモード？現在の動作方法は、以下のパラメータを設定して、実行時間の長いクエリを強制終了してWAL更新を適用できるようにするか、WAL更新を適用するクエリが実行されなくなるまで無期限に遅延させることです。両方持つことはできますか？長時間実行されるクエリとWAL更新が同時に適用されていますか？
ケースの実装：現在、ホットスタンバイモードを使用して、1つのマスターから1つのスレーブへの変更を同期しています。スレーブの役割は、クエリが常に同時に実行されているレポートデータベースサーバーとしての役割です（ミリ秒単位、秒単位、分単位）。スレーブでアクティブなクエリが実行されていないというギャップが生じることは非常にまれです。
ホットスタンバイで長いクエリを実行できるように、次の2つのパラメータを調整しました。
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/[email protected]
クエリの実行中にWAL更新がスレーブに適用されないようにするという概念を理解しています。ただし、MVCCを使用すると、スレーブでのアクティブなクエリ（長時間実行、30秒以上）は、WAL更新が適用されている間、1つのバージョン/スナップショットからの読み取りを実行できるため、後続のクエリはそのときにWAL更新を取得すると思いました。 WALトランザクションがコミットされます。 PostgreSQLで使用されているMVCCモデルをまだ完全に消化していません[ https://devcenter.heroku.com/articles/postgresql-concurrency] なので、これは私の仮定です-たとえWALの更新中にテーブルが削除/切り捨てられましたが、クエリを実行しているテーブルのバージョン/スナップショットを使用しているため、現在実行中のクエリは引き続き機能しますか？
概要：とにかく（サードパーティの拡張機能を使用しても）マスターからスレーブを同期し、マスターからの更新をスレーブに適用することができますか？実行時間のクエリをスタンバイ/スレーブで完了するまで実行し続けながら、すぐに実行しますか？ホットスタンバイでそれができない場合、この状況で何をお勧めしますか？私たちのシナリオは、クエリが絶えず同時に実行されてpostgresに到達し（ミリ秒単位、秒単位、分単位）、WAL更新が適用される時間がほとんどないというものです。 Bucardoを使用しましたが、このシナリオでは適切な選択ではありません。メインデータベース以外のビューや40以上の他のデータベースを含め、同期する必要がある200以上のテーブルがあるためです。
どんな助けでも大歓迎です。
ありがとうございました！
ギヨームの回答に感謝しますが、幸いなことに、PostgreSQL 9.1以降、PostgreSQLにはhot_standby_feedbackオプション（postgresql.confのスタンバイサーバーでこれを設定します）があり、長時間実行されるクエリを強制終了せず、WALの更新が可能になります。スタンバイサーバー。この回答の功績は、PostgreSQLメールリスト（Raja/Albe/Scott）の3人に与えられ、そのメーリングスレッドで私を助けてくれました。うまくいけば、これはstackoverflowでこの答えを探している誰かに役立つかもしれません。メールスレッドはここにあります：
http://www.postgresql.org/message-id/D274E3C1.1113E8%[email protected]
http://www.postgresql.org/docs/9.1/static/hot-standby.html
抜粋：
スタンバイクエリのキャンセルの数が許容できないことが判明した場合、修正の可能性があります。最初のオプションは、パラメータ
hot_standby_feedbackを設定することです。これにより、VACUUMが最近無効になった行を削除できなくなり、クリーンアップの競合が発生しなくなります。これを行うと、プライマリのデッド行のクリーンアップが遅れ、望ましくないテーブルの肥大化が発生する可能性があることに注意してください。ただし、クリーンアップの状況は、スタンバイクエリがプライマリサーバーで直接実行されている場合よりも悪くはなく、実行をスタンバイにオフロードするという利点があります。この場合、max_standby_archive_delayは大きく保つ必要があります。これは、遅延WALファイルに、目的のスタンバイクエリと競合するエントリがすでに含まれている可能性があるためです。
ソリューションの実装：
スタンバイサーバーでpostgresql.confを構成する必要があるものは次のとおりです。
max_standby_archive_delay = -1
max_standby_streaming_delay = -1
hot_standby_feedback = on
PostgreSQLは、ほとんどのクエリがテーブルをロックしないという意味で、非常に優れたデータベースエンジンです。内部的には、テーブルの行ごとに一種のリビジョンシステムがあります。つまり、他の読み取りトランザクション中にWALを書き込み続けることができます。
ログは遅延に対しても非常に耐性があり、大量のトラフィックがない限り、ある時点で常に追いつくでしょう。
Lockコマンドを使用しないように注意してください。そうすれば、問題はありません。