Replication

物理的レプリケーションはPostgreSQLの強みの1つであり、世界最大の組織の一部がビジネス継続性のコンテキストでのデータの管理にそれを選択した理由の1つです。物理レプリケーションは、主に高可用性を実現するために使用されますが、読み取り専用ワークロードのスケールアウトと、プライマリから一部の作業をオフロードすることもできます。

注釈

このセクションは、同じKubernetesクラスターで管理される同じ`Cluster` リソース内のレプリケーションに関するものです。異なるKubernetesクラスター間でも、別のPostgres Cluster リソースを使用して複製する方法については、レプリカクラスターセクションを参照してください。

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

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

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

非常に成熟したテクノロジー

PostgreSQLには、プライマリインスタンスから1つ以上のレプリカにデータをレプリケートするための非常に堅牢で成熟したネイティブフレームワークがあり、WALライトアヘッドログに継続的に保存されるトランザクションの変更の概念を中心に構築されています。

クラッシュリカバリーとポイントインタイムリカバリーテクノロジーの進化として始まった物理的レプリケーションは、継続的リカバリーでのプライマリからウォームスタンバイへのWALシッピングを介してPostgreSQL 8.22006で最初に導入されました。

PostgreSQL 9.02010は、 ホットスタンバイ を介したWALストリーミングと読み取り専用レプリカを導入しました。 2011年、PostgreSQL 9.1はトランザクションレベルで同期レプリケーションをもたらし、 PgBouncerPoolMode =0クラスターをサポートしました。カスケードレプリケーションはPostgreSQL 9.22012で追加されました。ロジカルレプリケーションのパブリケーションの基礎はPostgreSQL 9.42014で確立され、バージョン102017では、オリジンから宛先にデータをレプリケートするためのパブリッシャー/サブスクライバーパターンのネイティブサポートを導入しました。以下の表は、これらのマイルストーンをまとめたものです。

Version	Year	Feature
8.2	2006	Warm Standby with WAL shipping
9.0	2010	Hot Standby and physical streaming replication
9.1	2011	Synchronous replication (priority-based)
9.2	2012	Cascading replication
9.4	2014	Foundations of logical replication
10	2017	Logical publisher/subscriber and quorum-based synchronous replication

この表は、主要なPostgreSQLレプリケーション機能とその各バージョンを強調表示しています。

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

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

replicas = instances - 1 (where  instances > 0)

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

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

すぐに使える、オペレーターは、暗号化されたチャネルを介してクラスター内のストリーミングレプリケーションを自動的に設定し、streaming_replica ユーザーのTLSクライアント証明書認証を適用します。pg_hba.conf からの次の抜粋で強調表示されています。

##  Require client certificate authentication for the streaming_replica user

hostssl postgres streaming_replica all cert map=cnpg_streaming_replica
hostssl replication streaming_replica all cert map=cnpg_streaming_replica

注釈

CloudNativePGが証明書を管理する方法の詳細については、 Certificates を参照してください。

ドキュメントで。

構成されている場合、オペレーターはHAクラスター内のすべてのレプリカのレプリケーションスロットを管理し、各スタンバイに必要なWALファイルが、フェールオーバーまたはスイッチオーバーの後でもプライマリのストレージに保持されるようにします。

注釈

CloudNativePGが高可用性レプリカのレプリケーションスロットを自動的に管理する方法の詳細については、高可用性のためのレプリケーションスロットを参照してください。

以下。

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

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

同期レプリケーション

CloudNativePGは、両方の quorum-based and priority-based synchronous replication for PostgreSQL をサポートしています。

警告

デフォルトでは、トランザクションのコミット中にWALレプリケーションに必要な数のスタンバイノードを使用できない場合、同期レプリケーションは書き込み操作を一時停止します。この動作はデータの耐久性を優先し、PostgreSQL DBAのベストプラクティスに沿っています。ただし、セットアップでの厳密なデータの耐久性よりも自己修復の方が優先される場合、この設定を調整できます。この動作の管理の詳細については、データの耐久性と同期レプリケーションを参照してください。

セクション。

