レプリカクラスター¶

レプリカクラスターは独立したCloudNativePG Cluster リソースで、別のPostgresインスタンスのレプリカにあるという主な特徴を持ち、理想的にはCloudNativePGでも管理されます。通常、レプリカクラスターは別のリージョンの別のKubernetesクラスターにあります。レプリカクラスターもカスケードすることができ、以下で説明するように、ソースからのデータのレプリケーションをオブジェクトストアのみに依存できます。

以下の図-この機能に関する詳細情報を含む“Architecture” sectionから取得-は、レプリカクラスターで実装できるアーキテクチャの例を示しています。

基本概念¶

CloudNativePGは、PostgreSQLクラスターが既存のクラスター（ソース）から作成され、: レプリカクラスター機能を介して同期されている場合でも、PostgreSQLレプリケーションフレームワークの基盤に依存しています。ソースは、プライマリクラスターまたは別のレプリカクラスター（カスケードレプリカクラスター）にすることができます。

ブートストラップレベルと継続的リカバリレベルの両方で、レプリケーションに関して使用可能なオプションは次のとおりです。

レプリカクラスターとソース間のストリーミングレプリケーションを使用します（これには、2つのクラスター間のネットワーク接続が正しくセットアップされていることを確認するために、管理およびセキュリティ関連の作業が確かに必要になります）
ベースバックアップと、ソースからオブジェクトストアに定期的に出荷され、レプリカクラスター内のbarman-cloud-wal-restore によってプルされるWALファイルのリカバリにBarman Cloudオブジェクトストアを使用します
2つのいずれか

あなたがしなければならないのは、実際に外部クラスターを定義することだけです。: BootstrapConfiguration を参照してください

pg_basebackup （ストリーミング）またはrecovery （オブジェクトストア）のいずれかを使用してPostgreSQLサーバーのクローンを作成する方法について。

外部クラスターに barmanObjectStore セクションが含まれる場合：

recovery セクションを使用して、オブジェクトストアからレプリカクラスターをブートストラップできます
CloudNativePGは、指定されたプライマリインスタンスにrestore_command を自動的に設定します

外部クラスターに 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 名前を設定することです

この 最初の例 では、ブートストラップと継続的リカバリの両方でストリーミングレプリケーションを使用してレプリカクラスターを定義します。レプリカクラスターは、TLS認証を使用してソースクラスターに接続します。

sample YAML を確認できます

samples/ サブディレクトリ内。

ソースクラスターを指しているbootstrap およびreplica セクションに注意してください。

bootstrap:
  pg_basebackup:
    source: cluster-example

replica:
  enabled: true
  source: cluster-example

externalClusters セクションでは、 connectionParameters サブセクションのホストに正しい名前空間を使用することを忘れないでください。レプリカクラスターが別の名前空間にある場合、必要に応じて、 -replication および-ca シークレットをコピーする必要があります。

externalClusters:
- name: <MAIN-CLUSTER>
  connectionParameters:
    host: <MAIN-CLUSTER>-rw.<NAMESPACE>.svc
    user: streaming_replica
    sslmode: verify-full
    dbname: postgres
  sslKey:
    name: <MAIN-CLUSTER>-replication
    key: tls.key
  sslCert:
    name: <MAIN-CLUSTER>-replication
    key: tls.crt
  sslRootCert:
    name: <MAIN-CLUSTER>-ca
    key: ca.crt

2番目の例 では、 recovery セクションを使用してオブジェクトストアからブートストラップし、ストリーミングレプリケーションと指定されたオブジェクトストアの両方を使用して継続的リカバリーを定義するレプリカクラスターを定義します。ストリーミングレプリケーションの場合、レプリカクラスターは基本認証を使用してソースクラスターに接続します。

sample YAML を確認できます

samples/ サブディレクトリにあります。

ソースクラスターを指しているbootstrap およびreplica セクションに注意してください。

bootstrap:
  recovery:
    source: cluster-example

replica:
  enabled: true
  source: cluster-example

externalClusters セクションでは、 endpointURL およびconnectionParameters.host で正しい名前空間を使用するように注意してください。また、必要に応じて必要なシークレットがコピーされ、ソースクラスターのバックアップが既に作成されていることを確認してください。

externalClusters:
- name: <MAIN-CLUSTER>
  barmanObjectStore:
    destinationPath: s3://backups/
    endpointURL: http://minio:9000
    s3Credentials:
      …
  connectionParameters:
    host: <MAIN-CLUSTER>-rw.default.svc
    user: postgres
    dbname: postgres
  password:
    name: <MAIN-CLUSTER>-superuser
    key: password

注釈

ソースクラスターとレプリカクラスター間でストリーミングレプリケーションを使用するには、2つのクラスター間にネットワーク接続があること、およびパスワードまたは証明書を保持する必要なすべてのシークレットが事前に適切に作成されていることを確認する必要があります。

レプリカクラスター内の指定されたプライマリの昇格¶

指定されたプライマリ を プライマリ に昇格させるには、オプションspec.replica.enabled を使用してレプリカクラスターのレプリカモードを無効にするだけです

replica:
  enabled: false
  source: cluster-example

レプリカモードを無効にすると、レプリカクラスターとソースクラスターが2つの別々のクラスターになり、レプリカクラスターの 指定されたプライマリ がそのクラスターの プライマリ に昇格します。 cnpgプラグインを使用してロールの変更を確認し、以前はレプリカであったクラスターのステータスを確認できます。

kubectl cnpg -n <cluster-name-space> status cluster-replica-example

注釈

レプリケーションの無効化は**不可逆的な**操作です。レプリケーションを無効にして、**指定されたプライマリ**を**プライマリ**に昇格させると、レプリカクラスターとソースクラスターは決定的に2つの独立したクラスターになります。

レプリカクラスター¶

基本概念¶

レプリカクラスターのセットアップ¶

レプリカクラスター内の指定されたプライマリの昇格¶

前のトピックへ

次のトピックへ

目次