Backup and recovery¶
この章では、 EDB Postgres分散クラスターのバックアップと復元について説明します。
BDRは、分散型の高可用性システムとして設計されています。クラスターの1つ以上のノードが失われた場合、それらを置き換える最良の方法は、残りのノードから直接新しいノードのクローンを作成することです。
BDRのバックアップとリカバリの役割は、次のような状況でディザスターリカバリー（DR）を提供することです。
クラスター内のすべてのノードの損失
データ破損、アプリケーションエラー、またはセキュリティ違反の結果としての、複数のノードにわたる重大な訂正不能なデータ破損
バックアップ¶
pg_dump¶
pg_dump は、「論理バックアップ」とも呼ばれ、
BDRで正常に使用できます。
pg_dump
は、ローカルシーケンスとグローバルシーケンスの両方をローカルシーケンスであるかのようにダンプすることに注意してください。これは意図的なもので、
BDRスキーマをダンプして他のPostgreSQLデータベースに移植できるようにします。これは、ダンプ時にシーケンスの種類のメタデータが失われることを意味するため、復元すると、復元時にすべてのシーケンスの種類が効果的にリセットされます。
各シーケンスの正確なシーケンスの種類をリセットする復元後のスクリプトを作成するには、次のようなSQLスクリプトを使用できます。
SELECT SELECT bdr.alter_sequence_set_kind(||
nspname||.||relname||,||seqkind||);
FROM bdr.sequences
WHERE seqkind != local;
pg_dump がbdr.crdt_raw_value = on
を使用して実行されている場合、ダンプはbdr.crdt_raw_value = on
でのみリロードできることに注意してください。
テクニカルサポートは、 BDRのバックアップと復元に物理バックアップ技術を使用することをお勧めします。
物理バックアップ¶
EDB Postgres分散クラスター内のノードの物理バックアップは、 Barman などの標準のPostgreSQLソフトウェアを使用して取得できます。
BDRノードの物理バックアップは、PostgreSQLノードに適用されるのと同じ手順で実行できますBDRBDR機能を実行するPostgreSQLノードです。
PostgreSQLのバックアップ技術をBDRに適用する際に考慮しなければならない特定のポイントがいくつかあります。
BDRは単一のデータベースのレベルで動作しますが、物理バックアップにはインスタンス内のすべてのデータベースが含まれます。簡単にバックアップと復元ができるようにデータベースを計画する必要があります。
バックアップは1つのノードのみのコピーを作成します。最も単純な場合、すべてのノードにすべてのデータのコピーがあるため、1つのノードのみをバックアップしてすべてのデータをキャプチャする必要があります。ただし、その単一のコピーを含むサイトがダウンした場合、 BDRの目標は達成されないため、最小はサイトごとに少なくとも1つのノードのバックアップにする必要があります（明らかに多数のコピーなど）。
ただし、各ノードには複製されていないローカルデータがある場合、および/または複製セットの定義が複雑なため、すべてのノードがすべての複製セットにサブスクライブしない場合があります。このような場合、バックアップ計画には、レプリケートされていないローカルデータをバックアップする方法と、各レプリケーションセットにサブスクライブするノードのバックアップも含める必要があります。
最終的な一貫性¶
EDB Postgres分散クラスター内のノードは最終的に一貫性がありますが、完全に一貫性ではありません。特定のノードの物理バックアップは、そのノードが実際に想定する状態に制限されたポイントインタイムリカバリ機能を提供します（以下の[例]を参照）。
次の例は、同じEDB Postgres分散クラスター内の2つのノードが同じ一連の状態を経ない場合がある（そして通常は経ない場合がある）方法を示しています。
2つのノード N1 とN2 を持つクラスターを考えます。最初はS
状態です。トランザクションW1 がノードN1
に適用され、同時に非競合のトランザクションW2 がノードN2
に適用された場合、ノードN1 は次の状態になります。
(N1) S --> S + W1 --> S + W1 + W2
…一方、ノードN2 は次の状態になります。
(N2) S --> S + W2 --> S + W1 + W2
つまり、ノードN1 は状態S + W2
を決して想定し、ノードN2 も同様に状態S + W1
を想定しませんが、両方のノードは同じ状態S + W1 + W2
になります。この状況を考慮すると、バックアップ戦略を決定する方法に影響を与える可能性があります。
ポイントインタイムリカバリー（PITR）¶
上記の例では、 W1 とW2 は両方ともT1
に発生しますが、W1 の変更はT2 まで適用されません。
PostgreSQL
PITRは、単一のマスターからCOMMITオーダーで変更が届くことを前提に設計されています。したがって、PITRは、1つの特定の時点（PIT）に到達するまで変更をスキャンするだけで可能です。このスキームを使用すると、1つのノードをその観点から単一のポイントインタイムに復元できます。
T1
ですが、その状態には、その時間近くにコミットされたがまだノードに到着していない他のノードからの他のデータは含まれません。その結果、リカバリーは部分的に一貫性がない、または少なくとも1つの複製起点についてのみ一貫していると考えられる場合があります。
これを要求するには、標準の構文を使用します。
recovery_target_time = T1
BDRは、複数のマスターからの変更を許可します。すべてが1つのノードのWALログ内に記録され、レプリケーションオリジン識別子を使用して個別に識別されます。
BDRは、すべてまたは一部のレプリケーション起点のPITRを特定の時点に許可し、ノードのすべてのサブセットにわたって完全に一貫した視点を提供します。
したがって、マルチオリジンの場合、WALストリームは複数のストリームがすべて1つの大きなストリームに混合されていると見なします。 PITはまだ1つだけですが、それはオリジンごとに異なるポイントとして到達されます。
要求されたオリジンがPITを見つけるまでWALストリームを読み取ります。オリジンのPITに到達した後、オリジンのトランザクションレコードをコミット済みとしてマークしないことを除き、その時点までのすべての変更を適用します。
WALでは1つのLSN「ストップポイント」になりますが、「単一オリジンPITR」の場合と同様に、単一のタイムスタンプが一貫して適用されます。
定義されたPITに達したら、必要に応じて、リカバリを続行できるように後のPITを設定することもできます。
目的の停止ポイントに到達した後、回復したサーバーを昇格させる場合は、最初にシャットダウンし、
pg_resetwal
を使用して、このサーバーのタイムラインで使用されているよりも高いLSN値に移動します。これにより、論理デコードによって生成されたLSNが重複しないことが保証されます。
上記の特定の例では、 N1 はT1 に復元されますが、T1
によってコミットされた他のノードからの変更も含まれます。
マルチオリジンPITRを要求するには、recovery.confファイルで標準の構文を使用します。
recovery_target_time = T1
T1
に復元されるレプリケーション起点のリストは、新しいパラメーターrecovery_target_origins
を使用して、別のmulti_recovery.confファイルで指定する必要があります。
recovery_target_origins = *
…または、元のサブセットをrecovery_target_origins
のリストとして指定できます。
recovery_target_origins = 1,3
指定されたrecovery_target_time
へのローカルWALアクティビティのリカバリは常に暗黙的に実行されることに注意してください。
recovery_target_origins で指定されていないオリジンの場合、
recovery_target_origins
に記載されているリストのターゲットが達成される時期に応じて、回復は任意の時点で停止する場合があります。
multi_recovery.conf
ファイルが存在しない場合、リカバリはデフォルトで元のPostgreSQL
PITRの動作になります。これは、変更が単一のマスターからCOMMITオーダーで到着することを想定して設計されています。
注釈
この機能はEDB Postgres Extendedでのみ利用でき、 Barmanは現在`multi_recovery.conf` ファイルを自動的に作成しません。
復元する¶
標準のPostgreSQLノードと同じ手順で物理バックアップを作成できますが、少し複雑なのはBDRノードの物理バックアップを**復元することです。
EDB Postgres分散クラスターの障害またはバックアップからの新しいクラスターのシード¶
物理バックアップを復元する最も一般的なユースケースには、データセンターに障害が発生した場合など、クラスター内のすべてのBDRノードの障害または交換が含まれます。
この手順を実行して、 EDB Postgres分散クラスターの現在のコンテンツのクローンを作成して、QAまたは開発インスタンスをシードすることもできます。
その場合、 BDR機能は、単一のBDRノード、オプションでWALアーカイブの物理バックアップに基づいて復元できます。
まだいくつかのBDRノードが稼働している場合は、 BDRノードを復元したホストをフェンスオフして、残っているBDRノードに接続できないようにします。これにより、新しいノードが既存のクラスターを混同しないようにします。
BDRノードの1つの物理バックアップから単一のPostgreSQLノードを復元します。
バックアップに関連付けられたWALアーカイブがある場合は、適切な
recovery.confを作成し、PostgreSQLをリカバリで起動して最新の状態まで再生します。必要に応じて、ここで代替のrecovery_targetを指定できます。復元されたノードを起動するか、スタンバイリカバリの場合は読み取り/書き込みにプロモートします。生き残ったノードからフェンスしたままにしてください！
以下に説明するように、物理バックアップに含まれる残りのBDRメタデータをクリーンアップします。
PostgreSQLインスタンスを完全に停止して再起動します。
bdr.join_node_group()ファンクションコールに基づいた標準の手順で、さらにBDRノードを追加します。
BDRメタデータのクリーンアップ¶
残りのBDRメタデータのクリーニングは、次のように実行されます。
bdr.drop_nodeを使用してBDRノードを削除しますPostgreSQLを完全に停止してから再起動します（重要！）。
レプリケーションオリジンのクリーンアップ¶
レプリケーション元はシステムカタログに永続的に記録され、バックアップと復元されたインスタンスに含まれるため、別の手順で明示的に削除する必要があります。これらは依存関係として明示的に記録されないため、 BDR拡張機能を削除しても自動的に削除されません。
BDRは、リモートマスターノードごとに1つのレプリケーションオリジンを作成して、クラッシュセーフな方法で着信レプリケーションの進行状況を追跡します。したがって、次を実行する必要があります。
SELECT pg_replication_origin_drop(bdr_dbname_grpname_nodename);
…（前の）クラスター内のノードごとに1回。レプリケーションオリジンは次のようにリストできます。
SELECT * FROM pg_replication_origin;
…そして、 BDRによって作成されたものは、上の例のように名前で簡単に認識されます。
レプリケーションスロットのクリーンアップ¶
pg_basebackup
で物理バックアップが作成された場合、レプリケーションスロットはバックアップから省略されます。
他の一部のバックアップ方法では、レプリケーションスロットが古いまたは無効な状態である可能性があります。バックアップを復元したら、次のようにします。
SELECT pg_drop_replication_slot(slot_name)
FROM pg_replication_slots;
…すべてのレプリケーションスロットをドロップします。一部を保持する理由がある場合は、
WHERE slot_name LIKE 'bdr%'
句を追加できますが、これが役立つことはほとんどありません。
警告
ライブBDRノードでこれを実行しないでください。
