レプリカクラスター

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

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

基本的な概念

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

最初のステップは、レプリカクラスターをブートストラップし、使用可能な方法のいずれかを選択することです。

ストリーミングレプリケーションpg_basebackup 経由
ボリュームスナップショットからのリカバリー
オブジェクトストアのBarman Cloudバックアップからのリカバリー

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

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つのクラスター間のネットワーク接続があることを確認し、パスワードまたは証明書を保持する必要なシークレットがすべて事前に適切に作成されていることを確認する必要があります。

ボリュームスナップショットを使用した例

ボリュームスナップショットを使用し、ストレージクラスがスナップショットクラスター間の可用性を提供する場合、それを活用して、ソースクラスターのボリュームスナップショットを介してレプリカクラスターをブートストラップできます。

3番目の例 は、 recovery セクションを使用してボリュームスナップショットからブートストラップするレプリカクラスターを定義します。ストリーミングレプリケーション基本認証を介して、オブジェクトストアを使用してWALファイルを取得します。

sample YAML

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

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

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

replica:
  enabled: false
  source: cluster-example

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

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

注釈

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