PostgreSQLストリーミングレプリケーションでのarchive_commandの使用

Question

ストリーミングレプリケーションを使用する場合、誰かがPostgreSQLのarchive_commandとrestore_commandの目的を説明できますか？

私はストリーミングレプリケーションセカンダリサーバで学んだように、部分的に塗りつぶされたWALファイルを読み込んで適用します。私はpg_xlogに私のウォールセグメントの場所を持っており、archive_commandを使ってこれを私のローカルアーカイブディレクトリsay/arclogsにコピーします。

したがって、セカンダリサーバが部分的に満たされたアーカイブログをネットワーク経由でpg_xlogから読み取る場合、/ arclogsに保存されているファイルの使用は何ですか？ また、ファイルが/ arclogsに送信されるのは、16MBになるときだけです。

私はPostgreSQLに新規登録しました&あなたの助けが控えられるでしょう。

Answer 1

マスターは通常、マスターのwal_keep_segments設定によって制御されるpg_xlogに限られたWALしか保持しません。レプリカの速度が遅すぎるか、または長すぎると切断された場合、マスターはそれらのトランザクションログを削除し、ディスク領域を使い果たすことなく実行を継続できるようにします。

レプリカには、WALの連続したギャップのないストリームが必要なため、マスターに追いつく方法がありません。

だからあなたがすることができます：

• は、フォールバックとしてWALアーカイブ（archive_commandとarchive_mode）を有効にし、そのマスターは、そのpg_xlogから必要なWALを削除した場合のレプリカがアーカイブからWALを再生するに切り替えることができます。レプリカはWALをそのrestore_commandで取得します。重要なのは、アーカイブされたWALはマスターと同じマシン上にある必要はなく、通常はそうではありません。

又は

• マスターにレプリカを接続するための物理的複製スロット（primary_slot_name in recovery.conf）を使用。スロットが使用されている場合、レプリカが切断されている場合でもレプリカに必要なWALをマスターが知っています。したがって、まだレプリカが必要とするWALは、pg_xlogから削除されません。しかし、欠点はレプリカが長すぎるとディスクが空いているためにマスターが失敗する原因となり、pg_xlogがいっぱいになることです。

または

• ドゥでもない、と彼らはあまりにも遠くの後ろに落ちた場合にレプリカが失敗することができます。この場合、新しいベースバックアップから再作成します。

ドキュメントには、これらすべてをまとめておくための概要が必要です。

WALアーカイブにはさらに利点があります。サーバのbase backupを作成してWALアーカイブを使用すると、マスターのpoint-in-time restoreを実行できます。これにより、誤ったテーブルドロップなどのデータからデータを復元できます。 PgBarmanは、これを助けるツールの1つです。