注釈

*failover quorum* feature

同期レプリケーションと並行して使用して、フェールオーバーイベント中のデータの耐久性と安全性を向上させることができます。

synchronous_standby_names オプションの直接構成は許可されていません。ただし、CloudNativePGは、このオプションにローカルポッドの名前を自動的に入力しますが、カスタマイズでCluster リソースを超えて同期レプリケーションを拡張できます。これは、 .spec.postgresql.synchronous を介して実現できます。

同期レプリケーションはデフォルトで無効になっています。 synchronous スタンザは定義されていません。定義すると、2つのオプションが必須です。

method any クォーラムまたはfirst プライオリティ
number トランザクションが応答を待機する必要がある同期スタンバイサーバーの数

クォーラムベースの同期レプリケーション

PostgreSQLでは、クォーラムベースの同期レプリケーションにより、トランザクションのコミットは、WALレコードが指定された数のスタンバイにレプリケートされるまで待機します。これを有効にするには、method をany に設定します。

このレプリケーション方法は、CloudNativePGクラスターの最も一般的なセットアップです。

例

次の例は、3つのインスタンスを使用した一般的なcluster-example 構成に基づいて、少なくとも1つのインスタンスを使用してクォーラムベースの同期レプリケーションを設定します。

postgresql:
  synchronous:
    method: any
    number: 1

この構成では、CloudNativePGは次のようにsynchronous_standby_names のコンテンツを自動的に設定します。

ANY 1 (cluster-example-2, cluster-example-3, cluster-example-1)

非推奨の同期レプリケーション実装からの移行

このセクションでは、非推奨のクォーラムベースの同期レプリケーション形式からCloudNativePGの新しいより堅牢な実装に移行する方法について概要を説明します。

次のマニフェストを考えると

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: angus
spec:
  instances: 3
  minSyncReplicas: 1
  maxSyncReplicas: 1

  storage:
    size: 1Gi

次のとおりに、新しい形式に更新できます。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: angus
spec:
  instances: 3

  storage:
    size: 1Gi

  postgresql:
    synchronous:
      method: any
      number: 1
      dataDurability: required

厳密なデータの耐久性よりも自己修復を優先するには、代わりにdataDurability をpreferred に設定します。

優先度ベースの同期レプリケーション

PostgreSQLの優先度ベースの同期レプリケーションは、WALレコードが、優先度に基づいて選択された要求された数の同期スタンバイにレプリケートされるまで、トランザクションコミットを待機させます。 synchronous_standby_names オプションで前にリストされたスタンバイには、より高い優先順位が与えられ、同期とみなされます。現在の同期スタンバイが切断されると、次に優先度の高いスタンバイにすぐに置き換えられます。この方法を使用するには、 method をfirst に設定します。

注釈

現在、この方法は、以下で説明する`maxStandbyNamesFromCluster` 、standbyNamesPre 、および`standbyNamesPost` オプションを使用して、現在のクラスターを超えて同期レプリケーションを拡張する場合に最も役立ちます。

`synchronous_standby_names` コンテンツの制御

デフォルトでは、CloudNativePGはCluster リソースのローカルポッドの名前をsynchronous_standby_names に設定し、PostgreSQLクラスター内の同期レプリケーションを保証します。 .spec.postgresql.synchronous スタンザの次のオプショナルパラメーターを使用して、要件とレプリケーション方法クォーラムまたは優先順位に基づいてsynchronous_standby_names のコンテンツをカスタマイズできます。

maxStandbyNamesFromCluster PostgreSQLのsynchronous_standby_names オプションに自動的に含めることができるローカルCluster オブジェクトのポッド名の最大数。
standbyNamesPre オペレーターによって自動的にリストされたローカルポッド名のリストの前に追加されるスタンバイ名のリスト特にapplication_name 。
standbyNamesPost オペレーターによって自動的にリストされたローカルポッド名のリストに追加されるスタンバイ名のリスト特にapplication_name 。

警告

