AnalyticDB PostgreSQLは分散一貫性バックアップとリカバリの実装方法を教えます

1. 背景

AnalyticDB for PostgreSQL (略称 ADB PG) は、PostgreSQL カーネル (略称 PG) をベースに Alibaba Cloud データベース チームによって開発されたクラウドネイティブのデータ ウェアハウス製品です。 ADB PG には、リアルタイムのインタラクティブ データ分析、HTAP、ETL、BI レポート生成などのビジネス シナリオにおける独自の技術的利点があります。

エンタープライズ レベルのデータ ウェアハウス製品として、データ セキュリティの重要性は明らかです。バックアップとリカバリ機能は、データ セキュリティを確保するための基本的な手段であり、緊急事態に対応して ADB PG がデータベースをリカバリするための重要な保証でもあります。バックアップとリカバリは、その名前が示すように、問題が発生する前にそれを防ぐために、必要に応じてデータを復元できるようにデータベースをバックアップすることです。現在、ADB PG のバックアップおよび復元機能は、次のユーザー シナリオに適用されています。

システム障害や人為的ミスによりデータが破壊されたりインスタンスが利用できなくなったりした場合は、バックアップ データに基づいてインスタンスが復元されます。
ユーザーは、既存のインスタンスに基づいて同一のインスタンスをすばやく複製する必要があります。
ノード数は変更されないという前提で、ユーザーはソースインスタンスの仕様を変更する必要があります。
この記事では、ADB PG のバックアップとリカバリの原理と使用方法を紹介します。

II.導入

ADB PG は、MPP 水平拡張アーキテクチャを使用する分散データベースです。 ADB PG インスタンスは、1 つ以上の調整ノード (マスター) と複数のコンピューティング ノード (コンピューティング ノード) で構成されます。コーディネーションノードは、ユーザー要求を受信し、分散実行プランを策定してコンピューティングノードに送信し、実行結果を収集してクライアントに返す役割を担います。コンピューティング ノードは、並列コンピューティング分析とデータ ストレージを担当します。データは、コンピューティング ノード間でランダムに、ハッシュ化、または複製されて分散されます。次の図は、ADB PG のアーキテクチャを示しています。

ADB PG の物理バックアップおよびリカバリ機能は、クラスターの基本バックアップとログ バックアップに基づいています。分散データベースがサービスを提供し続け、データの一貫性を確保しながら、各ノードのデータをバックアップできます。必要に応じて、分散データベースをバックアップ時の状態に復元できます。

基本的なバックアップは、すべてのデータベース データの完全なコピーです。基本バックアップでは、クラスター データ全体のスナップショットが圧縮され、他のオフライン ストレージ メディアに保存されます。クラスターは、基本バックアップ中にユーザーの読み取りと書き込みをブロックしません。したがって、基本バックアップの整合性を確保するために、バックアップ中に生成されたログもバックアップされます。

ログ バックアップ (増分バックアップとも呼ばれます) とは、クラスターによって生成されたログ ファイルを他のオフライン ストレージ メディアにバックアップすることを指します。ログ ファイルには、データベースに対するユーザーの DML および DDL 操作が記録されます。完全な基本バックアップと継続的なログ バックアップにより、新しいクラスターを特定の履歴イベント ポイントに復元でき、この期間中のデータのセキュリティが確保されます。

ADB PG は、最小 10 分の RPO でバックアップとリカバリを保証します。

3. 原則

ADB PG のバックアップとリカバリの原理を完全に紹介する前に、まずスタンドアロン PG の PITR (Point in Time Recovery) バックアップとリカバリのメカニズムについて簡単に紹介します。 ADB PG のバックアップおよびリカバリ メカニズムは、スタンドアロン PG の PITR 原則に基づいており、分散データの一貫性保証メカニズムが追加されています。

1. スタンドアロンPGのPITRメカニズム

WAL ログ:

PostgreSQL データベースは、トランザクションによってデータに対して行われたすべての変更 (DDL、DML、およびその他の操作を含む) を WAL (Write Ahead Log) ログ ファイルに記録します。 WAL ログ ファイルは、無限に増加する追加専用ファイルと見なすことができます。 PG はログ データを固定サイズの複数のファイルに分割して保存します。トランザクションの各データ変更操作は WAL ファイルに追加され、一意の LSN 番号 (ログ シーケンス番号) が割り当てられます。トランザクションがコミットされると、WAL ログが永続的であることが保証されます。

これらのログ ファイルの目的は、WAL ログを「再生」してデータベースを復元し、データベースがクラッシュしたときには保持されなかったが、データベースを復元する必要があるときに対応するトランザクションがコミットされているデータを回復できるようにすることです。

復元ポイント:

WAL ログを使用すると、「再生」操作を実行できますが、いつ再生する必要があるのか​​という疑問が残ります。これを解決するには復元ポイントが必要です。

リカバリ ポイントは、ログの位置を示す WAL ログに書き込まれるマークに相当します。 PG はログを再生するときに、このマーク ポイントに到達したかどうかをチェックして、「再生」操作を停止するかどうかを決定します。

