Deployment patterns#

PGDは、単一の高可用HAグループから世界的に分散されたマルチリージョンクラスターに至るまで、いくつかの展開パターンを提供します。選択したパターンにより、データが存在する場所、書き込みを受け入れる場所、およびクラスターが障害から復旧する方法が決まります。重要なディメンションは、アクティブな書き込み場所の数、必要なディザスターリカバリーのレベル、および規制要件がデータの保存場所を制限するかどうかです。各選択は、書き込みレイテンシー、競合処理、および操作の複雑さに影響を与えます。

パターンの選択#

ほとんどのPGD展開は、それぞれが1つ以上のパターンにマッピングする4つの目標のいずれかから開始します。

継続的な可用性の維持#

PGDは、ノード障害、データセンターDC障害、およびメジャーPostgresバージョンのアップグレードを含むローリングメンテナンス操作を通じてデータベースの利用可能な状態を維持します。 Single data group, global read scaling パターンは、単一のロケーション内で、2つ以上のノードにわたってHAを提供します。完全なセカンドアクティブサイトのコストなしでデータセンターレベルの保護を行う場合、 Primary active group, DR group パターンは、プライマリDCに障害が発生した場合に引き継ぐ容量の削減されたDRサイトを追加します。

複数のリージョンにまたがる書き込み#

複数の地域のユーザーにサービスを提供するアプリケーションは、それらのユーザーの近くに書き込み容量を配置すると利点があります。 Two data groups, active-active および Three data groups, active-active-active パターンは両方ともアクティブ/アクティブで実行されます。すべての場所が書き込みを受け入れ、相互にレプリケートします。 2つのデータグループパターンは、プライマリおよびセカンダリの場所に適しています。監視専用の3番目のロケーションは、完全な3番目のデータサイトなしでRaftマジョリティを達成し、3つの完全なデータグループは、残りのリージョンを中断せずにリージョン全体の障害を乗り切ることにより、Raftマジョリティをさらに取得します。

リージョン間のアクティブ-アクティブレプリケーションにより、書き込み競合が発生する可能性があります。 PGDは、構成可能な競合解決ポリシーを使用して競合を自動的に解決しますが、スキーマとアプリケーションの書き込みは、競合を念頭に置いて設計する必要があります。

データの局所性の適用#

GDPRやCCPAなどの規制では、個人データや機密データを特定の管轄区域内に留めることが必要です。 Multiple locations, data residency パターンは、データ分類ごとに選択的レプリケーションを実装します。個人識別情報PII、財務記録、医療データを含むローカル限定データは、リージョン内でのみ複製されます。製品カタログや構成などのグローバル参照データは、どこでも複製されます。各リージョンは、独自のHAグループで独立して実行されます。

読み取りのスケールアウト#

読み取りの多いワークロードは、分離されていない場合、書き込みクラスターを過負荷にする可能性があります。 Single data group, global read scaling パターンは、分析、レポート、およびAPI読み取りトラフィックをサブスクライバー専用ノードにオフロードします。サブスクライバー専用ノードは、書き込みグループからすべての変更を受信しますが、書き込みまたはコンセンサスに参加しないため、それらを追加しても書き込みパフォーマンスまたはコミットスコープのクォーラムに影響はありません。これらを追加リージョンに配置して、ローカルユーザーの読み取り遅延を削減できます。

アーキテクチャ要素#

PGDクラスター内の各ノードは、 PGD拡張機能を実行しているPostgresインスタンスです。ノードはグループに編成され、各グループは書き込みリーダーを選択して書き込みを調整します。接続マネージャーは各ノードで実行され、クライアント接続を現在の書き込みリーダーにルーティングし、アプリケーションの接続文字列を変更せずに自動フェイルオーバーを有効にします。

ノードタイプ#

PGDクラスターは、それぞれが異なるロールを担う3つのノードタイプを使用します。

  • データノード データを保存および管理し、読み取りおよび書き込みを処理し、レプリケーションとコンセンサスに参加します。

  • サブスクライバー専用ノード 書き込みグループからすべての変更を受信しますが、書き込みを受け入れず、コンセンサスに参加しません。これらは、分析やレポートなどの読み取り中心のワークロードに適しています。

  • Witnessノード Raftコンセンサスに参加しますが、ユーザデータは保存しません。 3番目の場所の監視は、2つのデータの場所が相互に接続を失った場合に、スプリットブレインシナリオを解決します。

ノードのロール#

データノードは、条件の変更に応じてノード間で自動的に転送される一時的なロールを引き受けます。

  • 書き込みリーダー アプリケーションが接続マネージャーを介して接続するときのすべての書き込み操作の現在のターゲット。書き込みリーダーに障害が発生すると、別のノードが数秒で選択されます。

  • Raftリーダー 書き込みリーダー選挙やスキーマ変更の調整を含む、グループ全体のコンセンサス決定を管理します。

コミットスコープ#

コミットスコープは、PGDが各トランザクションに提供する耐久性保証を制御します。デフォルトは、結果的一貫性を備えた非同期レプリケーションです。マジョリティプロテクトからクォーラムコミットまでのより強力なオプションは、書き込みレイテンシーの追加を犠牲にして同期調整を追加します。クォーラムコミットは、最も厳密な一貫性保証を提供し、ノードがローカルにコミットする前に、すべての参加ノードにわたってコミット決定を調整します。各パターンページには、そのトポロジに推奨されるコミットスコープが記載されています。完全なリファレンスについては、 コミットスコープへの移行 を参照してください。