HAマルチデータセンター¶
複数のデータセンターにデプロイされたPostgreSQLクラスターの高可用性は、レプリケーションに基づいています。レプリケーションは、同期または非同期（ replication_modes ）の場合があります。
どちらの場合も、次の概念について明確にすることが重要です。
Postgresは、リーディングキーを所有し、リーディングキーを更新できる場合にのみ、プライマリまたはスタンバイリーダーとして実行できます。
奇数のetcd、ZooKeeper、またはConsulノードを実行する必要があります：3または5！
同期レプリケーション¶
ゾーンのドロップを自動的に許容できるマルチDCクラスターを持つには、少なくとも3つ必要です。
アーキテクチャ図は次のようになります。
etcd、ZooKeeper、またはConsulのクラスターを、異なるDCを介して、各ゾーンに1つずつ、少なくとも3つのノードでデプロイする必要があります。
postgresに関しては、異なるDCに少なくとも2つのノードを展開する必要があります。次に、グローバル synchronous_mode: true で synchronous_mode: true を設定する必要があります。
これにより、同期レプリケーションが有効になり、プライマリノードはノードの1つを同期として選択します。
非同期レプリケーション¶
データセンターが2つしかない場合、2つの独立したetcdクラスターを用意し、2番目のデータセンターでPatroni standby cluster を実行する方が良いでしょう。最初のサイトがダウンしている場合は、 standby_cluster 手動で昇格できます。
アーキテクチャ図は次のようになります。
DC2はDC1の状態を決して理解できないため、自動昇格はできません。
このシナリオでは、 pg_ctl promote を使用しないでください。 pg_ctl promote から standby_cluster セクションを削除して、正常なクラスターを「手動でプロモート」する必要があります。
警告
ソースクラスターがまだ稼働していて、スタンバイクラスターを昇格させる場合、スプリットブレインを作成します。
/"初期/"の状態に戻したい場合、解決するには2つの方法しかありません。
standby_clusterセクションを追加し直すとpg_rewindがトリガーされますが、pg_rewindが失敗する可能性があります。
スタンバイクラスターを最初から再構築します。
スタンバイクラスターを昇格する前に、ソースクラスターがダウンしていることを手動で確認する必要があります（STONITH）。DC1が回復したら、クラスターをスタンバイクラスターに変換する必要があります。
それを行う前に、データベースを手動で調べ、DC1とDC2間のネットワークが動作を停止してからDC1のクラスターを手動で停止するまでの間に発生したすべての変更を抽出できます。
抽出したら、これらの変更をDC2のクラスターに手動で適用することもできます。