standbyNamesPre および`standbyNamesPost` の名前が正しいことを確認する責任があります。 CloudNativePGは、ここにリストされている`application_name` でスタンバイを管理し、高可用性を保証することを想定しています。エントリが間違っていると、PostgreSQLデータベースのアップタイムが危険にさらされる可能性があります。

例

次に、いくつかの例を示します。すべては、3つのインスタンスを持つcluster-example に基づいています。

設定すると

postgresql:
  synchronous:
    method: any
    number: 1
    maxStandbyNamesFromCluster: 1
    standbyNamesPre:
      - angus

synchronous_standby_names の内容は次のとおりです。

ANY 1 (angus, cluster-example-2)

設定すると

postgresql:
  synchronous:
    method: any
    number: 1
    maxStandbyNamesFromCluster: 0
    standbyNamesPre:
      - angus
      - malcolm

synchronous_standby_names の内容は次のとおりです。

ANY 1 (angus, malcolm)

設定すると

postgresql:
  synchronous:
    method: first
    number: 2
    maxStandbyNamesFromCluster: 1
    standbyNamesPre:
      - angus
    standbyNamesPost:
      - malcolm

synchronous_standby_names オプションは次のようになります。

FIRST 2 (angus, cluster-example-2, malcolm)

データの耐久性と同期レプリケーション

.spec.postgresql.synchronous スタンザのdataDurability オプションは、同期レプリケーションのデータの安全性と可用性間のトレードオフを制御します。 required またはpreferred に設定できます。指定しない場合、デフォルトはrequired になります。

注釈

preferred は、 standbyNamesPre および`standbyNamesPost` が設定されていない場合にのみ使用できます。

必要なデータの耐久性

dataDurability がrequired に設定されている場合、PostgreSQLは、WAL書き込み先行ログレコードが指定された数の同期スタンバイにレプリケートされた後にコミットされたトランザクションのみを考慮します。この設定では、可用性よりデータの安全性が優先されます。つまり、必要な数の同期スタンバイが使用できない場合、書き込み操作は一時停止します。これにより、ゼロデータ損失RPO=0が保証されますが、ネットワークの中断またはスタンバイ障害が発生するとデータベースの可用性が低下する場合があります。

同期スタンバイは次の優先順位で選択されます。

正常インスタンス
異常なインスタンス
プライマリー

リストはこの値が設定されている場合はmaxStandbyNamesFromCluster に基づいて切り捨てられ、正常なインスタンスを優先し、synchronous_standby_names が設定されていることを確認します。

例

次の例を考えます。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: foo
spec:
  instances: 3
  postgresql:
    synchronous:
      method: any
      number: 1
      dataDurability: required

初期状態。 synchronous_standby_names の内容は次のとおりです。

ANY 1 ("foo-2","foo-3","foo-1")

foo-2 は使用できなくなります。優先的にプッシュバックされます。

ANY 1 ("foo-3","foo-2","foo-1")

foo-3 も使用できなくなります。リストには正常なスタンバイは含まれません。

ANY 1 ("foo-2","foo-3","foo-1")

この時点で、少なくとも1つのスタンバイが再び利用可能になるまで、書き込み操作は許可されません。

スタンバイが再び利用できるようになると、synchronous_standby_names は初期状態に戻ります。

優先データの耐久性

dataDurability がpreferred に設定されている場合、必要な同期インスタンスの数は、使用可能なスタンバイの数に基づいて調整されます。 PostgreSQLは、指定された数の同期スタンバイにWALレコードをレプリケートしようとしますが、要求された数よりも少ないスタンバイが使用可能な場合でも、書き込み操作は続行されます。

注釈

レプリカにとって*ready/available*が何を意味するかを明確に理解し、それに応じて期待を設定します。デフォルトでは、レプリカは少なくとも1回ソースに正常に接続すると、準備ができているとみなされます。ただし、CloudNativePGでは、最大遅延に基づいて、レプリカの起動および準備状況プローブを構成できます。詳細については、 Postgres Instance Manager を参照してください。

この設定は、データの安全性と可用性のバランスをとり、アプリケーションは一時的にスタンバイが使用不可になっている間も書き込みを続行できます。したがって、 自己修復モード としても知られています。

