レプリカクラスター ================== レプリカクラスターは、独立したCloudNativePG ``Cluster`` リソースであり、別のPostgresインスタンスからレプリカにあるという主な特徴があります、理想的には同じくCloudNativePGによって管理されます。通常、レプリカクラスターは、別のリージョンの別のKubernetesクラスターにあります。レプリカクラスターはカスケードすることもでき、以下で説明するように、ソースからのデータのレプリケーションをオブジェクトストアにのみ依存できます。 次の図は、この機能の詳細を含む\ `“Architecture” section `__\ から取得したもので、レプリカクラスターを使用して実装できるアーキテクチャの例を示しています。 .. figure:: /images/multi-cluster.png :width: 70% :alt: An example of multi-cluster deployment with a primary and a replica cluster An example of multi-cluster deployment with a primary and a replica cluster 基本的な概念 ------------ CloudNativePGは、 PostgreSQLクラスターが既存のソースソースから作成され、 :ref:`レプリカクラスター <レプリカクラスター>` 機能を介して同期が維持される場合でも、 PostgreSQLレプリケーションフレームワークの基礎に依存します。ソースは、プライマリクラスターまたは別のレプリカクラスターカスケードレプリカクラスターです。 最初のステップは、レプリカクラスターをブートストラップし、使用可能な方法のいずれかを選択することです。 - ストリーミングレプリケーション\ ``pg_basebackup`` 経由 - ボリュームスナップショットからのリカバリー - オブジェクトストアのBarman Cloudバックアップからのリカバリー :ref:`Bootstrap ` を参照してください。 ``pg_basebackup`` ストリーミングまたは\ ``recovery`` ボリュームスナップショットまたはオブジェクトストアを使用してPostgreSQLサーバーのクローンを作成する方法については、 レプリカクラスターのベースバックアップが利用できるようになったら、PostgreSQLの継続的リカバリーを介してオリジンから変更をレプリケートする方法を定義する必要があります。 2つのオプションがあります。 - レプリカクラスターとソース間でストリーミングレプリケーションを使用しますこれには、2つのクラスター間のネットワーク接続が正しく設定されていることを確認するために、いくつかの管理およびセキュリティ関連の作業を行う必要があります。 - WALアーカイブオブジェクトストア上を使用して、ソースからオブジェクトストアに定期的にシップされ、レプリカクラスタの\ ``barman-cloud-wal-restore`` によってプルされるWALファイルを取得します - 2つのいずれか あなたがしなければならないのは、実際に外部クラスターを定義することだけです。 外部クラスターに\ ``barmanObjectStore`` セクションが含まれる場合 - WALアーカイブを使用できるようになり、CloudNativePGは指定されたプライマリインスタンスに\ ``restore_command`` を自動的に設定します - ボリュームスナップショットを利用できない場合、 ``recovery`` セクションを使用してオブジェクトストアからレプリカクラスターをブートストラップできます。 外部クラスターに\ ``connectionParameters`` セクションが含まれる場合 - ``pg_basebackup`` セクションを使用して、ストリーミングレプリケーションを介してレプリカクラスターをブートストラップできるようになります - CloudNativePGは、指定されたプライマリインスタンスで\ ``primary_conninfo`` オプションを自動的に設定するため、WALレシーバープロセスが開始され、ソースクラスターに接続してデータを受信します 作成されたレプリカクラスターは、指定されたプライマリから予約されたオブジェクトストアでバックアップを実行でき、分散方法での対称アーキテクチャが有効になります。 以下を選択することにより、PostgreSQLデータベースのお気に入りの分散アーキテクチャを決定する完全な柔軟性と自由があります。 - 異なるデータセンターにある複数のKubernetesクラスターにまたがるプライベートクラウド - さまざまなリージョンの複数のKubernetesクラスターにまたがるパブリッククラウド - 前の2つの混合ハイブリッド - さまざまなリージョンおよびさまざまなクラウドサービスプロバイダーにある複数のKubernetesクラスターにまたがるパブリッククラウド レプリカクラスターのセットアップ -------------------------------- ソースクラスターからレプリカクラスターをセットアップするには、クラスターYAMLファイルを作成し、それに応じて次の部分を定義する必要があります。 - レプリカクラスターに\ ``externalClusters`` セクションを定義します - レプリカクラスターのブートストラップ部分を定義します。 ``pg_basebackup`` セクションを使用してストリーミングを介してブートストラップするか、 ``recovery`` セクションを使用してボリュームスナップショットまたはオブジェクトストアからブートストラップできます。 - レプリカクラスターに継続的リカバリ部\ ``spec.replica`` を定義します。行う必要があるのは、オプション\ ``spec.replica.enabled`` でレプリカモードを有効にし、オプション\ ``spec.replica.source`` で\ ``externalClusters`` 名前を設定することだけです pg_basebackupを使用した例 ^^^^^^^^^^^^^^^^^^^^^^^^^ この **最初の例** は、ブートストラップと継続的リカバリーの両方でストリーミングレプリケーションを使用してレプリカクラスターを定義します。レプリカクラスターは、TLS認証を使用してソースクラスターに接続します。 :ref:`sample YAML <例>` ``samples/`` サブディレクトリ。 ソースクラスターを指している\ ``bootstrap`` および\ ``replica`` セクションに注意してください。 .. code:: yaml bootstrap: pg_basebackup: source: cluster-example replica: enabled: true source: cluster-example ``externalClusters`` セクションでは、 ``connectionParameters`` サブセクションのホストに対応した適切な名前空間を使用することに注意してください。レプリカクラスターが別の名前空間にある場合、 ``-replication`` および\ ``-ca`` シークレットは、必要に応じてコピーしておく必要があります。 .. code:: yaml externalClusters: - name: connectionParameters: host: -rw..svc user: streaming_replica sslmode: verify-full dbname: postgres sslKey: name: -replication key: tls.key sslCert: name: -replication key: tls.crt sslRootCert: name: -ca key: ca.crt オブジェクトストアからのバックアップを使用した例 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ **2番目の例** は、 ``recovery`` セクションと継続的リカバリーを使用してオブジェクトストアからブートストラップするレプリカクラスターを定義します。ストリーミングレプリケーションと特定のオブジェクトストアの両方を使用します。ストリーミングレプリケーションの場合、レプリカクラスターは基本認証を使用してソースクラスターに接続します。 :ref:`sample YAML <バックアップ>` ``samples/`` サブディレクトリにあります。 ソースクラスターを指している\ ``bootstrap`` および\ ``replica`` セクションに注意してください。 .. code:: yaml bootstrap: recovery: source: cluster-example replica: enabled: true source: cluster-example ``externalClusters`` セクションでは、 ``endpointURL`` および\ ``connectionParameters.host`` で適切な名前空間を使用するように注意してください。また、必要に応じて必要なシークレットがコピーされていること、およびソースクラスターのバックアップが既に作成されていることを確認してください。 .. code:: yaml externalClusters: - name: barmanObjectStore: destinationPath: s3://backups/ endpointURL: http://minio:9000 s3Credentials: … connectionParameters: host: -rw.default.svc user: postgres dbname: postgres password: name: -superuser key: password .. Note:: ソースクラスターとレプリカクラスター間でストリーミングレプリケーションを使用するには、2つのクラスター間のネットワーク接続があることを確認し、パスワードまたは証明書を保持する必要なシークレットがすべて事前に適切に作成されていることを確認する必要があります。 ボリュームスナップショットを使用した例 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ボリュームスナップショットを使用し、ストレージクラスがスナップショットクラスター間の可用性を提供する場合、それを活用して、ソースクラスターのボリュームスナップショットを介してレプリカクラスターをブートストラップできます。 **3番目の例** は、 ``recovery`` セクションを使用してボリュームスナップショットからブートストラップするレプリカクラスターを定義します。ストリーミングレプリケーション基本認証を介して、オブジェクトストアを使用してWALファイルを取得します。 :ref:`sample YAML <例>` ``samples/`` サブディレクトリにあります。 レプリカクラスターでの指定されたプライマリの昇格 ------------------------------------------------ **指定されたプライマリ** を **プライマリ** に昇格させるには、オプション ``spec.replica.enabled`` を介してレプリカクラスターでレプリカモードを無効にするだけです .. code:: yaml replica: enabled: false source: cluster-example レプリカモードが無効になると、レプリカクラスターとソースクラスターは2つの別のクラスターになり、レプリカクラスターの **指定されたプライマリ** は、そのクラスターの **プライマリ** に昇格します。 cnpgプラグインを使用して、以前にレプリカであったクラスターのステータスを確認して、ロールの変更を確認できます。 .. code:: shell kubectl cnpg -n status cluster-replica-example .. Note:: レプリケーションの無効化は**不可逆**オペレーションです。レプリケーションが無効になり、**指定されたプライマリ**が**プライマリ**に昇格すると、レプリカクラスターとソースクラスターは決定的に2つの独立したクラスターになります。