Backup and recovery

PGDは、分散型の高可用性システムとして設計されています。クラスターの1つ以上のノードが失われた場合、それらを置き換える最善の方法は、残りのノードから新しいノードを直接複製することです。

PGDにおけるバックアップとリカバリの役割は、次のような状況でのディザスターリカバリー（DR）を提供することです。

  • クラスター内のすべてのノードの損失

  • データ破損、アプリケーションエラー、またはセキュリティ侵害の結果としての、複数のノードにわたる重大で訂正不能なデータ破損

バックアップ

pg_dump

pg_dumpは、通常はPGDで 論理バックアップ とも呼ばれます。

pg_dumpは、ローカルシーケンスとグローバルシーケンスの両方をローカルシーケンスであるかのようにダンプします。この動作は意図的なもので、PGDスキーマをダンプして他のPostgreSQLデータベースに移植できるようにするためのものです。これは、シーケンスの種類のメタデータがダンプ時に失われることを意味するため、復元により、復元時にすべてのシーケンスの種類が効果的にbdr.default_sequence_kind の値にリセットされます。

復元後のスクリプトを作成して、シーケンスごとに正確なシーケンスの種類をリセットするには、次のような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 でのみダンプをリロードできます。

テクニカルサポートは、PGDのバックアップと回復に物理バックアップ技術を使用することをお勧めします。

物理バックアップ

Barman などの標準のPostgreSQLソフトウェアを使用して、 EDB

Postgres分散クラスター内のノードの物理バックアップを取得できます。

PostgreSQLノードに適用される同じ手順を使用して、PGDノードの物理バックアップを実行できます。 PGDノードは、 BDR拡張機能を実行しているPostgreSQLノードです。

PostgreSQLバックアップテクニックをPGDに適用する際には、次の特定の点を考慮してください。

  • PGDは単一のデータベースのレベルで動作しますが、物理バックアップにはインスタンス内のすべてのデータベースが含まれます。データベースを計画して、簡単にバックアップと復元ができるようにします。

  • バックアップは1つのノードのみのコピーを作成します。最も単純なケースでは、すべてのノードにすべてのデータのコピーがあるため、1つのノードのみをバックアップしてすべてのデータをキャプチャする必要があります。ただし、その単一のコピーを含むサイトがダウンした場合、PGDの目標は達成されないため、最小はサイトごとに少なくとも1つのノードバックアップ（多数のコピーなど）です。

  • ただし、各ノードに複製されていないローカルデータがある場合、または複製セットの定義が複雑なため、すべてのノードがすべての複製セットにサブスクライブしない場合があります。このような場合、バックアップ計画には、レプリケートされていないローカルデータをバックアップする方法の計画と、各レプリケーションセットにサブスクライブする少なくとも1つのノードのバックアップも含める必要があります。

最終的な一貫性

EDB Postgres分散クラスター内のノードは 最終的に一貫性がある ですが、 完全に一貫性がある わけではありません。特定のノードの物理バックアップは、そのノードが実際に想定する状態に制限されたポイントインタイムリカバリ機能を提供します。

次の例は、同じEDB Postgres分散クラスター内の2つのノードがどのように同じ順序の状態を経ない（そして通常は経ない）かを示しています。

最初はS 状態である2つのノードN1 とN2 を持つクラスターを考えます。トランザクション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 までN2 に適用されません。

PostgreSQL PITRは、単一のマスターからCOMMITオーダーで変更が届くことを前提に設計されています。したがって、PITRは、特定の時点（PIT）に到達するまで変更をスキャンすることにより可能です。このスキームを使用すると、1つのノードをその観点から単一の時点に復元できます。たとえば、 T1 。ただし、その状態には、その時間近くにコミットされたがまだノードに到着していない他のノードからの他のデータは含まれません。その結果、リカバリーは部分的に一貫性がない、または少なくとも1つの複製起点についてのみ一貫していると考えられる場合があります。

これを要求するには、標準の構文を使用します。

recovery_target_time = T1

PGDは、複数のマスターからの変更を許可します。すべてが1つのノードのWALログに記録され、レプリケーションオリジン識別子を使用して個別に識別されます。

PGDは、特定の時点へのすべてまたは一部の複製起点のPITRを許可し、ノードのすべてのサブセットにわたって完全に一貫した視点を提供します。

したがって、マルチオリジンの場合、WALストリームは、複数のストリームがすべて1つの大きなストリームに混合されて含まれていると見ることができます。 PITはまだ1つしかありませんが、オリジンごとに異なるポイントとして到達します。

