ストリーミングレプリケーションの設定

レプリケーションシナリオの構成は複雑になる可能性があります。構成オプションの詳細については、次の場所にあるPostgreSQLコアのドキュメントを参照してください。

https://www.postgresql.org/docs/12/static/warm-standby.html#streaming-replication

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

https://www.postgresql.org/docs/12/static/client-authentication.html

注釈

バージョン3.10以降、EFMはスタンバイプロモーションに pg_ctl ユーティリティを使用します。スタンバイサーバーの昇格のために trigger_file または promote_trigger_file パラメータを設定する必要はありません。

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

|variable_prod_name|カスケードレプリケーションの完全なサポートは提供していません。カスケードレプリケーションシナリオでの単純なフェイルオーバーのサポートは限定的です。カスケードレプリケーションにより、スタンバイノードが別のスタンバイノードにストリーミングできるようになり、マスターノードへの接続数（および処理オーバーヘッド）が減少します。

カスケードレプリケーション。

カスケード型レプリケーションの構成の詳細については、次の場所にあるPostgreSQLのドキュメントを参照してください。

https://www.postgresql.org/docs/12/static/warm-standby.html#cascading-replication

|variable_prod_name|を使用するにはカスケード型レプリケーションのシナリオでは、クラスタプロパティファイルを変更して、スタンバイノード＃2で次のプロパティ値を設定する必要があります。

promotable=false
auto.reconfigure=false

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

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

スイッチオーバーを実行して元のマスターに戻すと、カスケード複製シナリオが保持されない場合があることに注意してください。