Backup and Recovery

この章では、 BDRクラスターのバックアップと復元について説明します。

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

BDRでのバックアップとリカバリのロールは、次のような状況でDisasterRecovery（DR）を提供することです。

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

  • マルチプルのノード間での重大な修正不可能なデータ破損 データ破損、アプリケーションエラー、または セキュリティ違反

バックアップ

pg_dump

「ロジカルバックアップ」とも呼ばれるpg_dumpは、通常BDRで使用できます。

pg_dumpは、ローカルシーケンスであるかのようにローカルシーケンスとグローバルシーケンスの両方をダンプすることに注意してください。これは、 シーケンスをダンプして他の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のバックアップとリカバリに物理的バックアップ技術を使用することを推奨しています。

物理バックアップ

BDRクラスター内のノードの物理バックアップは、Barmanなどの標準のPostgreSQLソフトウェアを使用して取得できます。

BDRノードの物理的バックアップは、任意のPostgreSQLノードに適用される同じ手順で実行できノードは、BDRノードを実行する単なるPostgreSQLノードです。

PostgreSQLバックアップテクニックをBDRに適用する際に考慮しなければならない特定のポイントがいくつかあります。

BDRは単一のデータベースのレベルで動作しますが、物理的 バックアップには、インスタンス内のすべてのデータベースが含まれます。あなたが計画する必要があります データベースを簡単にバックアップおよび復元できるようにします。

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

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

最終的な一貫性

BDRクラスター内のノードは、最後には一貫性を持つがありますが、完全に一貫性があります。特定のノードの物理的バックアップは、そのノードが実際に想定する状態に限定されたポイントインタイムリカバリ機能を提供します（以下の[例]を参照）。

次の例は、同じBDRクラスター内の2つのノードが同じ状態シーケンスを通過しない（および通常は通過しない）方法を示しています。

N1とN2の2つのノードを持つクラスターを考えてみましょう。初期状態はSです。トランザクションW1がノードN1に適用され、同時に競合しないトランザクションW2がノードN2に適用される場合、ノードN1は次の状態になります。

(N1)   S  -->  S + W1  -->  S + W1 + W2

…一方、ノードN2は次の状態を通過します。

(N2)   S  -->  S + W2  -->  S + W1 + W2

つまり、ノードN1は状態S + W2を決して想定せず、ノードN2likewiseは決して状態S + W1を想定しませんが、両方のノードは同じ状態S + W1 + W2になります。このシチュエーションを考慮すると、バックアップ戦略の決定方法に影響する場合があります。

ポイントインタイムリカバリ（PITR）

上記の例では、W1とW2の両方がT1の時点で発生しますが、W1の変更はN2までN2に適用されないため、変更も時間的に一貫性がありません。

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

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

recovery_target_time = T1

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

BDRを使用すると、特定の時点までのすべてまたは一部のレプリケーション起点元のPITRが可能になり、ノードのすべてのサブセットにわたって完全に一貫した視点が提供されます。

したがって、マルチオリジンの場合、WALストリームには、すべてが1つの大きなストリームに混在た複数のストリームが含まれてビューと見なされます。まだ1つのPITしかありませんが、各オリジンに対して別々のポイントとして別々に到達します。

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

WALで1つのLSN「停止ポイント」になりますが、「単一オリジンPITR」と同様に、1つのシングルタイムスタンプも一貫して適用されます。

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

目的の停止ポイントに達した後、リカバリされたサーバーが昇格する場合は、まずシャットダウンして、pg_resetwalを使用してLSNをこのサーバーのタイムラインで使用されるよりも大きいLSN値に転送します。これにより、重複するLSNが生成されないようにします。論理デコードによって。

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

マルチオリジンPITRを要求するには、 リカバリ.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ファイルがない場合、リカバリはデフォルトで、シングルマスタからCOMMITオーダーで到着する変更を前提として設計されたオリジナルのPostgreSQL PITR動作になります。

!!! Note * これはEDB Postgres Extendedでのみ利用可能な機能であり、 Barmanは現在、multi_recovery.confファイルを自動的に作成しません。

復元

標準のPostgreSQLノードと同じプロシージャで物理的バックアップを作成できますが、もう少し複雑なのは、 BDRノードの物理的バックアップを復元することです。

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

物理的バックアップを復元するための最も一般的なユースケースには、たとえばデータセンターの障害がイベントしたインスタンス、クラスター内のすべてのBDRノードの障害または交換が含まれます。

このプロシージャを実行して、BDRクラスターの現在のコンテンツを複製し、QAまたは開発インスタンスをシードすることもできます。

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

  • まだいくつかのBDRノードが稼働している場合は、ホストを隔離します BDRノードを復元したため、残りのBDRノードに接続できません。 これにより、新しいノードが既存のクラスターを混乱させないようにします。

  • いずれかの物理的バックアップから単一のPostgreSQLノードを復元する BDRノード。

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

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

  • 物理的バックアップに含まれていた残りのBDRメタデータをクリーンアップし、 以下に説明します。 PostgreSQLインスタンスを完全に停止してリスタートします。

  • に基づいた標準プロシージャでさらにBDRノードを追加します bdr.join_node_group()ファンクション呼び出し。

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

残りのBDRメタデータのクリーニングは、次のように達成されます。

  1. を使用して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%'句を追加できますが、これはほとんど役に立ちません。

!!! Warning * ライブBDRノードでこれを実行しないでください。