レプリカクラスター¶

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

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

基本概念¶

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

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

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

実際に外部クラスターを定義するだけです。 pg_basebackup （ストリーミング）またはrecovery （オブジェクトストア）を使用してPostgreSQLサーバーのクローンを作成する方法については、

Bootstrap構成を参照してください。

外部クラスターに 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認証を使用してソースクラスターに接続します。

samples/ サブディレクトリの sample YAML を確認できます。

ソースクラスターを指している 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 セクションを使用してオブジェクトストアからブートストラップし、ストリーミングレプリケーションと指定されたオブジェクトストアの両方を使用して継続的リカバリーを定義します。ストリーミングレプリケーションの場合、レプリカクラスターは基本認証を使用してソースクラスターに接続します。

samples/ サブディレクトリで sample YAML を確認できます。

ソースクラスターを指している 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つの独立したクラスターになります。

レプリカクラスター¶

基本概念¶

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

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

前のトピックへ

次のトピックへ

目次