警告

このモードでは、すべてのスタンバイが使用不可になるとデータが損失する可能性があります。

preferred データ持続性では、 正常なレプリカのみ がsynchronous_standby_names に含まれます。

例

次の例を考えます。デモンストレーションでは、5つのインスタンスと2つの同期スタンバイを持つbar という名前のクラスターを使用します。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: bar
spec:
  instances: 5
  postgresql:
    synchronous:
      method: any
      number: 2
      dataDurability: preferred

初期状態。 synchronous_standby_names の内容は次のとおりです。

ANY 2 ("bar-2","bar-3", "bar-4", "bar-5")

bar-2 およびbar-3 は使用できなくなります。これらはリストから削除されます。

ANY 2 ("bar-4", "bar-5")

bar-4 も使用できなくなります。リストから削除されます。使用可能なスタンバイの数は要求された数より少ないため、要求された量は削減されます。

ANY 1 ("bar-5")

bar-5 も使用できなくなります。 synchronous_standby_names は空になり、同期レプリケーションを完全に無効にします。書き込み操作は継続されますが、プライマリ障害が発生した場合に潜在的なデータ損失のリスクが伴います。
レプリカが戻ると、synchronous_standby_names は初期状態に戻ります。

同期レプリケーション非推奨

警告

CloudNativePG 1.24より前では、クォーラムベースの同期レプリケーション実装のみがサポートされていました。この方法は現在非推奨ですが、すぐに削除されることはありません。新しい方法は、自己修復よりもデータの耐久性を優先し、優先度ベースの同期レプリケーションや`synchronous_standby_names` オプションの完全な制御など、より堅牢な機能を提供します。前の段落で説明したように、同期レプリケーションの新しい構成方法に徐々に移行することをお勧めします。

注釈

非推奨なメソッドと新しいメソッドは相互排他的です。

CloudNativePGは、 minSyncReplicas およびmaxSyncReplicas と呼ばれる2つの構成オプションを介して **クォーラムベースの同期ストリーミングレプリケーション* の構成をサポートします。これらは、任意の時点で使用可能な同期スタンバイレプリカの予想される最小数と最大数です。自己修復の目的で、オペレーターは常にこれらの2つの値を使用可能なレプリカの数と比較して、クォーラムを決定します。

注釈

デフォルトでは、同期レプリケーションは、使用可能なすべてのレプリカから区別なく選択します。次のセクションで説明するように`syncReplicaElectionConstraint` オプションを介してノードラベルを操作することにより、同期レプリカをスケジュールできるノードを制限できます。

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

ANY q (pod1, pod2, ...)

そこで

q は、演算子によって自動的に計算された整数です。1 ≤ minSyncReplicas ≤ q ≤ maxSyncReplicas ≤ readyReplicas
pod1, pod2, ... は、クラスター内のすべてのPostgreSQLポッドのリストです

警告

自己修復機能を提供するために、オペレーターは`minSyncReplicas` そのような値が現在使用可能なレプリカの数より大きい場合は無視できます。 readyReplicas が`0` の場合、同期レプリケーションは自動的に無効になります。

PostgreSQL documentation で述べているように、 メソッド``ANY`` は、クォーラムベースの同期レプリケーションを指定し、WALレコードが少なくともリスト 内の要求された数の同期スタンバイにレプリケートされるまで、トランザクションコミットを待機させます。

注釈

オペレーターが同期レプリケーション設定の適用よりも自己修復を選択する場合でも、3つ以上のインスタンスがあるクラスター、より一般的には`maxSyncReplicas < (instances - 1)` の場合にのみ同期レプリケーションを計画することをお勧めします。

同期レプリケーションのノードを選択します

CloudNativePGを使用すると、PGDATAとPostgresポッドを保持するPVCが存在するノードラベルに基づいて、アンチアフィニティルールを介してクォーラムベースの同期レプリケーションセットに参加する資格のあるPostgreSQLインスタンスを選択できます。

注釈

一般的なポッドアフィニティおよびアンチアフィニティルールの詳細については、 Scheduling を確認してください。