次の SQL ステートメントは、WAL ログ ファイルに t1 という名前のマーカー ポイントを作成できます。

 postgres=# select pg_create_restore_point( 't1' );ログ: 復元ポイント"t1"が0/2205780に作成されましたステートメント: select pg_create_restore_point( 't1' ); pg_create_restore_point ----------------------- 0/2205780(1 行)  

データベースが WAL ログを順番に再生するときに、現在のログにこのリカバリ ポイント名が含まれているかどうかを確認します。そうなった場合、再生は停止します。さらに、PG は、任意の指定された時点、トランザクション番号、LSN シーケンス番号などへのリカバリなどの操作もサポートします。

基本バックアップと増分バックアップ:

ベース バックアップは、データベース データの完全なコピーです。 pg_basebackup ツールを使用して、スタンドアロン PG の基本バックアップを実行できます。バックアップ データはローカルに保存することも、他のオフライン ストレージ メディア (OSS) に保存することもできます。

 $ pg_basebackup -D pg_data_dir/ -p 6000NOTICE: pg_stop_backupが完了しました。必要なWALセグメントがすべて削除されました。

増分バックアップとは、生成された WAL ログ ファイルをバックアップすることを指します。 PG では、データベース パラメータ archive_command を使用して、WAL ログ データをバックアップする方法を指定できます。 PG は WAL ログ ファイルを生成すると、archive_command コマンドを実行してログ ファイルをバックアップおよびアーカイブしようとします。たとえば、次のコマンドは、指定された OSS にログ ファイルを送信します。

archive_command="ossutil cp %p oss://bucket/path/%f"

スタンドアロンPGのフルバックアップと増分バックアップ

基本バックアップ中はデータベースの読み取りと書き込みはブロックされないため、リカバリ中のデータの一貫性を確保するために、バックアップ期間中のデータ更新に対応する WAL ログもバックアップする必要があることに注意してください。

PITR リカバリ:

データベースを復元する必要がある場合は、まず基本バックアップ データをダウンロードし、次に基本バックアップを使用してクラスターを起動し、ログ ファイル バックアップをダウンロードして、指定された回復ポイントまで「再生」してデータベースを復元します。スタンドアロン PG では、指定されたリカバリ ポイントのターゲットは、トランザクション番号、タイムスタンプ、WAL シーケンス番号 (LSN)、およびリカバリ ポイント名になります。

(II) ADB PGの分散一貫性バックアップおよびリカバリメカニズム

分散データベースである ADB PG は、2 フェーズ トランザクション コミットを使用して分散トランザクションを管理します。スタンドアロン PG の PITR メカニズムをコピーすると、データの不整合が発生します。たとえば、次のシナリオでは、分散トランザクションは A、B、C の順序で割り当てられます。ただし、さまざまな理由 (ネットワーク遅延、ノード負荷、明示的な送信など) により、分散モードでのトランザクションの送信順序は、次の図に示すように、各ノードで異なる場合があります。

マスターはA、B、Cの順に提出します
計算ノード1はA、C、Bの順に送信する。
計算ノード2はB、C、Aの順で送信する。

プロセス中にリカバリ ポイントが作成され、リカバリ中にそのリカバリ ポイントに復元するように指定した場合、リカバリ後にクラスター内のノードの状態が不整合になることは明らかです。

2 フェーズ トランザクション コミット ロックと一貫性回復ポイント:

上記の問題を解決するために、2 フェーズのトランザクション コミット ロックを導入しました。分散トランザクションのコミットは SHARED モードでロックを取得しますが、リカバリ ポイントを作成するには EXCLUSIVE モードでロックを取得する必要があります。したがって、クラスター内に各ノードでコミットされるのを待機している分散トランザクションがある場合、回復ポイントを作成するクラスターのアクションは、すべてのノードで分散トランザクションがコミットされるまで待機してから実行する必要があります。

これにより、分散トランザクションがコミットされている間にリカバリ ポイントが作成され、リカバリ中にデータの不整合が発生するという上記の問題が根本的に解決されます。 2 フェーズ コミット ロック メカニズムが導入されると、作成されたリカバリ ポイントに対応する各ノードの状態が一貫していることを確認できます。したがって、ADB PG で作成されたリカバリ ポイントを一貫性のあるリカバリ ポイントと呼びます。

分散バックアップおよびリカバリプロセス:

トランザクション コミット ロックと一貫性のあるリカバリ ポイントを使用すると、不整合なノード ステータスを心配することなく、各 ADB PG ノードを安全にバックアップし、一貫性のあるリカバリ ポイントを作成できます。

ADB PG バックアップは、基本バックアップとログ バックアップ (増分バックアップとも呼ばれます) に分けられます。基本的なバックアップは、クラスター内の各ノードの完全なコピーです。 ADB PG は、コンピューティング ノードとコーディネーション ノードを同時にバックアップし、バックアップ データをオフライン ストレージ (OSS など) にストリーミングします。ベース バックアップ中は、クラスターの読み取りおよび書き込みサービスはブロックされません。したがって、基本バックアップ中にユーザーがデータを書き込んだり更新したりした場合は、データの変更に対応する WAL ログもバックアップする必要があります。次の図に示すように、ADB PG は各ノードのデータを並列にコピーし、ストリーミング方式で OSS にデータをアップロードします。

