Architecture

高可用性とスケーラビリティの目標のために、 PostgreSQLデータベース管理システムは、管理者にビルトイン 物理的レプリケーション WriteAheadLog（WAL）シッピング に基づく機能を提供します。

PostgreSQLは、ネットワークの非同期および同期的ストリーミングレプリケーションと、非同期ファイルベースのログシッピング（通常、例、WALファイルをオブジェクトストアに格納するためのフォールバックオプションとして使用されます）をサポートしていスタンバイサーバ。 ホットスタンバイ機能のおかげで、読み取り専用のワークロードにも使用できます。

CloudNativePGは、非同期および同期ストリーミングレプリケーションに基づくクラスターをサポートし、同じKubernetesクラスター内のマルチプルのホットスタンバイレプリカを管理します。以下の仕様があります。

  • 1つのプライマリ、高可用性のためのオプショナルのマルチプルのホットスタンバイレプリカ *アプリケーションで利用可能なサービス：

  • -rw ：アプリケーションはクラスターの唯一のプライマリインスタンスに接続します

  • -ro ：アプリケーションは読み取り専用ワークロードの唯一のホットスタンバイレプリカに接続します

  • -r ：アプリケーションは、読み取り専用ワークロードのインスタンスのいずれかに接続します

  • PostgreSQLクラスターの復元力を高めるために、シェアードナッシングアーキテクチャを推奨：

  • PostgreSQLインスタンスは異なるKubernetesワーカーノードに存在する必要があります ネットワークのみを共有します

  • PostgreSQLインスタンスは別の場所に存在できます 同じ地域のアベイラビリティーゾーン

  • PostgreSQLクラスターのすべてのノードは同じリージョンに存在する必要があります

読み取り/書き込みワークロード

アプリケーションは、次の図に示すように、Kubernetes演算子によって* current プライマリ *として選択されたPostgreSQLインスタンスに接続することを決定できます。

Applications writing to the single primary

Applications writing to the single primary

アプリケーションは -rw サフィックスサービスを使用できます。

プライマリが一時的または永続的に利用できない場合、Kubernetesは、高可用性を目的として、 -rw サービスをクラスターの別のインスタンスに移動します。

読み取り専用のワークロード

重要

アプリケーションは、 Hot Standby が提示する制限を認識し、これらのワークロードを処理する際のPostgreSQLの動作方法に精通している必要があります。

アプリケーションは、演算子が使用可能にした -ro サービスを介してホットスタンバイレプリカにアクセスできます。このサービスにより、アプリケーションは、プライマリノードから読み取り専用クエリをオフロードできます。

次の図は、アーキテクチャを示しています。

Applications reading from hot standby replicas in round robin

Applications reading from hot standby replicas in round robin

アプリケーションは、 -r サービスを介して任意のPostgreSQLインスタンスにアクセスすることもできます。

マルチクラスター展開

分散PostgreSQLクラスターでは、常にプライマリとして機能する単一のPostgreSQLインスタンスのみが存在できます。これは、アプリケーションがいつでも単一のKubernetesクラスター内にしか書き込みできないことを意味します。

ちなみに

すべてのインスタンスが書き込みを受け入れるPostgreSQLアーキテクチャに興味がある場合は、 BDR (Bi-Directional Replication) by EDB をご覧ください。 Kubernetesの場合、 BDRには独自のオペレーターがあり、2022年後半に予定されています。

ただし、ビジネス継続性の目標では、次のことが基本です。

PostgreSQLバックアップデータを保存することにより、グローバル リカバリポイント目標 （RPO）を削減 マルチプルの場所、地域、場合によっては異なるプロバイダーを使用 （ ディザスターリカバリー ） PostgreSQLを活用して、グローバルな リカバリ時間目標 （RTO）を削減 プライマリKubernetesクラスターを超えるレプリケーション（ 高可用性 ）

上記の懸念に対処オーダーに、CloudNativePGは* PostgreSQL Replica Cluster *の概念を導入しています。レプリカクラスターは、プライベート、パブリック、ハイブリッド、およびマルチクラウドコンテキストでのマルチクラスター展開を可能にするCloudNativePGの方法です。

レプリカクラスターは、個別の Cluster リソースです。

1.定義済みの外部ソースクラスター2からの pg_basebackup またはフル recovery を bootstrap オプションとして持つ。 replica.enabled オプションをに設定します。通常、Kubernetesクラスターの外部にある replica.source で識別される定義済みの外部クラスターから複製します4。 （PostgreSQLの restore_command パラメータを使用して）リカバリオブジェクトストアから受信したWAL情報を再生する、（PostgreSQLの primary_conninfo パラメータを使用して）ストリーミングレプリケーションを介して、または2つのいずれか（外部クラスターで barmanObjectStore と connectionParameters の両方が定義されている場合）5。 PostgreSQLのホットスタンバイでサポートされている読み取り接続のみを受け入れる

参考

別のクラスター（ externalClusters セクションで定義）からPostgreSQLクラスターを複製する方法の詳細については、 BootstrapConfiguration を参照してください。

次の図は、2つの異なるKubernetesクラスターにまたがるPostgreSQLクラスターを示しています。プライマリクラスターは最初のKubernetesクラスターにあり、レプリカクラスターは2番目にあります。 2番目のKubernetesクラスターは、企業の災害リカバリクラスターとして機能し、災害および最初のクラスターが利用できなくなった場合にアクティブ化する準備ができています。

レプリカクラスターは、プライマリクラスターと同じアーキテクチャを持つことができます。プライマリインスタンスの代わりに、レプリカクラスターには、 指定プライマリ インスタンスがあります。これは、ストリーミングレプリケーション（対称アーキテクチャ）内の任意の数のカスケードスタンバイサーバを持つスタンバイサーバーです。

指定されたプライマリはいつでも昇格させることができ、レプリカclusteraプライマリクラスタが書き込み接続を受け入れることができるようにします。

警告

CloudNativePGは、現時点ではクラスター間のスイッチオーバーまたはフェイルオーバーを実行しません。このようなオペレーションは、手動で実行するか、マルチクラスター/統合クラスター対応の権限に委任する必要があります。 PostgreSQLクラスターはそれぞれ独立しています。

上記の例で指定されたプライマリは、WALストリーミング（ primary_conninfo ）を介して供給され、 restore_command および barman-cloud-wal-restore を介したファイルベースのWALシッピングのフォールバックオプションを備えています。

CloudNativePGでは、マルチプルのレプリカクラスターを定義できます。レプリカの数を減らしてレプリカクラスターを定義し、クラスターがプライマリに昇格したときにこの数を増やすこともできます。