TiDB Self-Managed
Learning Center
お問い合わせ

BR を使用してクラスタデータを復元する

このドキュメントでは、次のシナリオで BR を使用してクラスター データを復元する方法について説明します。

バックアップと復元 (BR) に慣れていない場合は、次のドキュメントを読んで、BR の使用原理と方法を完全に理解することをお勧めします。

TiDB クラスターのスナップショットを復元する

BR は、空のクラスターでのスナップショット バックアップの復元をサポートし、スナップショットのバックアップ時にターゲット クラスターを最新の状態に復元します。

例: Amazon S3 のbackup-dataバケットの2022-01-30/ディレクトリから2022-01-30 07:42:23で生成されたスナップショットをターゲット クラスタに復元します。

br restore full \
    --pd "${PDIP}:2379" \
    --storage "s3://backup-data/2022-01-30/" \
    --ratelimit 128 \
    --log-file restorefull.log

前のコマンドでは、

  • --ratelimit :各 TiKVが復元タスクを実行する最大速度 (単位: MiB/s)
  • --log-file BR ロギングの対象ファイル

復元中は、以下に示すように、進行状況バーがターミナルに表示されます。プログレス バーが 100% まで進むと、復元は完了です。データのセキュリティを確保するために、BR は復元されたデータに対してチェックを実行します。

br restore full \
    --pd "${PDIP}:2379" \
    --storage "s3://backup-data/2022-01-30/" \
    --ratelimit 128 \
    --log-file restorefull.log
Full Restore <---------/...............................................> 17.12%.

データベースまたはテーブルを復元する

BR は、指定されたデータベースまたはテーブルの部分データをバックアップ データから復元することをサポートします。この機能を使用すると、不要なデータを除外して、特定のデータベースまたはテーブルのみをバックアップできます。

データベースを復元する

データベースをクラスターに復元するには、 br restore dbコマンドを実行します。このコマンドのヘルプを表示するには、 br restore db --helpコマンドを実行します。

例: Amazon S3 のbackup-dataバケットのdb-test/2022-01-30/ディレクトリからtestデータベースをターゲット クラスタに復元します。

br restore db \
    --pd "${PDIP}:2379" \
    --db "test" \
    --ratelimit 128 \
    --storage "s3://backup-data/db-test/2022-01-30/" \
    --log-file restore_db.log

上記のコマンドで、 --dbは復元するデータベースの名前を指定し、その他のパラメーターはTiDB クラスターのスナップショットを復元すると同じです。

ノート：

バックアップデータを復元する場合、 --dbで指定したデータベース名は、バックアップコマンドの-- dbで指定したデータベース名と同じでなければなりません。そうしないと、復元は失敗します。これは、バックアップ データのメタファイル ( backupmetaファイル) にデータベース名が記録されており、同じ名前のデータベースにしかデータを復元できないためです。推奨される方法は、バックアップ データを別のクラスター内の同じ名前のデータベースに復元することです。

テーブルを復元する

1 つのテーブルをクラスターに復元するには、 br restore tableコマンドを実行します。このコマンドのヘルプを表示するには、 br restore table --helpコマンドを実行します。

例: testを復元します。 usertable Amazon S3 のbackup-dataバケット内のtable-db-usertable/2022-01-30/ディレクトリからターゲット クラスタへ。

br restore table \
    --pd "${PDIP}:2379" \
    --db "test" \
    --table "usertable" \
    --ratelimit 128 \
    --storage "s3://backup-data/table-db-usertable/2022-01-30/" \
    --log-file restore_table.log

上記のコマンドで、 --tableは復元するテーブルの名前を指定し、その他のパラメーターはTiDB クラスターのスナップショットを復元すると同じです。

テーブル フィルターを使用して複数のテーブルを復元する

複数の基準で複数のテーブルを復元するには、 br restore fullコマンドを実行し、 --filterまたは-fでテーブル フィルターを指定します。

例: Amazon S3 のbackup-dataバケットのtable-filter/2022-01-30/ディレクトリからdb*.tbl*テーブルに一致するデータをターゲット クラスタに復元します。

br restore full \
    --pd "${PDIP}:2379" \
    --filter 'db*.tbl*' \
    --storage "s3://backup-data/table-filter/2022-01-30/"  \
    --log-file restorefull.log

外部ストレージからバックアップ データを復元する

BR は、Amazon S3、Google Cloud Storage (GCS)、Azure Blob Storage、NFS、またはその他の S3 互換ファイル ストレージ サービスへのデータの復元をサポートしています。詳細については、次のドキュメントを参照してください。

増分データの復元

増分データの復元は、BR を使用した完全なデータの復元に似ています。増分データを復元する場合は、 last backup tsより前にバックアップされたすべてのデータがターゲット クラスターに復元されていることを確認してください。また、増分復元では ts データが更新されるため、復元中に他の書き込みが行われないようにする必要があります。そうしないと、競合が発生する可能性があります。

