Replication =========== 物理的レプリケーションはPostgreSQLの強みの1つであり、世界最大の組織の一部がビジネス継続性のコンテキストでのデータの管理にそれを選択した理由の1つです。物理レプリケーションは、主に高可用性を実現するために使用されますが、読み取り専用ワークロードのスケールアウトと、プライマリから一部の作業をオフロードすることもできます。 .. Important:: このセクションは、同じKubernetesクラスターで管理される同じ`Cluster` リソース内のレプリケーションに関するものです。異なるKubernetesクラスター間でも、別のPostgres `Cluster` リソースを使用して複製する方法については、 :ref:`レプリカクラスター <レプリカクラスター>` セクションを参照してください。 アプリケーションレベルのレプリケーション ---------------------------------------- PostgreSQLのレプリケーション機能に長年貢献してきましたが、私たちはネイティブの物理レプリケーションテクノロジーに基づいてKubernetesのEDB Postgresの高可用性を構築し、Kubernetes APIに直接統合することにしました。 Kubernetesの用語では、これは_ストレージレベルのレプリケーション_とは対照的に、 **アプリケーションレベルのレプリケーション** と呼ばれます。 非常に成熟したテクノロジー -------------------------- PostgreSQLには、プライマリインスタンスから1つ以上のレプリカにデータをレプリケートするための非常に堅牢で成熟したネイティブフレームワークがあり、WALライトアヘッドログに継続的に保存されるトランザクションの変更の概念を中心に構築されています。 クラッシュリカバリーとポイントインタイムリカバリーテクノロジーの進化として始まった物理的レプリケーションは、継続的リカバリーでのプライマリからウォームスタンバイへのWALシッピングを介してPostgreSQL 8.22006で最初に導入されました。 PostgreSQL 9.0 2010は、 \_ホットスタンバイ_を介したWALストリーミングと読み取り専用レプリカを導入しました。 2011年、PostgreSQL 9.1はトランザクションレベルで同期レプリケーションをもたらし、 :ref:`リリース候補の目的 <リリース候補の目的>` =0クラスターをサポートしました。カスケードレプリケーションはPostgreSQL 9.22012で追加されました。 :ref:`Logical Replication ` の基礎はPostgreSQL 9.42014で確立され、バージョン102017では、オリジンから宛先にデータをレプリケートするためのパブリッシャー/サブスクライバーパターンのネイティブサポートを導入しました。以下の表は、これらのマイルストーンをまとめたものです。 .. csv-table:: :header: Version,Year,Feature :widths: 12,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レプリケーション機能とその各バージョンを強調表示しています。 ストリーミングレプリケーションのサポート ---------------------------------------- 現時点では、Kubernetes用EDB Postgresは、 ``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 hostssl replication streaming_replica all cert .. Seealso:: EDB Postgres for Kubernetesが証明書を管理する方法の詳細については、 :ref:`CertificatesConfiguration ` を参照してください。 ドキュメントで。 構成されている場合、オペレーターはHAクラスター内のすべてのレプリカのレプリケーションスロットを管理し、各スタンバイに必要なWALファイルが、フェールオーバーまたはスイッチオーバーの後でもプライマリのストレージに保持されるようにします。 .. Seealso:: KubernetesのEDB Postgresが高可用性レプリカのレプリケーションスロットを自動的に管理する方法の詳細については、 :ref:`高可用性のためのレプリケーションスロット <高可用性のためのレプリケーションスロット>` を参照してください。 以下。 継続的なバックアップ統合 ^^^^^^^^^^^^^^^^^^^^^^^^ クラスターで継続的バックアップが構成されている場合、KubernetesのEDB Postgresは、継続的リカバリー時に\ ``restore_command`` を利用するようにレプリカを透過的に構成します。その結果、PostgreSQLは、ストリーミングレプリケーションを介したWALのプルが失敗するときは常に、フォールバックオプションとしてWALアーカイブを使用できます。 同期レプリケーション -------------------- KubernetesのEDB Postgresは、両方の `quorum-based and priority-based synchronous replication for PostgreSQL `_ をサポートしています。 .. Warning:: デフォルトでは、トランザクションのコミット中にWALレプリケーションに必要な数のスタンバイノードを使用できない場合、同期レプリケーションは書き込み操作を一時停止します。この動作はデータの耐久性を優先し、PostgreSQL DBAのベストプラクティスに沿っています。ただし、セットアップでの厳密なデータの耐久性よりも自己修復の方が優先される場合、この設定を調整できます。この動作の管理の詳細については、 :ref:`データの耐久性と同期レプリケーション <データの耐久性と同期レプリケーション>` を参照してください。 セクション。 ``synchronous_standby_names`` オプションの直接構成は許可されていません。ただし、KubernetesのEDB Postgresは、このオプションにローカルポッドの名前を自動的に入力しますが、カスタマイズで\ ``Cluster`` リソースを超えて同期レプリケーションを拡張することもできます。これは、 :ref:`.spec.postgresql.synchronous ` を介して実現できます。 同期レプリケーションはデフォルトで無効になっています。 ``synchronous`` スタンザは定義されていません。定義すると、2つのオプションが必須です。 - ``method`` ``any`` クォーラムまたは\ ``first`` プライオリティ - ``number`` トランザクションが応答を待機する必要がある同期スタンバイサーバーの数 クォーラムベースの同期レプリケーション ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ PostgreSQLでは、クォーラムベースの同期レプリケーションにより、トランザクションのコミットは、WALレコードが指定された数のスタンバイにレプリケートされるまで待機します。これを有効にするには、\ ``method`` を\ ``any`` に設定します。 このレプリケーション方法は、KubernetesクラスターのEDB Postgresの最も一般的なセットアップです。 例 ^^ 次の例は、3つのインスタンスを使用した一般的な\ ``cluster-example`` 構成に基づいて、少なくとも1つのインスタンスを使用してクォーラムベースの同期レプリケーションを設定します。 .. code:: yaml postgresql: synchronous: method: any number: 1 この構成では、KubernetesのEDB Postgresは次のように\ ``synchronous_standby_names`` のコンテンツを自動的に設定します。 .. code:: console ANY 1 (cluster-example-2, cluster-example-3, cluster-example-1) 非推奨の同期レプリケーション実装からの移行 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ このセクションでは、非推奨のクォーラムベースの同期レプリケーション形式からKubernetesのEDB Postgresの新しいより堅牢な実装に移行する方法について概要を説明します。 次のマニフェストを考えると .. code:: yaml apiVersion: postgresql.k8s.enterprisedb.io/v1 kind: Cluster metadata: name: angus spec: instances: 3 minSyncReplicas: 1 maxSyncReplicas: 1 storage: size: 1G 次のとおりに、新しい形式に更新できます。 .. code:: yaml apiVersion: postgresql.k8s.enterprisedb.io/v1 kind: Cluster metadata: name: angus spec: instances: 3 storage: size: 1G postgresql: synchronous: method: any number: 1 dataDurability: required 厳密なデータの耐久性よりも自己修復を優先するには、代わりに\ ``dataDurability`` を\ ``preferred`` に設定します。 優先度ベースの同期レプリケーション ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ PostgreSQLの優先度ベースの同期レプリケーションは、WALレコードが、優先度に基づいて選択された要求された数の同期スタンバイにレプリケートされるまで、トランザクションコミットを待機させます。 ``synchronous_standby_names`` オプションで前にリストされたスタンバイには、より高い優先順位が与えられ、同期とみなされます。現在の同期スタンバイが切断されると、次に優先度の高いスタンバイにすぐに置き換えられます。この方法を使用するには、 ``method`` を\ ``first`` に設定します。 .. Important:: 現在、この方法は、以下で説明する`maxStandbyNamesFromCluster` 、`standbyNamesPre` 、および`standbyNamesPost` オプションを使用して、現在のクラスターを超えて同期レプリケーションを拡張する場合に最も役立ちます。 ``synchronous_standby_names`` コンテンツの制御 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ デフォルトでは、KubernetesのEDB Postgresは\ ``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` の名前が正しいことを確認するのは自分の責任です。 KubernetesのEDB Postgresは、ここにリストされている`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`` になります。 .. Important:: `preferred` は、 `standbyNamesPre` および`standbyNamesPost` が設定されていない場合にのみ使用できます。 必要なデータの耐久性 ^^^^^^^^^^^^^^^^^^^^ ``dataDurability`` が\ ``required`` に設定されている場合、PostgreSQLは、WAL書き込み先行ログレコードが指定された数の同期スタンバイにレプリケートされた後にコミットされたトランザクションのみを考慮します。この設定では、可用性よりデータの安全性が優先されます。つまり、必要な数の同期スタンバイが使用できない場合、書き込み操作は一時停止します。これにより、ゼロデータ損失RPO=0が保証されますが、ネットワークの中断またはスタンバイ障害が発生するとデータベースの可用性が低下する場合があります。 同期スタンバイは次の優先順位で選択されます。 1. 正常インスタンス 2. 異常なインスタンス 3. プライマリー リストはこの値が設定されている場合は\ ``maxStandbyNamesFromCluster`` に基づいて切り捨てられ、正常なインスタンスを優先し、\ ``synchronous_standby_names`` が設定されていることを確認します。 .. _例-2: 例 '' 次の例を考えます。 .. code:: yaml apiVersion: postgresql.k8s.enterprisedb.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レコードをレプリケートしようとしますが、要求された数よりも少ないスタンバイが使用可能な場合でも、書き込み操作は続行されます。 .. Important:: レプリカに対する_ready/available_の意味を明確に理解し、それに応じて期待を設定します。デフォルトでは、レプリカは少なくとも1回ソースに正常に接続すると、準備ができているとみなされます。 この設定は、データの安全性と可用性のバランスをとり、アプリケーションが一時的にスタンバイが使用不可になっているときに書き込みを継続できるようにします。したがって、\_self-healingモード_としても知られています。 .. Warning:: このモードでは、すべてのスタンバイが使用不可になるとデータが損失する可能性があります。 ``preferred`` データ持続性では、 **正常なレプリカのみ** が\ ``synchronous_standby_names`` に含まれます。 .. _例-3: 例 '' 次の例を考えます。デモンストレーションでは、5つのインスタンスと2つの同期スタンバイを持つ\ ``bar`` という名前のクラスターを使用します。 .. code:: yaml apiVersion: postgresql.k8s.enterprisedb.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:: Kubernetes 1.24のEDB Postgresより前では、クォーラムベースの同期レプリケーション実装のみがサポートされていました。この方法は現在非推奨ですが、すぐに削除されることはありません。新しい方法は、自己修復よりもデータの耐久性を優先し、優先度ベースの同期レプリケーションや`synchronous_standby_names` オプションの完全な制御など、より堅牢な機能を提供します。前の段落で説明したように、同期レプリケーションの新しい構成方法に徐々に移行することをお勧めします。 .. Important:: 非推奨なメソッドと新しいメソッドは相互排他的です。 KubernetesのEDB Postgresは、 ``minSyncReplicas`` および\ ``maxSyncReplicas`` と呼ばれる2つの構成オプションを介して \**クォーラムベースの同期ストリーミングレプリケーション\* の構成をサポートします。これらは、任意の時点で使用可能な同期スタンバイレプリカの予想される最小数と最大数です。自己修復の目的で、オペレーターは常にこれらの2つの値を使用可能なレプリカの数と比較して、クォーラムを決定します。 .. Important:: デフォルトでは、同期レプリケーションは、使用可能なすべてのレプリカを区別なく選択します。次のセクションで説明するように`syncReplicaElectionConstraint` オプションを介してノードラベルを操作することにより、同期レプリカをスケジュールできるノードを制限できます。 同期レプリケーションはデフォルトで無効になっています ``minSyncReplicas`` および\ ``maxSyncReplicas`` は定義されていません。 ``minSyncReplicas`` と\ ``maxSyncReplicas`` の両方が設定されている場合、Kubernetes用EDB PostgresはPostgreSQLの\ ``synchronous_standby_names`` オプションを次の値に自動的に更新します。 :: ANY q (pod1, pod2, ...) そこで - ``q`` は、演算子によって自動的に計算された整数です。\ ``1 <= minSyncReplicas <= q <= maxSyncReplicas <= readyReplicas`` - ``pod1, pod2, ...`` は、クラスター内のすべてのPostgreSQLポッドのリストです .. Warning:: 自己修復機能を提供するために、オペレーターは`minSyncReplicas` そのような値が現在使用可能なレプリカの数より大きい場合は無視できます。 `readyReplicas` が`0` の場合、同期レプリケーションは自動的に無効になります。 `PostgreSQL documentation `_ で述べているように、 \_method ``ANY`` は、クォーラムベースの同期レプリケーションを指定し、WALレコードが少なくともlist_内の要求された数の同期スタンバイにレプリケートされるまで、トランザクションコミットを待機させます。 .. Important:: オペレーターが同期レプリケーション設定の適用よりも自己修復を選択する場合でも、3つ以上のインスタンスがあるクラスター、より一般的には`maxSyncReplicas < (instances - 1)` の場合にのみ同期レプリケーションを計画することをお勧めします。 同期レプリケーションのノードを選択します ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ KubernetesのEDB Postgresを使用すると、PGDATAとPostgresポッドを保持するPVCが存在するノードラベルに基づいて、アンチアフィニティルールを介してクォーラムベースの同期レプリケーションセットに参加する資格のあるPostgreSQLインスタンスを選択できます。 .. Seealso:: 一般的なポッドアフィニティおよびアンチアフィニティルールの詳細については、 :ref:`Scheduling ` を確認してください。 .. Warning:: `.spec.postgresql.syncReplicaElectionConstraint` オプションは、同期レプリケーションの古い実装にのみ適用されます :ref:`同期レプリケーション非推奨 <同期レプリケーション非推奨>` を参照してください。 この機能のユースケースの例として 単一の同期レプリカを持つクラスターでは、同期レプリカがプライマリインスタンスとは別のアベイラビリティーゾーンにあることを確認できます。通常は ``topology.kubernetes.io/zone`` `label on a node `_ で識別されます。これにより、単一のアベイラビリティーゾーンで停止が発生した場合のクラスターのロバスト性、特に目標復旧ポイント :ref:`リリース候補の目的 <リリース候補の目的>` の点で向上します。 アンチアフィニティのアイデアは、クォーラムに参加する同期レプリカが、選択したラベルこの場合、アベイラビリティーゾーンラベルの異なる値を持つノードで実行されているポッドから選択されるようにすることです。プライマリが現在存在するノード実行中。このような基準に一致するノードがない場合、レプリカは同期レプリケーションの対象となります。 .. Important:: 自己修復の適用は、同期レプリカ選択の追加制約を定義しているときに引き続き適用されます :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はスタンバイサーバーでレプリケートしません。その結果、フェールオーバーまたはスイッチオーバー後、新しいプライマリには、古いプライマリのレプリケーションスロットが含まれません。これにより、古いプライマリに接続され、スロットを失ったストリーミングレプリケーションクライアントに問題が発生する可能性があります。 EDB Postgres for Kubernetesは、プライマリから各スタンバイに物理レプリケーションスロットのコンテンツを同期するターンキーソリューションを提供し、2つのユースケースに対応します。 - Postgresクラスターの高可用性のために自動的に作成されるレプリケーションスロット :ref:`高可用性のためのレプリケーションスロット <高可用性のためのレプリケーションスロット>` を参照してください 詳細についてはこちら - プライマリで作成された :ref:`ユーザー定義レプリケーションスロット <ユーザー定義レプリケーションスロット>` 高可用性のためのレプリケーションスロット ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ KubernetesのEDB Postgresは、高可用性クラスターから始めるクラスター管理レプリケーションスロットの概念を導入することにより、このギャップを埋めます。この機能は、プライマリとスタンバイの両方で、高可用性クラスター内の各ホットスタンバイレプリカの物理レプリケーションスロットを自動的に管理します。 KubernetesのEDB Postgresでは、次の用語を使用します。 - **プライマリHAスロット** ライフサイクルがクラスターの現在のプライマリによって完全に管理され、目的がストリーミングレプリケーションで特定のスタンバイにマッピングすることである物理レプリケーションスロット。このようなスロットは、プライマリにのみ存在します。 - **スタンバイHAスロット** スタンバイの物理レプリケーションスロット。そのライフサイクルは、プライマリの\ ``pg_replication_slots`` ビューの内容に基づいて、クラスター内の別のスタンバイによって完全に管理され、\ ``pg_replication_slot_advance()`` を使用して定期的に更新されます。 この機能はデフォルトで有効になっており、構成から無効にできます。詳細は :ref:`ReplicationSlotsConfiguration ` を参照してください。以下に、メインオプションの簡単な説明を示します。 ``.spec.replicationSlots.highAvailability.enabled`` ``true`` の場合、機能は有効です ``true`` がデフォルトです ``.spec.replicationSlots.highAvailability.slotPrefix`` この機能のオペレーターが管理するレプリケーションスロットを識別するプレフィックスデフォルト\ ``_cnp_`` ``.spec.replicationSlots.updateInterval`` スタンバイがレプリケーションスロットのローカルコピーの位置を現在のプライマリ上の位置と同期する頻度。秒単位で表現されますデフォルト30 お勧めしませんが、別の動作が必要な場合は、上記のオプションをカスタマイズできます。 たとえば、次のマニフェストは、レプリケーションスロットを無効にしたクラスターを作成します。 .. code:: yaml apiVersion: postgresql.k8s.enterprisedb.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 ユーザー定義レプリケーションスロット ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ KubernetesのEDB Postgresは、物理レプリケーションスロットを宣言的に定義する方法をサポートしていませんが、 `create your own slots via SQL `_ はできます。 .. Note rmation:: 現時点では、宣言的な方法でレプリケーションスロットを管理する計画はありませんが、ユーザーから受け取るフィードバックによっては変更される可能性があります。その理由は、レプリケーションスロットは特定の目的のために存在し、プライマリ上のスロットのライフサイクル全体を監督する特定のアプリケーションで各スロットを管理する必要があるためです。 KubernetesのEDB Postgresは、上記で説明したHAレプリケーションスロットの場合と同様に、プライマリとスタンバイ間のユーザー管理の物理レプリケーションスロットの同期を管理できます。唯一の違いは、レプリケーションスロットを作成する必要があることです。 この機能はデフォルトで有効になっていますが、レプリケーションスロットが同期されることを意味しますが、 ``synchronizeReplicas`` スタンザを介して無効にするか、正規表現を使用して一部のスロットを除外するなど、その動作をさらにカスタマイズできます。例 .. code:: yaml apiVersion: postgresql.k8s.enterprisedb.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.k8s.enterprisedb.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 レプリケーションスロット用に保持されるWALサイズのキャップ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ レプリケーションスロットが有効になっている場合、PostgreSQLがレプリケーションスロットによって要求されたWALファイルを保持しようとするため、ディスク領域が不足する場合があります。これは、スタンバイが一時的にダウンしている、遅延している、または単に孤立したレプリケーションスロットが原因で発生する可能性があります。 PostgreSQL 13以降、 :ref:`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`` メトリックに、スロットの名前、タイプ、アクティブかどうか、プライマリからの遅延などの重要な情報を提供します。 .. Seealso:: Kubernetes展開のEDB Postgresをモニタする方法の詳細については、 :ref:`モニタリングとメトリック <モニタリングとメトリック>` を参照してください。