Configuring streaming replication ================================= レプリケーションシナリオの構成は複雑になる場合があります。構成オプションの詳細については、 `PostgreSQL core documentation `_ を参照してください。 ``.pgpass`` ファイルを使用して、レプリケーションユーザーのmd5認証を有効にすることができます。これは、ご使用の環境にとって最も安全な認証方法でない場合があります。サポートされている認証オプションの詳細については、 `PostgreSQL core documentation `_ を参照してください。 .. Note:: フェールオーバーマネージャーは、スタンバイプロモーションに`pg_ctl` ユーティリティを使用します。スタンバイサーバーのプロモーションのために`trigger_file` または`promote_trigger_file` パラメーターを設定する必要はありません。 カスケードレプリケーションの限定的なサポート -------------------------------------------- フェールオーバーマネージャーは、カスケードレプリケーションシナリオでの単純なフェールオーバーの限定的なサポートを提供します。カスケードレプリケーションにより、スタンバイノードは別のスタンバイノードにストリーミングできるため、プライマリノードへの接続数および処理オーバーヘッドが削減されます。 .. figure:: /images/cascading_replication.png :width: 40% :alt: Cascading replication. Cascading replication. カスケードレプリケーションの構成の詳細については、 `PostgreSQL documentation `_ を参照してください。 カスケードレプリケーションシナリオでフェールオーバーマネージャーを使用するには、クラスタープロパティファイルを変更し、スタンバイノード2で次のプロパティ値を設定します。 .. code:: ini promotable=false auto.reconfigure=false フェールオーバーが発生すると、スタンバイノード1がプライマリノードの役割に昇格します。スタンバイノード2は、3つのノードを含むようにレプリケーションシナリオを手動で再構成するアクションを実行するまで、新しいプライマリノードの読み取り専用レプリカとして機能し続けます。 スタンバイノード1に障害が発生した場合、フェールオーバー保護はありませんが、ノードの障害を通知する電子メールが届きます。 .. Note:: 物理レプリケーションスロットを使用する場合、状況はより複雑です。上の図のスタンバイノード2が物理レプリケーションスロットを使用しており、スタンバイノード1がプライマリに昇格すると、新しいプライマリエージェント構成されている場合、レプリケーションスロットをクラスター内の他のプロモートブルデータベースノードにコピーします。その後、スタンバイが昇格した場合、スタンバイノード2で設定されたスロット名を昇格させず、他のスタンバイエージェントにスロットを進めるように信号を送りません。スタンバイノード1を昇格させないように注意するか、他のスタンバイを提供し、1番をプロモーション不可としてマークするか、Postgresql `max_slot_wal_keep_size` 設定を使用して保持されるwalの量を制限する手順を実行するか、非アクティブなノードを手動でドロップする必要があります他のデータベースノードのスロット。このスロットの削除は、 :ref:`script.post.promotion ` および :ref:`script.remote.post.promotion ` プロパティを使用して実行できます。物理レプリケーションスロットとフェールオーバーマネージャーでは、カスケードレプリケーションの使用を避けることをお勧めします。