br restore full \
    --pd "${PDIP}:2379" \
    --storage "s3://backup-data/2022-01-30/incr"  \
    --ratelimit 128 \
    --log-file restorefull.log

暗号化されたバックアップ データを復元する

バックアップ データを暗号化したら、対応する復号化パラメータを渡してデータを復元する必要があります。復号化アルゴリズムとキーが正しいことを確認してください。復号化アルゴリズムまたはキーが正しくない場合、データは復元できません。

br restore full\
    --pd ${PDIP}:2379 \
    --storage "s3://backup-data/2022-01-30/" \
    --crypter.method aes128-ctr \
    --crypter.key 0123456789abcdef0123456789abcdef

mysqlスキーマのテーブルを復元する

BR v5.1.0 以降、フル バックアップを実行すると、BR はシステム テーブルをバックアップします。 BR v6.2.0 より前のデフォルト構成では、BR はユーザー データのみを復元し、システム テーブル内のデータは復元しません。 BR v6.2.0 以降、バックアップ データにシステム テーブルが含まれている場合、 --with-sys-tableを構成すると、BR は一部のシステム テーブルのデータを復元します。

BR は、次のシステム テーブルのデータを復元できます。

+----------------------------------+
| mysql.columns_priv               |
| mysql.db                         |
| mysql.default_roles              |
| mysql.global_grants              |
| mysql.global_priv                |
| mysql.role_edges                 |
| mysql.tables_priv                |
| mysql.user                       |
+----------------------------------+

BR は、次のシステム テーブルを復元しません。

システム権限に関連するデータを復元する場合は、次の点に注意してください。

  • BR は、 userをcloud_adminとして、 hostを'%'としてユーザー データを復元しません。このユーザーはTiDB Cloud用に予約されています。 cloud_adminに関連するユーザー権限を正しく復元できないため、ご使用の環境でcloud_adminという名前のユーザーまたはロールを作成しないでください。

  • BR は、データを復元する前に、ターゲット クラスタ内のシステム テーブルがバックアップ データ内のシステム テーブルと互換性があるかどうかをチェックします。 「互換性がある」とは、次のすべての条件が満たされていることを意味します。

    • ターゲット クラスタには、バックアップ データと同じシステム テーブルがあります。
    • 対象クラスタのシステム権限テーブルの列数がバックアップデータの列数と一致している。列の順序は異なる場合があります。
    • ターゲット クラスタのシステム権限テーブルの列は、バックアップ データの列と互換性があります。列のデータ型が長さのある型 (int や char など) の場合、ターゲット クラスターの長さはバックアップ データの長さ以上である必要があります。列のデータ型が列挙型の場合、ターゲット クラスターの列挙値は、バックアップ データの列挙値のスーパーセットである必要があります。

ターゲット クラスタが空でない場合、またはターゲット クラスタがバックアップ データと互換性がない場合、BR は次の情報を返します。 --with-sys-tableを削除すると、システム テーブルの復元をスキップできます。

#######################################################################
# the target cluster is not compatible with the backup data,
# br cannot restore system tables.
# you can remove 'with-sys-table' flag to skip restoring system tables
#######################################################################

mysqlスキーマ (システム テーブルではない) でユーザーが作成したテーブルを復元するには、 テーブル フィルターを使用して明示的にテーブルを含めることができます。次の例は、BR が通常の復元を実行するときにmysql.usertableテーブルを復元する方法を示しています。

br restore full -f '*.*' -f '!mysql.*' -f 'mysql.usertable' -s $external_storage_url --with-sys-table

前のコマンドでは、

  • -f '*.*'は、デフォルトのルールをオーバーライドするために使用されます
  • -f '!mysql.*'は、特に明記されていない限り、 mysqlでテーブルを復元しないように BR に指示します。
  • -f 'mysql.usertable'は、 mysql.usertableを復元する必要があることを示します。

mysql.usertableのみを復元する必要がある場合は、次のコマンドを実行します。

br restore full -f 'mysql.usertable' -s $external_storage_url --with-sys-table

復元性能と影響

  • TiDB は、データの復元時に TiKV CPU、ディスク IO、ネットワーク帯域幅、およびその他のリソースを完全に使用します。したがって、実行中のサービスに影響を与えないように、空のクラスターにバックアップ データを復元することをお勧めします。
  • 復元速度は、クラスター構成、展開、および実行中のサービスに大きく依存します。通常、復元速度は 100 MB/秒 (TiKV ノードあたり) に達することがあります。

ノート：

多くのシナリオでのシミュレーション テストに基づき、一部の顧客サイトで検証された前述のテストの結論は、参照に値します。ただし、復元速度はシナリオによって異なる場合があります。したがって、常にテストを実行し、テスト結果を確認する必要があります。