Configuring streaming replication

レプリケーションシナリオの構成は複雑になる場合があります。構成オプションの詳細については、 PostgreSQL core documentation を参照してください。

.pgpass ファイルを使用して、レプリケーションユーザーのmd5認証を有効にすることができます。これは、ご使用の環境にとって最も安全な認証方法でない場合があります。サポートされている認証オプションの詳細については、 PostgreSQL core documentation を参照してください。

注釈

フェールオーバーマネージャーは、スタンバイプロモーションに`pg_ctl` ユーティリティを使用します。スタンバイサーバーのプロモーションのために`trigger_file` または`promote_trigger_file` パラメーターを設定する必要はありません。

カスケードレプリケーションの限定的なサポート

フェールオーバーマネージャーは、カスケードレプリケーションシナリオでの単純なフェールオーバーの限定的なサポートを提供します。カスケードレプリケーションにより、スタンバイノードは別のスタンバイノードにストリーミングできるため、プライマリノードへの接続数および処理オーバーヘッドが削減されます。

Cascading replication.

カスケードレプリケーションの構成の詳細については、 PostgreSQL documentation を参照してください。

カスケードレプリケーションシナリオでフェールオーバーマネージャーを使用するには、クラスタープロパティファイルを変更し、スタンバイノード2で次のプロパティ値を設定します。

promotable=false
auto.reconfigure=false

フェールオーバーが発生すると、スタンバイノード1がプライマリノードの役割に昇格します。スタンバイノード2は、3つのノードを含むようにレプリケーションシナリオを手動で再構成するアクションを実行するまで、新しいプライマリノードの読み取り専用レプリカとして機能し続けます。

スタンバイノード1に障害が発生した場合、フェールオーバー保護はありませんが、ノードの障害を通知する電子メールが届きます。

注釈

物理レプリケーションスロットを使用する場合、状況はより複雑です。上の図のスタンバイノード2が物理レプリケーションスロットを使用しており、スタンバイノード1がプライマリに昇格すると、新しいプライマリエージェント構成されている場合、レプリケーションスロットをクラスター内の他のプロモートブルデータベースノードにコピーします。その後、スタンバイが昇格した場合、スタンバイノード2で設定されたスロット名を昇格させず、他のスタンバイエージェントにスロットを進めるように信号を送りません。スタンバイノード1を昇格させないように注意するか、他のスタンバイを提供し、1番をプロモーション不可としてマークするか、Postgresql max_slot_wal_keep_size 設定を使用して保持されるwalの量を制限する手順を実行するか、非アクティブなノードを手動でドロップする必要があります他のデータベースノードのスロット。このスロットの削除は、 script.post.promotion および script.remote.post.promotion プロパティを使用して実行できます。物理レプリケーションスロットとフェールオーバーマネージャーでは、カスケードレプリケーションの使用を避けることをお勧めします。