Replication
===========
.. raw:: html
物理的レプリケーションはPostgreSQLの強みの1つであり、世界最大の組織の一部がビジネス継続性のコンテキストでのデータの管理にそれを選択した理由の1つです。物理レプリケーションは、主に高可用性を実現するために使用されますが、読み取り専用ワークロードのスケールアウトと、プライマリから一部の作業をオフロードすることもできます。
.. Note::
このセクションは、同じKubernetesクラスターで管理される同じ`Cluster` リソース内のレプリケーションに関するものです。異なるKubernetesクラスター間でも、別のPostgres `Cluster` リソースを使用して複製する方法については、 :ref:`レプリカクラスター <レプリカクラスター>` セクションを参照してください。
アプリケーションレベルのレプリケーション
----------------------------------------
PostgreSQLのレプリケーション機能に長年貢献してきましたが、ネイティブ物理レプリケーションテクノロジーに基づいてCloudNativePGで高可用性を構築し、Kubernetes
APIに直接統合することにしました。
Kubernetesの用語では、これは
*ストレージレベルのレプリケーション*\ とは対照的に、\*\*
アプリケーションレベルのレプリケーション**と呼ばれます。
非常に成熟したテクノロジー
--------------------------
PostgreSQLには、プライマリインスタンスから1つ以上のレプリカにデータをレプリケートするための非常に堅牢で成熟したネイティブフレームワークがあり、WALライトアヘッドログに継続的に保存されるトランザクションの変更の概念を中心に構築されています。
クラッシュリカバリーとポイントインタイムリカバリーテクノロジーの進化として始まった物理的レプリケーションは、継続的リカバリーでのプライマリからウォームスタンバイへのWALシッピングを介してPostgreSQL
8.22006で最初に導入されました。
PostgreSQL 9.02010は、 *ホットスタンバイ*
を介したWALストリーミングと読み取り専用レプリカを導入しました。
2011年、PostgreSQL
9.1はトランザクションレベルで同期レプリケーションをもたらし、
:ref:`PgBouncerPoolMode `
=0クラスターをサポートしました。カスケードレプリケーションはPostgreSQL
9.22012で追加されました。 :ref:`ロジカルレプリケーションのパブリケーション <ロジカルレプリケーションのパブリケーション>` の基礎はPostgreSQL
9.42014で確立され、バージョン102017では、オリジンから宛先にデータをレプリケートするためのパブリッシャー/サブスクライバーパターンのネイティブサポートを導入しました。以下の表は、これらのマイルストーンをまとめたものです。
.. csv-table::
:header: Version,Year,Feature
:widths: 10,10,25
:align: left
:class: longtable
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``
というユーザーを作成します。
.. code:: sql
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
.. Note::
CloudNativePGが証明書を管理する方法の詳細については、 :ref:`Certificates ` を参照してください。
ドキュメントで。
構成されている場合、オペレーターはHAクラスター内のすべてのレプリカのレプリケーションスロットを管理し、各スタンバイに必要なWALファイルが、フェールオーバーまたはスイッチオーバーの後でもプライマリのストレージに保持されるようにします。
.. Note::
CloudNativePGが高可用性レプリカのレプリケーションスロットを自動的に管理する方法の詳細については、 :ref:`高可用性のためのレプリケーションスロット <高可用性のためのレプリケーションスロット>` を参照してください。
以下。
継続的なバックアップ統合
^^^^^^^^^^^^^^^^^^^^^^^^
クラスターで継続的バックアップが構成されている場合、CloudNativePGは、継続的リカバリー時に\ ``restore_command``
を利用するようにレプリカを透過的に構成します。その結果、PostgreSQLは、ストリーミングレプリケーションを介したWALのプルが失敗するときは常に、フォールバックオプションとしてWALアーカイブを使用できます。
同期レプリケーション
--------------------
CloudNativePGは、両方の `quorum-based and priority-based synchronous replication for PostgreSQL `_ をサポートしています。
.. Warning::
デフォルトでは、トランザクションのコミット中にWALレプリケーションに必要な数のスタンバイノードを使用できない場合、同期レプリケーションは書き込み操作を一時停止します。この動作はデータの耐久性を優先し、PostgreSQL DBAのベストプラクティスに沿っています。ただし、セットアップでの厳密なデータの耐久性よりも自己修復の方が優先される場合、この設定を調整できます。この動作の管理の詳細については、 :ref:`データの耐久性と同期レプリケーション <データの耐久性と同期レプリケーション>` を参照してください。
セクション。
.. Note::
:ref:`*failover quorum* feature `
同期レプリケーションと並行して使用して、フェールオーバーイベント中のデータの耐久性と安全性を向上させることができます。
``synchronous_standby_names``
オプションの直接構成は許可されていません。ただし、CloudNativePGは、このオプションにローカルポッドの名前を自動的に入力しますが、カスタマイズで\ ``Cluster``
リソースを超えて同期レプリケーションを拡張できます。これは、
:ref:`.spec.postgresql.synchronous ` を介して実現できます。
同期レプリケーションはデフォルトで無効になっています。 ``synchronous``
スタンザは定義されていません。定義すると、2つのオプションが必須です。
- ``method`` ``any`` クォーラムまたは\ ``first`` プライオリティ
- ``number``
トランザクションが応答を待機する必要がある同期スタンバイサーバーの数
クォーラムベースの同期レプリケーション
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PostgreSQLでは、クォーラムベースの同期レプリケーションにより、トランザクションのコミットは、WALレコードが指定された数のスタンバイにレプリケートされるまで待機します。これを有効にするには、\ ``method``
を\ ``any`` に設定します。
このレプリケーション方法は、CloudNativePGクラスターの最も一般的なセットアップです。
例
^^
次の例は、3つのインスタンスを使用した一般的な\ ``cluster-example``
構成に基づいて、少なくとも1つのインスタンスを使用してクォーラムベースの同期レプリケーションを設定します。
.. code:: yaml
postgresql:
synchronous:
method: any
number: 1
この構成では、CloudNativePGは次のように\ ``synchronous_standby_names``
のコンテンツを自動的に設定します。
.. code:: console
ANY 1 (cluster-example-2, cluster-example-3, cluster-example-1)
非推奨の同期レプリケーション実装からの移行
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
このセクションでは、非推奨のクォーラムベースの同期レプリケーション形式からCloudNativePGの新しいより堅牢な実装に移行する方法について概要を説明します。
次のマニフェストを考えると
.. code:: yaml
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
name: angus
spec:
instances: 3
minSyncReplicas: 1
maxSyncReplicas: 1
storage:
size: 1Gi
次のとおりに、新しい形式に更新できます。
.. code:: yaml
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`` に設定します。
.. Note::
現在、この方法は、以下で説明する`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``
。
.. Warning::
`standbyNamesPre` および`standbyNamesPost` の名前が正しいことを確認する責任があります。 CloudNativePGは、ここにリストされている`application_name` でスタンバイを管理し、高可用性を保証することを想定しています。エントリが間違っていると、PostgreSQLデータベースのアップタイムが危険にさらされる可能性があります。
.. _例-1:
例
^^
次に、いくつかの例を示します。すべては、3つのインスタンスを持つ\ ``cluster-example``
に基づいています。
設定すると
.. code:: yaml
postgresql:
synchronous:
method: any
number: 1
maxStandbyNamesFromCluster: 1
standbyNamesPre:
- angus
``synchronous_standby_names`` の内容は次のとおりです。
.. code:: console
ANY 1 (angus, cluster-example-2)
設定すると
.. code:: yaml
postgresql:
synchronous:
method: any
number: 1
maxStandbyNamesFromCluster: 0
standbyNamesPre:
- angus
- malcolm
``synchronous_standby_names`` の内容は次のとおりです。
.. code:: console
ANY 1 (angus, malcolm)
設定すると
.. code:: yaml
postgresql:
synchronous:
method: first
number: 2
maxStandbyNamesFromCluster: 1
standbyNamesPre:
- angus
standbyNamesPost:
- malcolm
``synchronous_standby_names`` オプションは次のようになります。
.. code:: console
FIRST 2 (angus, cluster-example-2, malcolm)
データの耐久性と同期レプリケーション
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
``.spec.postgresql.synchronous`` スタンザの\ ``dataDurability``
オプションは、同期レプリケーションのデータの安全性と可用性間のトレードオフを制御します。
``required`` または\ ``preferred``
に設定できます。指定しない場合、デフォルトは\ ``required`` になります。
.. Note::
`preferred` は、 `standbyNamesPre` および`standbyNamesPost` が設定されていない場合にのみ使用できます。
必要なデータの耐久性
^^^^^^^^^^^^^^^^^^^^
``dataDurability`` が\ ``required``
に設定されている場合、PostgreSQLは、WAL書き込み先行ログレコードが指定された数の同期スタンバイにレプリケートされた後にコミットされたトランザクションのみを考慮します。この設定では、可用性よりデータの安全性が優先されます。つまり、必要な数の同期スタンバイが使用できない場合、書き込み操作は一時停止します。これにより、ゼロデータ損失RPO=0が保証されますが、ネットワークの中断またはスタンバイ障害が発生するとデータベースの可用性が低下する場合があります。
同期スタンバイは次の優先順位で選択されます。
1. 正常インスタンス
2. 異常なインスタンス
3. プライマリー
リストはこの値が設定されている場合は\ ``maxStandbyNamesFromCluster``
に基づいて切り捨てられ、正常なインスタンスを優先し、\ ``synchronous_standby_names``
が設定されていることを確認します。
.. _例-2:
例
''
次の例を考えます。
.. code:: yaml
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
name: foo
spec:
instances: 3
postgresql:
synchronous:
method: any
number: 1
dataDurability: required
1. 初期状態。 ``synchronous_standby_names`` の内容は次のとおりです。
::
ANY 1 ("foo-2","foo-3","foo-1")
2. ``foo-2`` は使用できなくなります。優先的にプッシュバックされます。
::
ANY 1 ("foo-3","foo-2","foo-1")
3. ``foo-3``
も使用できなくなります。リストには正常なスタンバイは含まれません。
::
ANY 1 ("foo-2","foo-3","foo-1")
この時点で、少なくとも1つのスタンバイが再び利用可能になるまで、書き込み操作は許可されません。
4. スタンバイが再び利用できるようになると、\ ``synchronous_standby_names``
は初期状態に戻ります。
優先データの耐久性
^^^^^^^^^^^^^^^^^^
``dataDurability`` が\ ``preferred``
に設定されている場合、必要な同期インスタンスの数は、使用可能なスタンバイの数に基づいて調整されます。
PostgreSQLは、指定された数の同期スタンバイにWALレコードをレプリケートしようとしますが、要求された数よりも少ないスタンバイが使用可能な場合でも、書き込み操作は続行されます。
.. Note::
レプリカにとって*ready/available*が何を意味するかを明確に理解し、それに応じて期待を設定します。デフォルトでは、レプリカは少なくとも1回ソースに正常に接続すると、準備ができているとみなされます。ただし、CloudNativePGでは、最大遅延に基づいて、レプリカの起動および準備状況プローブを構成できます。詳細については、 :ref:`Postgres Instance Manager ` を参照してください。
この設定は、データの安全性と可用性のバランスをとり、アプリケーションは一時的にスタンバイが使用不可になっている間も書き込みを続行できます。したがって、
*自己修復モード* としても知られています。
.. Warning::
このモードでは、すべてのスタンバイが使用不可になるとデータが損失する可能性があります。
``preferred`` データ持続性では、 **正常なレプリカのみ**
が\ ``synchronous_standby_names`` に含まれます。
.. _例-3:
例
''
次の例を考えます。デモンストレーションでは、5つのインスタンスと2つの同期スタンバイを持つ\ ``bar``
という名前のクラスターを使用します。
.. code:: yaml
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
name: bar
spec:
instances: 5
postgresql:
synchronous:
method: any
number: 2
dataDurability: preferred
1. 初期状態。 ``synchronous_standby_names`` の内容は次のとおりです。
::
ANY 2 ("bar-2","bar-3", "bar-4", "bar-5")
2. ``bar-2`` および\ ``bar-3``
は使用できなくなります。これらはリストから削除されます。
::
ANY 2 ("bar-4", "bar-5")
3. ``bar-4``
も使用できなくなります。リストから削除されます。使用可能なスタンバイの数は要求された数より少ないため、要求された量は削減されます。
::
ANY 1 ("bar-5")
4. ``bar-5`` も使用できなくなります。 ``synchronous_standby_names``
は空になり、同期レプリケーションを完全に無効にします。書き込み操作は継続されますが、プライマリ障害が発生した場合に潜在的なデータ損失のリスクが伴います。
5. レプリカが戻ると、\ ``synchronous_standby_names``
は初期状態に戻ります。
同期レプリケーション非推奨
--------------------------
.. Warning::
CloudNativePG 1.24より前では、クォーラムベースの同期レプリケーション実装のみがサポートされていました。この方法は現在非推奨ですが、すぐに削除されることはありません。新しい方法は、自己修復よりもデータの耐久性を優先し、優先度ベースの同期レプリケーションや`synchronous_standby_names` オプションの完全な制御など、より堅牢な機能を提供します。前の段落で説明したように、同期レプリケーションの新しい構成方法に徐々に移行することをお勧めします。
.. Note::
非推奨なメソッドと新しいメソッドは相互排他的です。
CloudNativePGは、 ``minSyncReplicas`` および\ ``maxSyncReplicas``
と呼ばれる2つの構成オプションを介して
\**クォーラムベースの同期ストリーミングレプリケーション\*
の構成をサポートします。これらは、任意の時点で使用可能な同期スタンバイレプリカの予想される最小数と最大数です。自己修復の目的で、オペレーターは常にこれらの2つの値を使用可能なレプリカの数と比較して、クォーラムを決定します。
.. Note::
デフォルトでは、同期レプリケーションは、使用可能なすべてのレプリカから区別なく選択します。次のセクションで説明するように`syncReplicaElectionConstraint` オプションを介してノードラベルを操作することにより、同期レプリカをスケジュールできるノードを制限できます。
同期レプリケーションはデフォルトで無効になっています ``minSyncReplicas``
および\ ``maxSyncReplicas`` は定義されていません。 ``minSyncReplicas``
と\ ``maxSyncReplicas``
の両方が設定されている場合、CloudNativePGはPostgreSQLの\ ``synchronous_standby_names``
オプションを次の値に自動的に更新します。
::
ANY q (pod1, pod2, ...)
そこで
- ``q``
は、演算子によって自動的に計算された整数です。\ ``1 ≤ minSyncReplicas ≤ q ≤ maxSyncReplicas ≤ readyReplicas``
- ``pod1, pod2, ...``
は、クラスター内のすべてのPostgreSQLポッドのリストです
.. Warning::
自己修復機能を提供するために、オペレーターは`minSyncReplicas` そのような値が現在使用可能なレプリカの数より大きい場合は無視できます。 `readyReplicas` が`0` の場合、同期レプリケーションは自動的に無効になります。
`PostgreSQL documentation `_ で述べているように、 *メソッド\ ``ANY``
は、クォーラムベースの同期レプリケーションを指定し、WALレコードが少なくともリスト*
内の要求された数の同期スタンバイにレプリケートされるまで、トランザクションコミットを待機させます。
.. Note::
オペレーターが同期レプリケーション設定の適用よりも自己修復を選択する場合でも、3つ以上のインスタンスがあるクラスター、より一般的には`maxSyncReplicas < (instances - 1)` の場合にのみ同期レプリケーションを計画することをお勧めします。
同期レプリケーションのノードを選択します
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
CloudNativePGを使用すると、PGDATAとPostgresポッドを保持するPVCが存在するノードラベルに基づいて、アンチアフィニティルールを介してクォーラムベースの同期レプリケーションセットに参加する資格のあるPostgreSQLインスタンスを選択できます。
.. Note::
一般的なポッドアフィニティおよびアンチアフィニティルールの詳細については、 :ref:`Scheduling ` を確認してください。
.. Warning::
`.spec.postgresql.syncReplicaElectionConstraint` オプションは、同期レプリケーションの古い実装にのみ適用されます :ref:`同期レプリケーション非推奨 <同期レプリケーション非推奨>` を参照してください。
この機能のユースケースの例として
単一の同期レプリカを持つクラスターでは、同期レプリカがプライマリインスタンスとは別のアベイラビリティーゾーンにあることを確認できます。通常は
``topology.kubernetes.io/zone`` `label on a node `_
で識別されます。これにより、単一のアベイラビリティーゾーンで停止が発生した場合のクラスターのロバスト性、特に目標復旧ポイント
:ref:`PgBouncerPoolMode ` の点で向上します。
アンチアフィニティのアイデアは、クォーラムに参加する同期レプリカが、選択したラベルこの場合、アベイラビリティーゾーンラベルの異なる値を持つノードで実行されているポッドから選択されるようにすることです。プライマリが現在存在するノード実行中。このような基準に一致するノードがない場合、レプリカは同期レプリケーションの対象となります。
.. Note::
自己修復の適用は、同期レプリカ選択の追加制約を定義しているときに引き続き適用されます :ref:`同期レプリケーションを介したゼロデータ損失クラスター <同期レプリケーションを介したゼロデータ損失クラスター>` を参照してください。
次の例は、\ ``.spec.postgresql`` 内の\ ``syncReplicaElectionConstraint``
セクションを介してこれを行う方法を示しています。
``nodeLabelsAntiAffinity``
では、現在のプライマリと、アベイラビリティーゾーンラベルの値が異なるノードにあるレプリカの間で、オペレーターによって同期レプリケーションが動的に構成されることを確認するために、評価する必要があるノードラベルを指定できます。プライマリが存在するノード
.. code:: yaml
spec:
instances: 3
postgresql:
syncReplicaElectionConstraint:
enabled: true
nodeLabelsAntiAffinity:
- topology.kubernetes.io/zone
ご想像のとおり、アベイラビリティーゾーンは一例にすぎませんが、ストレージ、CPU、メモリなど、ノードを説明する他のラベルに基づいてこの動作をカスタマイズできます。
レプリケーションスロット
------------------------
`Replication slots `_
は、9.4で導入されたネイティブのPostgreSQL機能で、接続されているすべてのストリーミングレプリケーションクライアントがWALセグメントを受信するまで、プライマリがWALセグメントを削除しないこと、およびプライマリが次の場合でもリカバリ競合を発生させる可能性のある行を削除しないことを保証する自動方法を提供しますスタンバイは一時的に切断されています。
レプリケーションスロットは、それを作成したインスタンスにのみ存在し、PostgreSQLはスタンバイサーバーでレプリケートしません。その結果、フェールオーバーまたはスイッチオーバー後、新しいプライマリには、古いプライマリのレプリケーションスロットが含まれません。これにより、古いプライマリに接続され、スロットを失ったストリーミングレプリケーションクライアントに問題が発生する可能性があります。
CloudNativePGは、プライマリから各スタンバイに物理レプリケーションスロットのコンテンツを同期するターンキーソリューションを提供し、2つのユースケースに対応します。
- Postgresクラスターの高可用性のために自動的に作成されるレプリケーションスロット
:ref:`高可用性のためのレプリケーションスロット <高可用性のためのレプリケーションスロット>` を参照してください
詳細についてはこちら
- プライマリで作成された :ref:`ユーザー定義レプリケーションスロット <ユーザー定義レプリケーションスロット>`
高可用性のためのレプリケーションスロット
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
CloudNativePGは、高可用性クラスターから始めて、クラスター管理レプリケーションスロットの概念を導入することにより、このギャップを埋めます。この機能は、プライマリとスタンバイの両方で、高可用性クラスター内の各ホットスタンバイレプリカの物理レプリケーションスロットを自動的に管理します。
CloudNativePGでは、次の用語を使用します。
- **プライマリHAスロット**
ライフサイクルがクラスターの現在のプライマリによって完全に管理され、目的がストリーミングレプリケーションで特定のスタンバイにマッピングすることである物理レプリケーションスロット。このようなスロットは、プライマリにのみ存在します。
- **スタンバイHAスロット**
スタンバイの物理レプリケーションスロット。そのライフサイクルは、プライマリの\ ``pg_replication_slots``
ビューの内容に基づいて、クラスター内の別のスタンバイによって完全に管理され、\ ``pg_replication_slot_advance()``
を使用して定期的に更新されます。
この機能はデフォルトで有効になっており、構成から無効にできます。詳細については、
:ref:`ReplicationSlotsConfiguration ` を参照してください。以下に、メインオプションの簡単な説明を示します。
``.spec.replicationSlots.highAvailability.enabled``
``true`` の場合、機能は有効になっています ``true`` がデフォルトです
``.spec.replicationSlots.highAvailability.slotPrefix``
この機能のオペレーターが管理するレプリケーションスロットを識別するプレフィックスデフォルト\ ``_cnpg_``
``.spec.replicationSlots.updateInterval``
スタンバイがレプリケーションスロットのローカルコピーの位置を現在のプライマリ上の位置と同期する頻度。秒単位で表現されますデフォルト30
お勧めしませんが、別の動作が必要な場合は、上記のオプションをカスタマイズできます。
たとえば、次のマニフェストは、レプリケーションスロットを無効にしたクラスターを作成します。
.. code:: yaml
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 `_ は可能です。
.. Note::
現時点では、宣言的な方法でレプリケーションスロットを管理する計画はありませんが、ユーザーから受け取るフィードバックによっては変更される可能性があります。その理由は、レプリケーションスロットは特定の目的のために存在し、プライマリ上のスロットのライフサイクル全体を監督する特定のアプリケーションで各スロットを管理する必要があるためです。
CloudNativePGは、上記で説明したHAレプリケーションスロットの場合と同様に、プライマリとスタンバイ間のユーザー管理の物理レプリケーションスロットの同期を管理できます。唯一の違いは、レプリケーションスロットを作成する必要があることです。
この機能はデフォルトで有効になっていますが、レプリケーションスロットが同期されることを意味しますが、
``synchronizeReplicas``
スタンザを介して無効にするか、正規表現を使用して一部のスロットを除外するなど、その動作をさらにカスタマイズできます。例
.. code:: yaml
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
name: cluster-example
spec:
instances: 3
replicationSlots:
synchronizeReplicas:
enabled: true
excludePatterns:
- "^foo"
詳細については、
:ref:`ReplicationSlotsConfiguration ` を参照してください。以下に、メインオプションの簡単な説明を示します。
``.spec.replicationSlots.synchronizeReplicas.enabled``
trueまたは指定されない場合、プライマリのすべてのユーザー定義のレプリケーションスロットは、各スタンバイで同期されます。
falseに変更した場合、オペレーターは、各スタンバイで自分自身が以前に作成したレプリケーションスロットを削除します。
``.spec.replicationSlots.synchronizeReplicas.excludePatterns``
同期から除外するユーザー定義のレプリケーションスロットの名前と一致する正規表現パターンのリスト。これは、命名規則に基づいて特定のスロットを除外する場合に役立ちます。
.. Warning::
この機能を利用するユーザーは、ユーザー定義のレプリケーションスロットを注意深く監視して、運用要件を満たし、フェイルオーバープロセスを妨げないことを確認する必要があります。
同期周波数
^^^^^^^^^^
この例のように、スタンバイがプライマリで\ ``pg_replication_slots``
ビューを照会し、レプリケーションスロットのローカルコピーを更新する頻度を制御することもできます。
.. code:: yaml
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つの手順が必要です。
最初のステップは、論理デコードスロットの同期を有効にすることです。
.. code:: yaml
# ...
replicationSlots:
highAvailability:
synchronizeLogicalDecoding: true
2番目のステップには、PostgreSQLパラメーターの構成が含まれます。以下で説明するように、必要な構成はPostgreSQLバージョンによって異なります。
有効にすると、オペレーターはフェールオーバーとスイッチオーバー中に論理デコードスロット状態を自動的に管理し、スロットの無効化を防止し、論理レプリケーションクライアントのデータ損失を回避します。
PostgreSQL 17以降での動作
^^^^^^^^^^^^^^^^^^^^^^^^^
PostgreSQL
17以降の場合、CloudNativePGは
`synchronized_standby_slots `_ を透過的に管理します。
PostgreSQL構成で\ ``sync_replication_slots``
と\ ``hot_standby_feedback`` の両方を有効にする必要があります。
.. code:: yaml
## ...
postgresql:
parameters:
# ...
hot_standby_feedback: on
sync_replication_slots: on
さらに、 ``failover``
オプションを有効にして論理レプリケーション\ ``Subscription``
を作成する必要があります。例
.. code:: yaml
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``
を明示的に設定することをお勧めします。例
.. code:: ini
# ...
postgresql:
parameters:
max_slot_wal_keep_size: "10GB"
# ...
レプリケーションスロットの監視
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
インフラストラクチャでレプリケーションスロットは注意深く監視する必要があります。デフォルトでは、Prometheusエクスポーターの\ ``pg_replication_slots``
メトリックに、スロットの名前、タイプ、アクティブかどうか、プライマリからの遅延などの重要な情報を提供します。
.. Note::
CloudNativePG展開をモニタする方法の詳細については、 :ref:`バックアップの進行状況のモニタリング <バックアップの進行状況のモニタリング>` を参照してください。