警告

.spec.postgresql.syncReplicaElectionConstraint オプションは、同期レプリケーションの古い実装にのみ適用されます同期レプリケーション非推奨を参照してください。

この機能のユースケースの例として単一の同期レプリカを持つクラスターでは、同期レプリカがプライマリインスタンスとは別のアベイラビリティーゾーンにあることを確認できます。通常は topology.kubernetes.io/zone label on a node で識別されます。これにより、単一のアベイラビリティーゾーンで停止が発生した場合のクラスターのロバスト性、特に目標復旧ポイント PgBouncerPoolMode の点で向上します。

アンチアフィニティのアイデアは、クォーラムに参加する同期レプリカが、選択したラベルこの場合、アベイラビリティーゾーンラベルの異なる値を持つノードで実行されているポッドから選択されるようにすることです。プライマリが現在存在するノード実行中。このような基準に一致するノードがない場合、レプリカは同期レプリケーションの対象となります。

注釈

自己修復の適用は、同期レプリカ選択の追加制約を定義しているときに引き続き適用されます同期レプリケーションを介したゼロデータ損失クラスターを参照してください。

次の例は、.spec.postgresql 内のsyncReplicaElectionConstraint セクションを介してこれを行う方法を示しています。 nodeLabelsAntiAffinity では、現在のプライマリと、アベイラビリティーゾーンラベルの値が異なるノードにあるレプリカの間で、オペレーターによって同期レプリケーションが動的に構成されることを確認するために、評価する必要があるノードラベルを指定できます。プライマリが存在するノード

spec:
  instances: 3
  postgresql:
    syncReplicaElectionConstraint:
      enabled: true
      nodeLabelsAntiAffinity:
      - topology.kubernetes.io/zone

ご想像のとおり、アベイラビリティーゾーンは一例にすぎませんが、ストレージ、CPU、メモリなど、ノードを説明する他のラベルに基づいてこの動作をカスタマイズできます。

レプリケーションスロット

Replication slots

は、9.4で導入されたネイティブのPostgreSQL機能で、接続されているすべてのストリーミングレプリケーションクライアントがWALセグメントを受信するまで、プライマリがWALセグメントを削除しないこと、およびプライマリが次の場合でもリカバリ競合を発生させる可能性のある行を削除しないことを保証する自動方法を提供しますスタンバイは一時的に切断されています。

レプリケーションスロットは、それを作成したインスタンスにのみ存在し、PostgreSQLはスタンバイサーバーでレプリケートしません。その結果、フェールオーバーまたはスイッチオーバー後、新しいプライマリには、古いプライマリのレプリケーションスロットが含まれません。これにより、古いプライマリに接続され、スロットを失ったストリーミングレプリケーションクライアントに問題が発生する可能性があります。

CloudNativePGは、プライマリから各スタンバイに物理レプリケーションスロットのコンテンツを同期するターンキーソリューションを提供し、2つのユースケースに対応します。

Postgresクラスターの高可用性のために自動的に作成されるレプリケーションスロット高可用性のためのレプリケーションスロットを参照してください

詳細についてはこちら

プライマリで作成されたユーザー定義レプリケーションスロット

高可用性のためのレプリケーションスロット

CloudNativePGは、高可用性クラスターから始めて、クラスター管理レプリケーションスロットの概念を導入することにより、このギャップを埋めます。この機能は、プライマリとスタンバイの両方で、高可用性クラスター内の各ホットスタンバイレプリカの物理レプリケーションスロットを自動的に管理します。

CloudNativePGでは、次の用語を使用します。

プライマリHAスロット ライフサイクルがクラスターの現在のプライマリによって完全に管理され、目的がストリーミングレプリケーションで特定のスタンバイにマッピングすることである物理レプリケーションスロット。このようなスロットは、プライマリにのみ存在します。
スタンバイHAスロット スタンバイの物理レプリケーションスロット。そのライフサイクルは、プライマリのpg_replication_slots ビューの内容に基づいて、クラスター内の別のスタンバイによって完全に管理され、pg_replication_slot_advance() を使用して定期的に更新されます。

