アーキテクチャ

A typical EFM and PgPool configuration

典型的なEFMおよびPgPool構成

サンプルアーキテクチャ図には、次の表に示す4つのノードが示されています。

シナリオ

コンポーネント

サーバー1

AdvancedServerおよびFailoverManagerとPostgresStreamingReplicationを実行するマスターノード。アプリケーション/クライアントは、サーバー4のPgpoolポート経由で（または、使用されている場合は仮想IP経由で）接続して、書き込み操作（つまり、INSERT、UPDATE、DELETE）を実行します。

サーバー2とサーバー3

フェールオーバーマネージャーを実行するスタンバイノード（Pgpool-IIはオプション）。これはストリーミングレプリケーションのスタンバイノードです。アプリケーション/クライアントは、サーバー4のPgpoolポート（または、使用されている場合は仮想IP）を介してこのデータベースに接続し、読み取り操作（つまり、SELECT）を実行します。必要に応じて、オプションのスタンバイPgpoolインスタンスをここで設定し、watchdogを実行できます。

サーバー4

Pgpool-IIおよびFailoverManagerを実行するオプションの監視ノード。このサーバーは、アクティブなデータベースを使用せずに、フェイルオーバーマネージャーとPgpoolを使用してセットアップされています。すべてのアプリケーション/クライアントは、このサーバーを介して、このサーバーのIPアドレスを介して、またはこのサーバーを指す仮想IPを介して、他のデータベースに接続します。他に3つ以上のEFMノードが存在する場合、監視ノードは不要であることに注意してください。このサンプルアーキテクチャの監視ノードは、デモ用に提供されています。

このアーキテクチャ:

  • マスターノードに障害が発生した場合に2つのスタンバイを提供することにより、最大の可用性を実現します。

  • ロードバランシング用に複数のスタンバイを使用して読み取りスケーラビリティを向上させることにより、読み取り集中型の混合ワークロードで最大のパフォーマンスを実現します。

  • マスターでPgpoolを実行せずにロードバランシングを実行することにより、マスターノードの負荷を軽減します。

  • watchdog を使用して高可用性モードでPgpoolを構成することにより、Pgpoolの単一障害点を回避します。

  • 最も負担の少ないノード（監視ノード）でPgpoolマスター/アクティブインスタンスを実行して、フェイルオーバーマネージャーとリソースを共有しながら（TCOを削減するために）パフォーマンスを向上させます。

1つ以上のスタンバイが同期レプリケーションで構成されている場合、ユーザーは障害イベントでデータ損失をほぼゼロにすることができます。

このアーキテクチャでは、次の動作が期待できます。

シナリオ

HAへの影響

読み取りスケーラビリティへの影響

スイッチオーバー/スイッチバック: これは、一部のOS/DBレベルのアクティビティのために計画されたダウンタイムであり、ダウンタイム中に使用可能なスタンバイをマスターとしてプロモートするときに行われます。

**HAへの影響なし**（役割の変更中の数秒間の妨害を除く）。EFM/PgPoolクラスター内のノードの数はそのままです。切り替えは、EFMによって（EFMコマンドを介して）行われます。使用可能なスタンバイの1つが、ダウンタイム中に新しいマスターとして昇格されます。古いマスターは、手動セットアップなしのEFMによって新しいスタンバイとして再構成され、HAセットアップのノードの総数を維持します。

**読み取りスケーラビリティへの影響はありません**（役割変更中の数秒間の妨害を除く）。スイッチオーバー後も、クラスター内のスタンバイの総数は変わらないため、負荷分散/読み取りのスケーラビリティには影響しません。EFMによってスイッチオーバーが行われると、ポストプロモーションスクリプトが呼び出され、PgPoolが変更されて更新されます。したがって、PgPoolはすべてのクラスターノードの役割を変更します。

フェイルオーバー: これは予期しないダウンタイムであり、アプリケーションからマスターデータベースにアクセスできなくなります（プライマリDBダウン）。

HAへの影響はありません。ただし、このようなインシデント（フェールオーバー）では、EFM/PgPoolクラスターにスタンバイが1つだけ残ります。常に最大の可用性（1マスター、2スタンバイ）を維持するには、古い/ダウンしたマスターを（pg_basebackupまたはpg_rewindを介して）新しいスタンバイとして再構築し、EFMクラスターに接続する必要があります（または新しいマシンを次のように導入する必要があります）スタンバイ）。DBAによる手動介入が必要です。フェイルオーバーはEFMによって自動的に実行されます。

読み取りスケーラビリティが影響を受けます。フェイルオーバー後、古い/ダウンしたマスターが新しいスタンバイとして再構築され、EFMクラスターに接続されるまで、読み取りスケーラビリティー/負荷分散に使用できるスタンバイは1つだけです。ノードの総数（この場合は3つのノード）が復元されると、EFM接続スクリプトがノードをPgpoolクラスターに接続します。完了すると、両方のスタンバイがロードバランシングに使用できるようになります。