WALストリームは、要求されたオリジンがPITを見つけるまで読み取られます。オリジンのPITに到達した後、オリジンのコミット済みとしてマークされないトランザクションレコードを除いて、すべての変更はその時点までに適用されます。

WALには1つのLSN「ストップポイント」ができますが、シングルオリジンのPITRと同じように、1つのタイムスタンプが一貫して適用されます。

定義されたPITに達すると、必要に応じて、リカバリを続行できるように後のPITも設定される場合があります。

目的の停止ポイントに到達した後、回復したサーバーを昇格する場合は、最初にシャットダウンします。 pg_resetwal を使用して、このサーバー上のタイムラインで使用されるよりも高いLSN値にLSNを転送します。このアプローチにより、論理デコードによって生成された重複したLSNがないことが保証されます。

示されている特定の例では、 N1 はT1 に復元されます。また、後でまでN1 に適用されなかった場合でも、T1 によってコミットされた他のノードからの変更も含まれます。

マルチオリジンPITRを要求するには、 recovery.conf ファイルで標準構文を使用します。

recovery_target_time = T1

2つの方法のいずれかで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ノードと同じ手順で物理バックアップを作成できますが、PGDノードの物理バックアップを復元するのは少し複雑です。

EDB Postgres分散クラスターの障害またはバックアップからの新しいクラスターのシード

物理バックアップを復元する最も一般的なユースケースには、データセンターに障害が発生した場合など、クラスター内のすべてのPGDノードの障害または交換が含まれます。

この手順を実行して、 EDB Postgres分散クラスターの現在のコンテンツのクローンを作成し、QAまたは開発インスタンスをシードすることもできます。

その場合、単一のPGDノードの物理バックアップと、オプションでWALアーカイブに基づいて、PGD機能を復元できます。

  • まだいくつかのPGDノードがライブで実行されている場合は、PGDノードを復元したホストをフェンスオフして、生き残ったPGDノードに接続できないようにします。このプラクティスにより、新しいノードが既存のクラスターを混同しないようにします。

  • PGDノードの1つの物理バックアップから単一のPostgreSQLノードを復元します。

  • バックアップに関連付けられたWALアーカイブがある場合は、適切なrecovery.conf を作成し、PostgreSQLをリカバリで起動して、最新の状態まで再生します。必要に応じて、ここで代替のrecovery_target を指定できます。

  • 復元されたノードを起動するか、スタンバイリカバリの場合は読み取り/書き込みに昇格します。生き残ったノードからフェンスしたままにしてください！

  • 物理バックアップに含まれていた残りのPGDメタデータをクリーンアップします。

  • PostgreSQLインスタンスを完全に停止して再起動します。

  • bdr.join_node_group() 関数呼び出しに基づいた標準手順で、さらにPGDノードを追加します。

PGDメタデータのクリーンアップ

残ったPGDメタデータをクリーンアップするには：

  1. bdr.drop_node を使用してPGDノードを削除します。

  2. PostgreSQLを完全に停止して再起動します（重要！）。

複製起点のクリーンアップ

レプリケーションオリジンはシステムカタログに永続的に記録されるため、別の手順で明示的に削除する必要があります。したがって、それらはバックアップと復元されたインスタンスに含まれます。それらは依存関係として明示的に記録されないため、 BDR拡張機能を削除しても自動的に削除されません。

クラッシュセーフな方法で着信レプリケーションの進行状況を追跡するために、PGDはリモートマスターノードごとに1つのレプリケーションオリジンを作成します。したがって、前のクラスター内のノードごとに、これを1回実行します。

SELECT pg_replication_origin_drop(bdr_dbname_grpname_nodename);

次のようにレプリケーションオリジンをリストできます。

SELECT * FROM pg_replication_origin;

PGDによって作成されたものは、名前で簡単に認識できます。

レプリケーションスロットのクリーンアップ

pg_basebackup で物理バックアップが作成された場合、レプリケーションスロットはバックアップから省略されます。

他の一部のバックアップ方法では、古い状態または無効な状態である可能性が高いレプリケーションスロットを保持する場合があります。バックアップを復元したら、これを使用してすべてのレプリケーションスロットを削除します。

SELECT pg_drop_replication_slot(slot_name)
FROM pg_replication_slots;

いくつかのスロットを保持する理由がある場合は、 WHERE slot_name LIKE 'bdr%' 句を追加できますが、これが役立つことはめったにありません。

警告

ライブPGDノードでこれを実行しないでください。