📣
TiDB Cloud Essential はパブリックプレビュー中です。このページは自動翻訳されたものです。原文はこちらからご覧ください。
TiDB Cloud
TiDB Self-Managed
Learning Center
お問い合わせ

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

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

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

Dumpling、CSV ファイル、または Amazon Auroraによって生成された Apache Parquet ファイルによってエクスポートされたデータを復元する必要がある場合は、 TiDB Lightningを使用してデータをインポートし、復元を実装できます。詳細については、 TiDB Lightningを使用して完全なデータを復元するを参照してください。

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 は、デフォルトでmysqlスキーマで作成されたテーブルをバックアップします。 BR を使用してデータを復元する場合、 mysqlスキーマで作成されたテーブルはデフォルトでは復元されません。これらのテーブルを復元するには、 テーブル フィルターを使用して明示的に含めることができます。次の例では、 mysqlスキーマで作成されたmysql.usertableを復元します。このコマンドは、他のデータとともにmysql.usertableを復元します。

br restore full -f '*.*' -f '!mysql.*' -f 'mysql.usertable' -s $external_storage_url --ratelimit 128

前のコマンドでは、

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

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

br restore full -f 'mysql.usertable' -s $external_storage_url --ratelimit 128

復元性能と影響

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

ノート：

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

このページは役に立ちましたか？