ホットスタンバイサーバーでpg_dumpを実行していますか？

免責事項：私は確かにこれをまだ試していませんが、それが正しく動作していなかったかどうかわからないので、尋ねたいと思いました。

pg_dumpallプライマリに負荷をかけないように、ストリーミングレプリケーションを実行しているホットスタンバイサーバーから（経由で）夜間バックアップジョブを実行したいと思います。ここやここなどで人々が遭遇したいくつかの落とし穴について言及しているだけですが、ガイダンスはほとんどありません。バックアップが一貫している限り（それがあるはずです）、バックアップがプライマリよりわずかに遅れていても問題ありません。

私の質問は：

1. 本当にこれを実行したいのですか、またはプライマリサーバーでバックアップを実行する必要がありますか？どうして？

2. スタンバイでダンプを行うとき、どの設定が必要ですか、それを正しく行うために手順を使用する必要がありますか？たとえば、バックアップ中はレプリケーションを停止する必要がありますか？

よく知らpg_dumpれているように、ホットスタンバイで実行することは、スタンバイが役立つ主要な機能の1つです。それは完全に安全ですが、完全に信頼できるわけではありません-スタンバイがトランザクションをマスターから大幅に遅らせたときにトランザクションが中断すると、ダンプが失敗する可能性があります。

あなたが本当に見る必要がある唯一のことは、スタンバイが最新であり続けていることを確認することです。スタンバイがマスターへの接続を失い、あまりにも遅れた場合、3週間の古いスタンバイを陽気にバックアップしたくありません。

バックアップ中は、スタンバイがマスターからかなり遅れることを許可する必要があります。そうしないと、pg_dumpWALの再生を続けるためにトランザクションをキャンセルする必要があります。参照してくださいホットスタンバイ上の文書、特に「クエリの競合を処理」セクション、およびmax_standby_archive_delayおよびmax_standby_streaming_delayパラメータを。

マスターは、スレーブが再び追いつくのに十分なWALアーカイブを保持する必要があることに注意してください。

1. スタンバイでバックアップを行いますが、まったく問題ありません。
2. スタンバイシステムのバックアップ中にキャンセルされたステートメントの競合を回避するには、を使用してスタンバイでレプリケーションを一時停止しSELECT pg_xlog_replay_pause();、バックアップが実行さSELECT pg_xlog_replay_resume();れたら、実行を完了してレプリケーションを再開する必要があります。上記のコマンドを実行すると、スレーブのリカバリラグが発生することに注意してください。これは、データベースのサイズによっては非常に大きい場合があります。また、一時停止中にスレーブでリプレイされないため、WALセグメントが占めるスペースを考慮してください。

ドキュメントには他の便利な管理機能があります。たとえば、一時停止する前に、サーバーが実際に回復中であるかどうかを確認しますSELECT pg_is_in_recovery()。

バックアップ中にレプリケーションを一時停止した場合（これは整合性と一貫性を維持するための良いアイデアです）、マスターpostgresqlのいくつかの行を編集できます。

バックアップを習慣的に遅らせている時間。マスターノードがレプリケーションを再開するために必要なx_logファイル全体を保持していることを確認してください。あなたはpostgresql.conf編集でそれを行うことができます

wal_keep_segments = 32      # in logfile segments, 16MB each; 0 disables

これを変更せず、バックアッププロセスが長すぎる場合、おそらくマスターノードがスレーブに送信する前にxlogファイルを消去している可能性があります。