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