レプリケーション¶
物理レプリケーションはPostgreSQLの強みの1つであり、世界最大の組織の一部がビジネス継続性のコンテキストでのデータ管理にPostgreSQLを選択した理由の1つです。主に高可用性を実現するために使用される物理レプリケーションでは、読み取り専用ワークロードのスケールアウトと、プライマリからの一部の作業のオフロードも可能です。
重要
このセクションは、同じKubernetesクラスターで管理される同じ`Cluster` リソース内のレプリケーションについてです。異なるKubernetesクラスター間でも、別のPostgres Cluster リソースで複製する方法については、 レプリカクラスター
セクション。
アプリケーションレベルのレプリケーション¶
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）では、オリジンから宛先にデータをレプリケートするパブリッシャー/サブスクライバーパターンのネイティブサポートが導入されました。
ストリーミングレプリケーションのサポート¶
現時点では、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
hostssl replication streaming_replica all cert
ドキュメントに。
構成されている場合、オペレーターはHAクラスター内のすべてのレプリカのレプリケーションスロットを管理し、フェールオーバーまたはスイッチオーバー後でも、各スタンバイに必要なWALファイルがプライマリのストレージに保持されるようにします。
以下。
継続的バックアップ統合¶
クラスターで継続的バックアップが構成されている場合、CloudNativePGは、継続的リカバリ時にrestore_command
を利用するようにレプリカを透過的に構成します。その結果、PostgreSQLは、ストリーミングレプリケーションを介したWALのプルに失敗したときはいつでも、フォールバックオプションとしてWALアーカイブを使用できます。
同期レプリケーション¶
CloudNativePGは、 minSyncReplicas およびmaxSyncReplicas
と呼ばれる2つの構成オプションを介して、
クォーラムベースの同期ストリーミングレプリケーション
の構成をサポートします。これらは、いつでも使用可能な予想される同期スタンバイレプリカの最小数と最大数です。自己修復の目的で、オペレーターは常にこれら2つの値を使用可能なレプリカの数と比較して、クォーラムを判断します。
重要
デフォルトでは、同期レプリケーションは使用可能なすべてのレプリカの中から区別なく選択します。次のセクションで説明するように、 syncReplicaElectionConstraint オプションを使用してノードラベルを操作することにより、同期レプリカをスケジュールできるノードを制限できます。
同期レプリケーションはデフォルトで無効になっています（minSyncReplicas
およびmaxSyncReplicas は定義されていません）。 minSyncReplicas
とmaxSyncReplicas
の両方が設定されている場合、CloudNativePGはPostgreSQLのsynchronous_standby_names
オプションを次の値に自動的に更新します。
ANY q (pod1, pod2, ...)
そこで：
qは、オペレーターによって自動的に計算された整数です。1 <= minSyncReplicas <= q <= maxSyncReplicas <= readyReplicaspod1, pod2, ...は、クラスター内のすべてのPostgreSQL Podのリストです
警告
自己修復機能を提供するために、オペレーターは`minSyncReplicas` そのような値が現在利用可能なレプリカの数よりも大きい場合、無視できます。 readyReplicas が`0` の場合、同期レプリケーションは自動的に無効になります。
PostgreSQL documentation で述べられているように、
メソッド``ANY``はクォーラムベースの同期レプリケーションを指定し、WALレコードが少なくともリスト内の要求された数の同期スタンバイにレプリケートされるまでトランザクションコミットを待機させます 。
重要
オペレーターが同期レプリケーション設定の強制よりも自己修復を選択した場合でも、3つ以上のインスタンスを持つクラスターでのみ、より一般的には`maxSyncReplicas < (instances - 1)` の場合にのみ同期レプリケーションを計画することをお勧めします。
同期レプリケーションのノードを選択する¶
CloudNativePGを使用すると、 PGDATAを保持するPVCとPostgresポッドがあるノードラベルに基づいて、アンチアフィニティルールを介して、クォーラムベースの同期レプリケーションセットに参加する資格のあるPostgreSQLインスタンスを選択できます。
この機能のユースケースの例：
単一の同期レプリカを持つクラスターでは、通常
topology.kubernetes.io/zone label on a node
で識別されるプライマリインスタンスとは異なるアベイラビリティーゾーンに同期レプリカがあることを保証できます。これにより、特に目標復旧時点（RPO）の観点から、単一のアベイラビリティーゾーンで障害が発生した場合のクラスターの堅牢性が向上します。
アンチアフィニティーの考え方は、クォーラムに参加する同期レプリカが、選択されたラベル（この場合、アベイラビリティーゾーンラベル）とプライマリが現在あるノードの値が異なるノードで実行されているポッドから選択されるようにすることです実行中。このような基準に一致するノードがない場合、レプリカは同期レプリケーションの対象となります。
重要
自己修復の強制は、同期レプリカ選択の追加の制約を定義しているときにも適用されます（ 同期レプリケーションによるゼロデータ損失クラスター を参照）。
以下の例は、spec.postgresql
内のsyncReplicaElectionConstraint
セクションを介してこれを行う方法を示しています。
nodeLabelsAntiAffinity
を使用すると、評価する必要があるノードラベルを指定して、現在のプライマリと、プライマリがあるノード：
spec:
instances: 3
postgresql:
syncReplicaElectionConstraint:
enabled: true
nodeLabelsAntiAffinity:
- topology.kubernetes.io/zone
ご想像のとおり、アベイラビリティーゾーンは一例にすぎませんが、ストレージ、CPU、メモリなど、ノードを説明する他のラベルに基づいてこの動作をカスタマイズできます。
高可用性のためのレプリケーションスロット¶
9.4で導入されたネイティブのPostgreSQL機能であり、接続されているすべてのストリーミングレプリケーションクライアントがWALセグメントを受信するまでプライマリがWALセグメントを削除せず、プライマリが行を削除しないことを保証する自動化された方法を提供します。スタンバイは（一時的に）切断されます。
レプリケーションスロットは、それを作成したインスタンスにのみ存在し、PostgreSQLはスタンバイサーバーに複製しません。その結果、フェールオーバーまたはスイッチオーバーの後、新しいプライマリには古いプライマリのレプリケーションスロットが含まれません。これにより、古いプライマリに接続され、スロットを失ったストリーミングレプリケーションクライアントに問題が発生する可能性があります。
CloudNativePGは、高可用性クラスターから始めて、クラスター管理のレプリケーションスロットの概念を導入することにより、このギャップを埋めます。この機能は、プライマリとスタンバイの両方で、高可用性クラスター内の各ホットスタンバイレプリカの物理レプリケーションスロットを自動的に管理します。
CloudNativePGでは、次の用語を使用します。
プライマリHAスロット ：ライフサイクルがクラスターの現在のプライマリによって完全に管理され、ストリーミングレプリケーションで特定のスタンバイにマッピングすることを目的とする物理レプリケーションスロット。このようなスロットはプライマリにのみ存在します。
スタンバイHAスロット ：そのライフサイクルがクラスター内の別のスタンバイによって完全に管理され、プライマリの
pg_replication_slotsビューの内容に基づいて管理され、pg_replication_slot_advance()を使用して定期的に更新されるスタンバイの物理レプリケーションスロット。
CloudNativePG 1.18で導入されたこの機能は、デフォルトで有効になりました。構成で無効にできます。詳細は
を参照ください。以下に、主なオプションの簡単な説明を示します。
.spec.replicationSlots.highAvailability.enabled
：trueの場合、機能は有効になっています（true
がデフォルトです-1.20以降）
.spec.replicationSlots.highAvailability.slotPrefix
：この機能のオペレーターが管理するレプリケーションスロットを識別するプレフィックス（デフォルト：_cnpg_
）
.spec.replicationSlots.updateInterval
：スタンバイがレプリケーションスロットのローカルコピーの位置を秒単位で表される現在のプライマリ上の位置と同期する頻度（デフォルト：30）
重要
この機能は、 pg_replication_slot_advance() に依存しているため、PostgreSQL 11以降が必要です
レプリケーションスロットの位置を直接操作します。
警告
PostgreSQL 11では、最初に無効になっている場合にレプリケーションスロットを有効にしたり、逆に最初に有効になっている場合に無効にしたりすると、クラスターのローリング更新が必要になります（起動時にのみ読み取られる`recovery.conf` ファイルが存在するため）。
お勧めはしませんが、別の動作が必要な場合は、上記のオプションをカスタマイズできます。
たとえば、次のマニフェストは、レプリケーションスロットを有効にせずにクラスターを作成します。
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
次の例のように、スタンバイがプライマリの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:
highAvailability:
enabled: true
updateInterval: 300
storage:
size: 1Gi
レプリケーションスロットは、インフラストラクチャで注意深く監視する必要があります。デフォルトでは、Prometheusエクスポーターのpg_replication_slots
メトリックに、スロットの名前、タイプ、アクティブかどうか、プライマリからのラグなどのキー情報を提供します。