この機能はデフォルトで有効になっており、構成から無効にできます。詳細については、 ReplicationSlotsConfiguration を参照してください。以下に、メインオプションの簡単な説明を示します。

.spec.replicationSlots.highAvailability.enabled

true の場合、機能は有効になっています true がデフォルトです

.spec.replicationSlots.highAvailability.slotPrefix

この機能のオペレーターが管理するレプリケーションスロットを識別するプレフィックスデフォルト_cnpg_

.spec.replicationSlots.updateInterval

スタンバイがレプリケーションスロットのローカルコピーの位置を現在のプライマリ上の位置と同期する頻度。秒単位で表現されますデフォルト30

お勧めしませんが、別の動作が必要な場合は、上記のオプションをカスタマイズできます。

たとえば、次のマニフェストは、レプリケーションスロットを無効にしたクラスターを作成します。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: cluster-example
spec:
  instances: 3
  # Disable replication slots for HA in the cluster
  replicationSlots:
    highAvailability:
      enabled: false

  storage:
    size: 1Gi

ユーザー定義レプリケーションスロット

CloudNativePGは、物理レプリケーションスロットを宣言的に定義する方法をサポートしていませんが、 create your own slots via SQL は可能です。

注釈

現時点では、宣言的な方法でレプリケーションスロットを管理する計画はありませんが、ユーザーから受け取るフィードバックによっては変更される可能性があります。その理由は、レプリケーションスロットは特定の目的のために存在し、プライマリ上のスロットのライフサイクル全体を監督する特定のアプリケーションで各スロットを管理する必要があるためです。

CloudNativePGは、上記で説明したHAレプリケーションスロットの場合と同様に、プライマリとスタンバイ間のユーザー管理の物理レプリケーションスロットの同期を管理できます。唯一の違いは、レプリケーションスロットを作成する必要があることです。

この機能はデフォルトで有効になっていますが、レプリケーションスロットが同期されることを意味しますが、 synchronizeReplicas スタンザを介して無効にするか、正規表現を使用して一部のスロットを除外するなど、その動作をさらにカスタマイズできます。例

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: cluster-example
spec:
  instances: 3
  replicationSlots:
    synchronizeReplicas:
      enabled: true
      excludePatterns:
      - "^foo"

詳細については、 ReplicationSlotsConfiguration を参照してください。以下に、メインオプションの簡単な説明を示します。

.spec.replicationSlots.synchronizeReplicas.enabled

trueまたは指定されない場合、プライマリのすべてのユーザー定義のレプリケーションスロットは、各スタンバイで同期されます。 falseに変更した場合、オペレーターは、各スタンバイで自分自身が以前に作成したレプリケーションスロットを削除します。

.spec.replicationSlots.synchronizeReplicas.excludePatterns

同期から除外するユーザー定義のレプリケーションスロットの名前と一致する正規表現パターンのリスト。これは、命名規則に基づいて特定のスロットを除外する場合に役立ちます。

警告

この機能を利用するユーザーは、ユーザー定義のレプリケーションスロットを注意深く監視して、運用要件を満たし、フェイルオーバープロセスを妨げないことを確認する必要があります。

同期周波数

この例のように、スタンバイがプライマリでpg_replication_slots ビューを照会し、レプリケーションスロットのローカルコピーを更新する頻度を制御することもできます。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: cluster-example
spec:
  instances: 3
  # Reduce the frequency of standby HA slots updates to once every 5 minutes
  replicationSlots:
    updateInterval: 300

  storage:
    size: 1Gi

論理デコードスロットの同期

CloudNativePGは、高可用性クラスター内のすべてのノードで論理デコーディングレプリケーションスロットを同期でき、フェールオーバーまたはスイッチオーバー後の論理レプリケーションのシームレスな継続を保証します。この機能はデフォルトでは無効になっており、有効にするには2つの手順が必要です。

最初のステップは、論理デコードスロットの同期を有効にすることです。

# ...
replicationSlots:
  highAvailability:
    synchronizeLogicalDecoding: true

