PostgreSQLストリーミングとファイルベースのレプリケーション（サーバーの動作と構成の観点から）

本番環境でトラブルシューティングできるように、PostgreSQLレプリケーションの最適な使用法とその仕組みを理解しようとしています。

これらの2種類のレプリケーションの違いを（1）構成（2）2つのサーバーのマスター/スレーブが各シナリオでどのように実行するかという点を理解するのに苦労しています

PostgreSQL（9.2以降）でのレプリケーションは、基本的にサイズが16MBのXLOGファイル（各ファイルを作成するための周波数設定に依存）がマスターで作成され、なんらかの方法でスレーブに送信されます。

私の設定（この質問の目的のため）

マスター
archive_command = 'rsync -av％p postgres @ [SlaveIP]：[wal_archive_folder] /％f' 上のPostgresql.confの設定

ログファイルを読み取るためのスレーブ上のRecovery.confの構成
restore_command = 'cp [wal_archive_folder] /％f \ "％p \"'
primary_conninfo = 'host = [MasterIP] port = 5432 user = postgres'

私の質問は、この構成のどの部分がこの「ストリーミング」レプリケーションと「ログシッピング」を作るのかということです。私のマスターは、rsyncを使用してスレーブにログを送信するように構成されています（これはログ配布ですか？）私のスレーブは、recovery.confでマスターに接続できるように構成されています（これはストリーミングですか？）

質問の後半：何が起こっているのですか？WAL_senderとWAL_receiverを介してPostgreSQLに別のプロトコルがあることを理解しています。しかし、これがストリーミングのみに使用されているかどうかは不明です。使用されている場合、マスターでrsyncはどのように使用されていますか？

：） ありがとうございました！！そして、これが明らかな質問であれば申し訳ありません。私はブログや本をたくさん読んでいますが、理解に苦労しています。Postgres wikiは非常に詳細なので、すべてを完了するには長い時間がかかります（そして私には期限があります）

「ストリーミングレプリケーション」とは、接続でwalsenderプロトコルを使用して、マスターとレプリカ間のTCP / IP接続を介してWALレコードを継続的に送信することを指しreplicationます。マスターは自身のWALを読み取り、pg_xlog必要に応じてレプリカに送信します。接続を許可するために、マスターのprimary_conninfoディレクティブrecovery.confとpg_hba.confエントリで構成されていますreplication。またwal_keep_segments、ドキュメントで説明されている他のいくつかのオプションも必要です。

「ログ配布」とは、ファイル転送プロトコルを介してWALアーカイブ全体としてWALレコードをアーカイブの場所に定期的に送信し、そこからレプリカがそれらをフェッチできることを意味します。これは、で構成されていますrestore_commandディレクティブ内recovery.confやarchive_commandマスターインチ PostgreSQLは、ファイルの場所や転送方法を気にしません。ファイルがそこに置かれ、必要なアーカイブarchive_commandがrestore_commandフェッチされるだけです。これにより、PgBarmanやWAL-Eなどのシステムを構築できます。

ストリーミングレプリケーションでは、レコードが生成されたときに送信されるため、ラグはそれほど大きくありません。ただし、マスターとレプリカの両方がオンラインであり、直接通信できる必要があります。また、マスターがレプリカに必要なWALのディスク上のコピーを保持できるようにレプリカが十分に対応できるようにする必要があり、通常pg_xlog、レプリカ用に余分なWALを保持するために余分なスペースを費やす必要があります。

アーカイブ全体が送信されるとレプリカはWALしか認識しないため、ログ配布レプリケーションのラグは長くなります。ただし、マスターとレプリカが共有の保存場所を使用してTCP / IP経由で直接通信できない場合でも機能します。マスターがWALをpg_xlogアーカイブした後にのみ破棄するため、レプリカがしばらくダウンしていても動作し続けます。そのため、WALはアーカイブ内にあり、マスターが送信できなくてもレプリカで使用できます。もうストリーミングで。archive_command決してあきらめないのでpg_xlog、アーカイブが失敗するといっぱいになる可能性があることに注意してください。そのため、信頼できる場所にアーカイブしてから、その場所からレプリカサーバーにフェッチすることをお勧めします。

一般に、実際には2つを組み合わせる、つまり両方を使用します。その場合、すべてが順調に進んでいるときにストリーミングレプリケーションが使用されます。レプリカが遅れすぎてマスターが必要なxlogを破棄した場合、接続の問題が発生した場合など、レプリカは追いつくまでアーカイブされたWALの読み取りに切り替わります。成功するまで定期的にストリーミングへの切り替えを再試行します。

ログシッピングを使用しない場合は、ログシッピングを使用します。ログシッピングフォールバックなしのストリーミングレプリケーションは（PostgreSQL 9.4まで）レプリケーションラグが発生しやすく、レプリカを強制的に再構築する必要があるためです。

PostgreSQL 9.4では、ストリーミングレプリケーションで「レプリケーションスロット」を使用できるようになったため、これが少し変更されています。これにより、マスターはレプリカが必要とするWALの量を追跡でき、レプリカがWALを再生するまでそれを破棄する必要がありません。したがってwal_keep_segments、レプリケーションスロット（デフォルトではない）を使用する場合、これ以上の必要はありません。

PostgreSQL 9.4のレプリケーションスロットのストリーミングに関する私の記事を参照してください。

9.4では、ストリーミング論理レプリケーションの基礎も導入されています。これは、Londiste、Slony-Iなどの論理レプリケーションシステム、および新しい双方向非同期マルチマスターレプリケーション機能で使用するために設計された、もう1つのメカニズムです。