レプリカ クラスタ

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

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

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 クラスターが既存のクラスター (ソース) から作成され、 レプリカ クラスタ 機能によって同期が維持されている場合でも、PostgreSQL レプリケーション フレームワークの基盤に依存しています。ソースは、プライマリ クラスターまたは別のレプリカ クラスター (カスケード レプリカ クラスター) にすることができます。

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

  • レプリカ クラスタとソース間でストリーミングレプリケーションを使用します (これには、2 つのクラスタ間のネットワーク接続が正しく設定されていることを確認するために、管理およびセキュリティ関連の作業を行う必要があります)。

  • ソースからオブジェクト ストアに定期的に送信され、レプリカ クラスタの barman-cloud-wal-restore によってプルされるベース バックアップと WAL ファイルのリカバリにBarman Cloud オブジェクト ストアを使用する

  • 2 つのいずれか

必要なのは、実際に外部クラスターを定義することだけです。 ブートストラップ を参照してください。

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