Replication¶

物理的レプリケーションはPostgreSQLの強みの1つであり、世界最大の組織のいくつかがビジネス継続高可用性コンテキストでデータの管理にそれを選択した理由の1つです。 -唯一のワークロードとプライマリからの一部の作業のオフロード。

アプリケーションレベルのレプリケーション¶

PostgreSQLのレプリケーション機能に長年にわたって貢献してきたので、ネイティブの物理的レプリケーションテクノロジーの上にCloudNativePGで高可用性を構築し、Kubernetes APIに直接統合することにしました。

Kubernetesの用語では、これは アプリケーションレベルのレプリケーション と呼ばれ、ストレージレベルのレプリケーションとは対照的です。

非常に成熟した技術¶

PostgreSQLには、プライマリインスタンスから1つ以上のレプリカにデータをレプリケートするための、非常に堅牢で成熟したネイティブフレームワークがあり、WAL（Write Ahead Log）に継続的に格納されるトランザクションの変更の概念に基づいて構築されています。

クラッシュリカバリとポイントインタイムリカバリテクノロジーの進化として開始された物理的レプリケーションは、 PostgreSQL 8.2（2006）でプライマリからウォームスタンバイの連続リカバリへのWALシッピングを通じて初めて導入されました。

PostgreSQL 9.0（2010）は、WALストリーミングとホットスタンバイ*を介した読み取り専用レプリカでそれを強化し、9.1（2011）はトランザクションレベルでの同期レプリケーションを導入しました（RPO = 0クラスターの場合）。カスケードレプリケーションは、PostgreSQL 9.2（2012）でリリースされました。ロジカルレプリケーションの基礎はPostgreSQL 9.4に置かれましたが、バージョン10（2017）は、データをオリジンからデスティネーションにレプリケートするためのパブリッシャー/サブスクライバーパターンのネイティブサポートを導入しました。

PostgreSQLクラスター内でのレプリケーション¶

ストリーミングレプリケーションのサポート¶

現時点では、CloudNativePGは、 spec で提供される instances の数に基づいて、クラスター内の物理ストリーミングレプリカを宣言的方法でネイティブかつ透過的に管理します。

replicas = instances - 1 (where  instances > 0)

クラスターの初期化直後に、演算子は次のように streaming_replica というユーザーを作成します。

CREATE USER streaming_replica WITH REPLICATION;
   -- NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB NOBYPASSRLS

注釈

pg_rewind の要件により、 PostgreSQL 10では streaming_replica ユーザが SUPERUSER 特権で作成されます。

すぐに使用できるように、演算子は暗号化されたチャネルを介してクラスター内でストリーミングレプリケーションを自動的にセットアップし、 streaming_replica ユーザに対してTLSクライアント証明書認証を実施します- pg_hba.conf からの次の抜粋で強調されています：

#  Require client certificate authentication for the streaming_replica user
hostssl postgres streaming_replica all cert
hostssl replication streaming_replica all cert

継続的なバックアップ統合¶

クラスターで連続バックアップが構成されている場合、CloudNativePGはレプリカを透過的に構成して、連続リカバリに restore_command を利用します。その結果、 PostgreSQLは、ストリーミングレプリケーションを介したWALのプルが失敗するたびに、WALアーカイブをフォールバックオプションとして使用できます。

同期レプリケーション¶

演算子は、スタンバイおよびレプリカと呼ばれる2つの構成オプションを介した クォーラムベースの同期ストリーミングレプリケーション の構成をサポートします。クォーラムを決定するオーダーに使用可能なレプリカの数。

同期レプリケーションはデフォルトで無効になっています（ minSyncReplicas と maxSyncReplicas は定義されていません）。 minSyncReplicas と maxSyncReplicas の両方が設定されている場合、CloudNativePGはPostgreSQLの synchronous_standby_names オプションを次の値に自動的に更新します。

ANY q (pod1, pod2, ...)

どこで：

警告

自己修復機能を提供するために、演算子は、 minSyncReplicas が現在利用可能なレプリカの数よりも大きい場合、 minSyncReplicas を無視する権限を持っています。 readyReplicas が 0 の場合、同期レプリケーションは自動的に無効になります。

PostgreSQL documentation で述べたように、*メソッド ANY

は、クォーラムベースの同期レプリケーションを指定し、WALレコードがリスト内の少なくとも要求された数の同期的スタンバイにレプリケートされるまでトランザクションのコミットを待機させリスト*。

重要

演算子が同期レプリケーション設定の強制よりも自己修復を選択している場合でも、3 +インスタンスのクラスター、またはより一般的には maxSyncReplicas < (instances - 1) のクラスターでのみ同期レプリケーションを計画することをお勧めします。

外部PostgreSQLクラスターからのレプリケーション¶

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

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

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

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

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

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

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

ストリーミングレプリケーションを介してレプリカクラスターをブートストラップできるようになります pg_basebackup セクションを使用する
CloudNativePGは primary_conninfo を自動的に設定します指定されたプライマリインスタンスのオプション、WALレシーバソースクラスターに接続してデータを受信するプロセスが開始されます

作成されたレプリカクラスターは、指定されたプライマリから予約たオブジェクトストアでバックアップを実行でき、分散型の対称アーキテクチャを可能にします。

以下を選択することにより、 PostgreSQLデータベースのお気に入りの分散アーキテクチャを自由に決定できます。

異なるデータのマルチプルのKubernetesクラスターにまたがるプライベートクラウドセンター
異なるマルチプルのKubernetesクラスターにまたがるパブリッククラウド地域
前の2つの組み合わせ（ハイブリッド）
異なるマルチプルのKubernetesクラスターにまたがるパブリッククラウド地域および異なるクラウドサービスプロバイダー

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

ソースクラスタからレプリカクラスタをセットアップするには、クラスタyamlfileを作成し、それに応じて次の部分を定義する必要があります。

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

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

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

指定されたプライマリ を プライマリ にプロモートさせるには、option spec.replica.enabled を使用してレプリカクラスタのレプリカモードを無効にするだけです。

replica:
  enabled: false
  source: cluster-example

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

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

注釈

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