ADB PG の基本的なバックアッププロセス

ADB PG のログ バックアップは、クラスター内のコンピューティング ノードとコーディネーション ノードによって生成された WAL ログのバックアップです。各ノードは、生成した WAL ログをオフライン ストレージ (OSS など) にダンプします。同時に、クラスターは定期的に一貫性回復ポイントを作成し、一貫性回復ポイントを含む WAL ログをバックアップします。

新しいクラスターを復元する必要がある場合は、ベース バックアップとログ バックアップの両方を使用し、最初に元のインスタンスと同じ数のノードを持つリカバリ インスタンスを作成する必要があります。各ノードは、指定された基本バックアップをローカル コンピューターに並行して取得します。その後、各ノードは必要な WAL ログ バックアップ ファイルを取得し、指定された一貫性回復ポイントで停止するまでローカルで再生します。最後に、新しいクラスターを取得し、整合性回復ポイントでのデータとステータスがソースインスタンスのデータとステータスと一致していることを確認できます。回復プロセスを次の図に示します。

IV.使用

（１）コンソールバックアップ関連情報

基本バックアップ セットを表示する ユーザーは、インスタンス コンソールの [バックアップと復元] ページで、データベースの基本バックアップ データを表示できます。現在、基本的なバックアップデータは OSS に保存されており、デフォルトの保存期間は 7 日間です。

テーブルの各行は基本的なバックアップ データを表し、バックアップの開始時刻、終了時刻、バックアップ ステータス (成功/失敗)、バックアップ データ サイズ、一貫性の時点を記録します。一貫した時点とは、この基本バックアップ データによってクラスターをその履歴時点に復元し、データベースを一貫した状態にできることを意味します。

一貫性のあるリカバリポイントの表示

一貫性のあるリカバリ ポイントとは、クラスターを復元できる履歴上の時点を指します。ユーザーは、バックアップとリカバリ ページの「リカバリ ポイント」ページで、現在のインスタンスのすべてのリカバリ ポイントを表示できます。

テーブルの各行は、一貫性のあるリカバリ ポイントを表し、リカバリ ポイントのタイムスタンプを記録します。これは、リカバリ ポイントによってクラスターをこの履歴時点に復元できることを示します。

ログファイルリストを表示する

ログ ファイルには、データベースへのすべての変更が記録されます。クラスターが復元されると、対応するログ ファイルを使用してクラスターが一貫した状態に復元されます。現在、ユーザー クラスタのリカバリに関するログ ファイルは OSS に保存されています。ユーザーは、バックアップと復元ページの「ログ バックアップ」でログ ファイル リストを表示できます。

バックアップポリシーを表示

バックアップ戦略とは、インスタンス バックアップのサイクルと期間、一貫性のあるリカバリ ポイントを作成する頻度、データ バックアップの保持日数などを指します。

ユーザーは、バックアップとリカバリのバックアップ設定でバックアップ ポリシーを表示および変更できます。

バックアップポリシーを変更する

バックアップ戦略を変更するには、「バックアップ構成の変更」ボタンをクリックします。

（２）インスタンスリカバリ手順

まず、ソースインスタンスのデータを表示します

回復ページに入る

ユーザーは、コンソールのインスタンス リスト、データ バックアップ リスト、またはリカバリ ポイント リストで [復元] をクリックして、インスタンスのリカバリ ページに入ることができます。

回復ページは次のとおりです。

インスタンスを復元するための販売ページはインスタンスを購入するためのページと似ていますが、次の制限があります。

1. 現在のリカバリインスタンスはマスター番号であり、1を選択する必要があります。

2. 選択したインスタンスセグメント（コンピュータノード）の数は、ソースインスタンスと一致している必要があります。

3. 選択したインスタンスのストレージ容量は、ソースインスタンスの容量以上である必要があります。

回復時点を選択します。リカバリ ページの [クローン ソース バックアップ セット] のドロップダウン リストで、インスタンスを復元する履歴ポイントを選択します (つまり、一貫性のあるリカバリ ポイントを指定します)。

クリックして購入

ユーザーが「購入」をクリックした後のプロセスは、新しいインスタンスを購入する場合と同じです。インスタンスが作成された後、ユーザーはそれが作成されるまで待機する必要があります。その後、新しく復元されたインスタンスがコンソールに表示されます。

新しいインスタンスを復元しました

復元されたインスタンスのデータを確認すると、データがソースインスタンスとまったく同じであることがわかります。

V. 結論

バックアップとリカバリは、ADB PG にとって、データ セキュリティを確保する上で非常に重要です。現在のバックアップおよびリカバリ機能は、複数のユーザー シナリオに適用されており、少なくとも 10 分の RPO を保証します。今後も、ADB PG バックアップおよびリカバリ機能は、バックアップおよびリカバリのパフォーマンスを最適化し、差別化されたバックアップをサポートし、より多くのストレージ メディアをサポートし、ユーザー エクスペリエンスを向上させ、より多くの機能、パフォーマンス、コストの最適化をユーザーに提供していきます。