2番目のステップには、PostgreSQLパラメーターの構成が含まれます。以下で説明するように、必要な構成はPostgreSQLバージョンによって異なります。

有効にすると、オペレーターはフェールオーバーとスイッチオーバー中に論理デコードスロット状態を自動的に管理し、スロットの無効化を防止し、論理レプリケーションクライアントのデータ損失を回避します。

PostgreSQL 17以降での動作

PostgreSQL 17以降の場合、CloudNativePGは synchronized_standby_slots を透過的に管理します。

PostgreSQL構成でsync_replication_slots とhot_standby_feedback の両方を有効にする必要があります。

##  ...

postgresql:
  parameters:
    # ...
    hot_standby_feedback: on
    sync_replication_slots: on

さらに、 failover オプションを有効にして論理レプリケーションSubscription を作成する必要があります。例

apiVersion: postgresql.cnpg.io/v1
kind: Subscription

##  ...

spec:

##  ...

  parameters:
    failover: true

##  ...

構成すると、論理WAL送信プロセスは、指定されたレプリケーションスロットが関連するWALの受信とフラッシュを確認した後のみ、デコードされた変更をプラグインに送信し、次のことを保証します。

論理レプリケーションスロットは、パブリッシャーのレプリカが安全に受信するまで変更を消費しません。
ロジカルレプリケーションクライアントは、フェールオーバー後にデータを欠落することなく、昇格したスタンバイにシームレスに再接続できます。

論理レプリケーションスロットの同期の詳細については、 Logical Replication Failover のPostgreSQLドキュメントを参照してください。

PostgreSQL 16以前の動作

PostgreSQL 16以前のバージョンの場合、CloudNativePGは pg_failover_slots を使用します

フェールオーバー全体で論理レプリケーションスロットの同期を維持するため。

レプリケーションスロット用に保持されるWALサイズのキャップ

レプリケーションスロットが有効になっている場合、PostgreSQLがレプリケーションスロットによって要求されたWALファイルを保持しようとするため、ディスク領域が不足する場合があります。これは、スタンバイが一時的にダウンしている、遅延している、または単に孤立したレプリケーションスロットが原因で発生する可能性があります。

PostgreSQL 13以降、 max_slot_wal_keep_size を利用できます。

構成オプションは、レプリケーションスロットがチェックポイント時にpg_wal ディレクトリに保持できるWALファイルの最大サイズを制御します。デフォルトでは、PostgreSQLではmax_slot_wal_keep_size は-1 に設定されています。これは、レプリケーションスロットが無制限の量のWALファイルを保持できることを意味します。その結果、レプリケーションスロットのサポートが有効になっているときにmax_slot_wal_keep_size を明示的に設定することをお勧めします。例

# ...
postgresql:
  parameters:
    max_slot_wal_keep_size: "10GB"
# ...

レプリケーションスロットの監視

インフラストラクチャでレプリケーションスロットは注意深く監視する必要があります。デフォルトでは、Prometheusエクスポーターのpg_replication_slots メトリックに、スロットの名前、タイプ、アクティブかどうか、プライマリからの遅延などの重要な情報を提供します。

注釈

CloudNativePG展開をモニタする方法の詳細については、バックアップの進行状況のモニタリングを参照してください。

Replication

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

非常に成熟したテクノロジー

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

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

同期レプリケーション

クォーラムベースの同期レプリケーション

例

非推奨の同期レプリケーション実装からの移行

優先度ベースの同期レプリケーション

synchronous_standby_names コンテンツの制御

例

データの耐久性と同期レプリケーション

必要なデータの耐久性

例

優先データの耐久性

例

同期レプリケーション非推奨

同期レプリケーションのノードを選択します

レプリケーションスロット

高可用性のためのレプリケーションスロット

ユーザー定義レプリケーションスロット

同期周波数

論理デコードスロットの同期

PostgreSQL 17以降での動作

PostgreSQL 16以前の動作

レプリケーションスロット用に保持されるWALサイズのキャップ

レプリケーションスロットの監視

`synchronous_standby_names` コンテンツの制御