バックアップおよび復元
グラフのバックアップと復元(GBAR)は、TigerGraphインスタンスまたはクラスターのデータとデータディクショナリー(スキーマ、読み込んだジョブ、クエリ)をバックアップおよび復元するための統合されたツールです。
バックアップ機能は、TigerGraphデータと設定情報をローカルディスクまたはリモートのAWS S3バケットのディレクトリーに保存します。複数のバックアップファイルをアーカイブでき、後で復元機能を使用して、システムを任意のバックアップポイントにロールバックできます。このツールは、Linux cronと簡単に統合することができ、これにより定期的なバックアップジョブを実行することもできます。
シンタックス
|
GBARの現在のバージョンは、バックアップが行われた同マシンを復元することを目的としています。データベースのクローン作成(つまり、マシンAのバックアップおよびマシンBへのデータベースの復元)については、support@tigergraph.comまでお問い合わせください。 |
Usage: gbar backup [options] -t <backup_tag>
gbar restore [options] <backup_tag>
gbar list [backup_tag] [-j]
gbar remove|rm <backup_tag>
gbar cleanup
gbar expand [-a] <new_nodes>
新しいノードはコンマで区切られた<name>:<host>のペアで記述する必要があります
例:
m1:192.168.1.2,m2:192.168.1.3,m3:192.168.1.4
オプション:
-h, --help このヘルプメッセージを表示して終了
-v デバッグ情報をダンプして実行
-vv 詳細なデバッグ情報をダンプして実行
-y プロンプトなしで実行
-j リストをJSONとして出力
-t BACKUP_TAG バックアップファイルのタグ(バックアップに必要)
-a, --advanced ノード拡張の詳細モードを有効化-y オプションを選択すると、GBARはインタラクティブなプロンプト質問をスキップします。その際、デフォルトの回答が選択されます。現在、インタラクティブな質問は1つあります。
-
GBARでは復元の開始時に、TigerGraphサービスを停止およびリセットしてもよいかどうかの質問が行われます。デフォルトの答えはyesです。
GBARの設定
バックアップまたは復元機能を使用する前に、GBARの設定を行う必要があります。
-
gadmin config entry system.backupを実行します。プロンプトが表示されますので、それぞれの設定パラメーターに適切な値を入力します。$ gadmin config entry system.backup System.Backup.TimeoutSec [ 18000 ]: バックアップのタイムアウト時間(秒) New: 18000 System.Backup.CompressProcessNumber [ 8 ]: バックアップ中の圧縮の同時プロセス数 New: 8 System.Backup.Local.Enable [ true ]: ローカルパスへのバックアップデータ New: true System.Backup.Local.Path [ /tmp/backup ]: バックアップファイル保存のためのパス New: /data/backup System.Backup.S3.Enable [ false ]: S3パスへのデータのバックアップ New: false System.Backup.S3.AWSAccessKeyID [ <masked> ]: バックアップファイル保存のためのパス New: System.Backup.S3.AWSSecretAccessKey [ <masked> ]: バックアップファイル保存のためのパス New: System.Backup.S3.BucketName [ ]: バックアップファイル保存のためのパス New: -
設定値を入力した後、次のコマンドを実行して新しい設定を適用します
gadmin config apply -y
|
バックアップの実行
バックアップを行うには、TigerSGraph Linuxユーザーとして、次のコマンドを実行します
gbar backup -t <backup_tag>行った設定に応じて、バックアップアーカイブはローカルバックアップパスやAWS S3バケットに出力されます。クラスターを実行している場合、同じパス内のすべてのノードにバックアップアーカイブがあります。
バックアップアーカイブは、ひとつのファイルとしてではなく、フォルダー内の複数のファイルとして保存されます。バックアップタグは、アーカイブファイル名のファイル名プレフィックスとなります。バックアップアーカイブのフルネームは <backup_tag>-<timestamp> となります。これはバックアップリポジトリーのサブフォルダーです。
-
System.Backup.Local.Enableがtrueに設定されている場合、クラスター内のノード間での大量のデータの移動を防ぐため、フォルダーはクラスター内のすべてのノード上のローカルフォルダーとなります。 -
System.Backup.S3.Enableがtrueに設定されている場合、すべてのノードにおいて、その中にあるデータはS3リポジトリーにアップロードされます。したがって、クラスター内のすべてのノードはAmazon S3へのアクセスが必要です。
GBARバックアップはライブバックアップを実行します。つまり、バックアップの進行中も通常の操作を続行できます。GBARバックアップが開始されると、GBARは実行中の読み込みジョブがあるかどうかを確認します。存在する場合は、1分間ロードを一時停止して、スナップショットを作成し、バックアッププロセスを続行します。ロードの一時停止の間隔は、環境変数 PAUSE_LOADING で指定できます。
次に、GBARは管理サーバーにリクエストを送り、GPEとGSEにデータのスナップショットを作成するよう要求します。これに応じてGPEとGSEは、GBARの作業ディレクトリーにデータを保存します。またGBARは、ディクショナリーに直接接続し、システム設定情報のダンプを取得します。GBARはさらに、TigerGraphシステムのバージョンとカスタマイズされた情報(ユーザー定義関数、トークン関数、スキーマレイアウト、ユーザーがアップロードしたアイコンなど)を収集します。次に、これらの各データおよび設定情報ファイルはtgz形式で圧縮され、各ノードの <backup_tag>-<timestamp> サブフォルダーに保存されます。最後に、GBARはそのファイルを、設定に従ってローカルストレージまたはAWS S3にコピーし、バックアップ中に生成されたすべての一時ファイルを削除します。
GBARバックアップの現在のバージョンは、スナップショットを迅速に取得することで、すべてのコンポーネント(GPE、GSE、およびディクショナリー)をできる限り一貫性のある状態になるようにしていますが、その一貫性を完全に保証するものではありません。
|
バックアップでは、REST++またはKafkaの入力メッセージキューの保存はできません。 |
バックアップファイルの一覧表示
gbar listこのコマンドによって、ユーザーが設定した保管場所に生成されたすべてのバックアップファイルを一覧表示できます。ファイルごとに、ファイルの完全なタグ、人間が読める形式のサイズ、および作成時間が表示されます。
バックアップファイルアーカイブからの復元
バックアップを復元する前に、復元に使うバックアップのバージョンが、現在お使いのTigerGraphのバージョンと完全に同じバージョンであることを確認する必要があります。
バックアップを復元するには、次のコマンドを実行します。
gbar restore <archive_name>バックアップアーカイブが存在し、バックアップのシステムバージョンが現在のシステムバージョンと互換性があることを確認できた場合、GBARはTigerGraphサーバーを一時的にシャットダウンし、バックアップを復元します。復元が完了すると、TigerGraphサーバーは再起動されます。 クラスターを実行していて、バックアップファイルをクラスター内の各ノードにコピーした場合、任意のノードで gbar restore を実行すると、クラスター全体が復元されます。
復元はオフラインで行われるため、データサービスを一時的にシャットダウンする必要があります。復元する完全なアーカイブ名( <backup_tag>-<timestamp> )を指定してください。GBARが復元を開始すると、まずはコマンドラインで指定されたアーカイブ名と完全に一致するバックアップアーカイブを探します。次に、バックアップファイルを作業ディレクトリーに解凍します。その後、バックアップアーカイブ内のTigerGraphシステムのバージョンを現在のシステムのバージョンの比較が行われ、バックアップアーカイブが現在のシステムと互換性があることが確認されます。その後に、TigerGraphサーバー(GSE、RESTPPなど)が一時的にシャットダウンされます。次に、予防措置として、現在のグラフデータのコピーが作成されます。GBARはバックアップグラフデータをGPEおよびGSEにコピーし、ディクショナリーに設定データを読み込むように通知します。また、バックアップユーザーデータを読み込むようGSTに通知し、バックアップされたユーザー定義のトークン/関数を適切な場所にコピーします。これらのアクションがすべて完了した後、GBARはTigerGraphサーバーを再起動します。
| GBARによる復元では、非圧縮データサイズを推定せず、十分なディスク容量があるかどうかを確認します。 |
|
GBARの主な目的は、TigerGraphシステムのデータ設定のスナップショットを保存することです。これにより、同じシステムを、保存された状態のうちの1つにロールバック(復元)することができます。 バックアップと復元が同じマシンで実行され、TigerGraphソフトウェアのファイル構造が変更されていないことが重要な前提となります。 |
|
復元には、古いgstoreと復元するgstoreの両方を収めるのに十分な空き容量が必要です。 |
バックアップの消去
バックアップを消去するには、 gbar remove コマンドを実行します。
$ gbar remove <backup_tag>このコマンドは、バックアップストレージパスからのバックアップの消去を行います。バックアップのタグを取得するには、 gbarlist コマンドを使用できます。
GBARの詳細例
次に、グラフデータのセットの実際の例を示し、コマンド、期待される出力、所要時間とディスク容量について説明します。この例では、Amazon EC2インスタンスおよび次の設定が使用されています。
32 vCPU + 244GBメモリ+ 2TB HDDのシングルインスタンス。
バックアップや復元の所要時間は、使用するハードウェアによって異なります。
GBARバックアップ作業詳細
毎日バックアップを実行するには、タグ名 daily でGBARにバックアップ指示を入れます。
$ gbar backup -t daily
[23:21:46] Retrieve TigerGraph system configuration
[23:21:51] Start workgroup
[23:21:59] Snapshot GPE/GSE data
[23:33:50] Snapshot DICT data
[23:33:50] Calc checksum
[23:37:19] Compress backup data
[23:46:43] Pack backup data
[23:53:18] Put archive daily-20180607232159 to repo-local
[23:53:19] Terminate workgroup
Backup to daily-20180607232159 finished in 31m33s.バックアッププロセス全体には約31分かかり、生成されたアーカイブは約49GBです。GPEデータ、GSEデータをディスクにダンプするのに12分かかり、ファイルの圧縮にはさらに20分かかっています。
GBAR復元作業詳細
バックアップアーカイブから復元を行うには、「 daily-20180607232159 」のように、完全なアーカイブ名を指定する必要があります。デフォルトでは、復元を行う際、ユーザーは続行の承認を求められます。これらのアクションを事前に承認する場合は、「-y」オプションを使用すると、GBARがデフォルトの選択を行います。
$ gbar restore daily-20180607232159
[23:57:06] Retrieve TigerGraph system configuration
GBAR restore needs to reset TigerGraph system.
Do you want to continue?(y/N):y
[23:57:13] Start workgroup
[23:57:22] Pull archive daily-20180607232159, round #1
[23:57:57] Pull archive daily-20180607232159, round #2
[00:01:00] Pull archive daily-20180607232159, round #3
[00:01:00] Unpack cluster data
[00:06:39] Decompress backup data
[00:17:32] Verify checksum
[00:18:30] gadmin stop gpe gse
[00:18:36] Snapshot DICT data
[00:18:36] Restore cluster data
[00:18:36] Restore DICT data
[00:18:36] gadmin reset
[00:19:16] gadmin start
[00:19:41] reinstall GSQL queries
[00:19:42] recompiling loading jobs
[00:20:01] Terminate workgroup
Restore from daily-20180607232159 finished in 22m55s.
Old gstore data saved under /home/tigergraph/tigergraph/gstore with suffix -20180608001836, you need to remove them manually.このテストでは、GBARの復元に約23分かかりました。ほとんどの時間(20分)は、バックアップアーカイブの解凍に費やされています。
復元が完了すると、GBARは復元前のグラフデータ(gstore)が保存されたことを通知します。復元が成功したことを確認したら、ディスク領域を空けるために古いgstoreファイルを削除と良いでしょう。