ホットスタンバイサーバーでpg_dumpを実行していますか？
免責事項：私は確かにこれをまだ試していませんが、正しく機能していないかどうかわからないので、質問しました。
プライマリに負荷がかからないように、ストリーミングレプリケーションを実行しているホットスタンバイサーバーから（pg_dumpallを介して）毎晩バックアップジョブを実行したいと思います。私は人々が遭遇したいくつかの落とし穴についての言及を見たことがあります。 here および here ですが、ガイダンスはほとんどありません。整合性が取れているかぎり、バックアップがプライマリよりもわずかに遅れていても問題ありません。
私の質問は：
本当にこれを実行しますか、それともバックアップをプライマリサーバーで実行する必要がありますか？どうして？
スタンバイでダンプを行う場合、それを正しく行うために必要な設定と手順を教えてください。例えばバックアップ中にレプリケーションを停止する必要がありますか？
AFAIK、ホットスタンバイでpg_dumpを実行することは、スタンバイが便利な主要な機能の1つです。完全に安全ですが、完全に信頼できるわけではありません。マスターからの遅れが大きすぎるときにスタンバイがトランザクションを中止すると、ダンプが失敗する可能性があります。
あなたが本当に見なければならない唯一のことは、スタンバイが最新であり続けていることを確認することです。スタンバイがマスターへの接続を失い、遅れが大きすぎる場合、3週間の古いスタンバイを楽にバックアップする必要はありません。
WALの再生を続けるにはpg_dumpトランザクションをキャンセルする必要があるため、バックアップ中にスタンバイがマスターからかなり遅れるようにする必要があります。 ホットスタンバイに関するドキュメント 、特に「クエリの競合の処理」セクション、および max_standby_archive_delay および max_standby_streaming_delay を参照してください。パラメーター。
マスターは、スレーブが再び追いつくことができるように十分なWALアーカイブを保持する用意がある必要があることに注意してください。
- スタンバイ時にバックアップを行いますが、問題はありません。
- スタンバイシステムでのバックアップ中にキャンセルされたステートメントの競合を回避するには、
SELECT pg_xlog_replay_pause();を使用してスタンバイでレプリケーションを一時停止し、バックアップを実行する必要があります。完了したら、SELECT pg_xlog_replay_resume();を実行してレプリケーションを再開します。上記のコマンドを実行すると、スレーブでリカバリラグが発生することに注意してください。これは、データベースのサイズによっては非常に大きくなる場合があります。また、一時停止中にスレーブで再生されないため、WALセグメントが占めるスペースも考慮に入れてください。
documentation には、その他の便利な管理機能があります。たとえば、一時停止する前に、サーバーが実際に回復中であるかどうかを確認します：SELECT pg_is_in_recovery()。
バックアップ中にレプリケーションを一時停止する場合（これは整合性と一貫性を維持するための良いアイデアです）、マスターpostgresqlのいくつかの行を編集できます：
バックアップが習慣的に遅れている時間。レプリケーションを再開するために必要なx_logファイル全体をマスターノードが保持していることを確認してください。あなたはpostgresql.conf編集でそれを行うことができます
wal_keep_segments = 32 # in logfile segments, 16MB each; 0 disables
これを変更せず、バックアッププロセスが長すぎる場合は、マスターノードがスレーブに送信する前にxlogファイルを消去している可能性があります。