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

スナップショットのバックアップと復元ガイド

このドキュメントでは、br コマンドライン ツール (以下、 brと呼びます) を使用して TiDB スナップショットをバックアップおよび復元する方法について説明します。 データのバックアップと復元を行う前に、まずbrコマンドラインツールをインストールするを行う必要があります。

スナップショットバックアップは、クラスター全体をバックアップする実装です。 マルチバージョン同時実行制御 (MVCC)に基づいて、指定されたスナップショット内のすべてのデータをターゲットstorageにバックアップします。 バックアップデータのサイズは、クラスター内の圧縮された単一のレプリカのサイズとほぼ同じです。 バックアップが完了したら、バックアップデータを空のクラスターまたは競合データを含まないクラスター（同じスキーマまたは同じテーブルを持つ）に復元したり、クラスターをスナップショットバックアップの時点に復元したり、クラスターレプリカ設定に従って複数のレプリカを復元したりできます。

基本的なバックアップと復元に加えて、スナップショット バックアップと復元では次の機能も提供されます。

クラスタースナップショットをバックアップする

注記：

  • 次の例では、 Amazon S3 アクセスキーとシークレットキーを使用して権限を承認することを前提としています。IAM ロールを使用して権限を承認する場合は、 --send-credentials-to-tikvからfalseに設定する必要があります。
  • 他のstorageシステムまたは認証方法を使用して権限を認証する場合は、 バックアップストレージに従ってパラメータ設定を調整します。

tiup br backup fullコマンドを実行すると、TiDB クラスターのスナップショットをバックアップできます。ヘルプ情報を表示するには、 tiup br backup full --help実行します。

tiup br backup full --pd "${PD_IP}:2379" \
    --backupts '2022-09-08 13:30:00' \
    --storage "s3://backup-101/snapshot-202209081330?access-key=${access-key}&secret-access-key=${secret-access-key}" \
    --ratelimit 128 \

上記のコマンドでは、

  • --backupts : スナップショットの時点。形式はTSOまたはタイムスタンプ ( 400036290571534337や2018-05-11 01:42:23など) になります。このスナップショットのデータがガベージ コレクションされている場合、 tiup br backupコマンドはエラーを返し、 br終了します。このパラメータを指定しない場合、 brバックアップ開始時刻に対応するスナップショットを選択します。
  • --storage : バックアップ データのstorageアドレス。スナップショット バックアップでは、バックアップstorageとして Amazon S3、Google Cloud Storage、Azure Blob Storage がサポートされています。上記のコマンドでは、例として Amazon S3 を使用しています。詳細については、 外部ストレージサービスの URI 形式を参照してください。
  • --ratelimit : バックアップ タスクを実行するTiKV あたりの最大速度。単位は MiB/s です。

バックアップ中は、以下のようにターミナルに進行状況バーが表示されます。進行状況バーが 100% に進むと、バックアップ タスクが完了し、合計バックアップ時間、平均バックアップ速度、バックアップ データ サイズなどの統計情報が表示されます。

Full Backup <-------------------------------------------------------------------------------> 100.00%
Checksum <----------------------------------------------------------------------------------> 100.00%
*** ["Full Backup success summary"] *** [backup-checksum=3.597416ms] [backup-fast-checksum=2.36975ms] *** [total-take=4.715509333s] [BackupTS=435844546560000000] [total-kv=1131] [total-kv-size=250kB] [average-speed=53.02kB/s] [backup-data-size(after-compressed)=71.33kB] [Size=71330]

スナップショットバックアップのバックアップ時点を取得する

多数のバックアップを管理するために、スナップショット バックアップの物理的な時間を取得する必要がある場合は、次のコマンドを実行できます。

tiup br validate decode --field="end-version" \
--storage "s3://backup-101/snapshot-202209081330?access-key=${access-key}&secret-access-key=${secret-access-key}" | tail -n1

出力は物理時間2022-09-08 13:30:00 +0800 CSTに対応して次のようになります。

435844546560000000

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

注記：

  • BR v7.5.0 以前のバージョンの場合、TiKV ノードあたりのスナップショット復元速度は約 100 MiB/秒です。
  • BR v7.6.0 以降では、大規模なリージョンのシナリオで潜在的な復元ボトルネックを解決するために、粗粒度のリージョン分散アルゴリズム (実験的) による復元の高速化をサポートしています。この機能は、コマンドライン パラメータ--granularity="coarse-grained"を指定して有効にできます。
  • BR v8.0.0 以降では、粗粒度リージョン分散リージョンによるスナップショット復元が一般提供 (GA) され、デフォルトで有効になっています。BRBR、粗粒度リージョン分散アルゴリズムの採用、データベースとテーブルのバッチ作成、SST ファイルのダウンロードと取り込み操作の相互影響の軽減、テーブル統計の復元の高速化など、さまざまな最適化を実装することで、スナップショット復元速度が大幅に向上しています。実際のケースでのテスト結果によると、スナップショット復元の SST ファイルのダウンロード速度は最大約 10 倍向上し、TiKV ノードあたりのデータ復元速度は 1.2 GiB/s で安定し、エンドツーエンドの復元速度は約 1.5 ～ 3 倍向上し、1 時間以内に 100 TiB のデータを復元できます。

tiup br restore fullコマンドを実行するとスナップショット バックアップを復元できます。ヘルプ情報を表示するにはtiup br restore full --help実行します。

次の例では、 前のバックアップスナップショットターゲット クラスターに復元します。

tiup br restore full --pd "${PD_IP}:2379" \
--storage "s3://backup-101/snapshot-202209081330?access-key=${access-key}&secret-access-key=${secret-access-key}"

大規模クラスターの復元速度をさらに向上させるために、v7.6.0 以降、 BR は、並列復元を高速化するための粗粒度のリージョン分散アルゴリズム (実験的) をサポートしています。このアルゴリズムは、 --granularity="coarse-grained"指定して有効にできます。有効にすると、 BR は復元タスクを多数の小さなタスクにすばやく分割し、それらをすべての TiKV ノードにバッチで分散できるため、各 TiKV ノードのリソースを最大限に活用して、並列で高速に復元できます。

復元中は、以下のようにターミナルに進行状況バーが表示されます。進行状況バーが 100% に進むと、復元タスクが完了し、合計復元時間、平均復元速度、合計データ サイズなどの統計情報が表示されます。

Full Restore <------------------------------------------------------------------------------> 100.00%
*** ["Full Restore success summary"] *** [total-take=4.344617542s] [total-kv=5] [total-kv-size=327B] [average-speed=75.27B/s] [restore-data-size(after-compressed)=4.813kB] [Size=4813] [BackupTS=435844901803917314]

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

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

データベースを復元する

データベースをクラスターに復元するには、 tiup br restore dbコマンドを実行します。次の例では、 testデータベースをバックアップ データからターゲット クラスターに復元します。

tiup br restore db \
--pd "${PD_IP}:2379" \
--db "test" \
--storage "s3://backup-101/snapshot-202209081330?access-key=${access-key}&secret-access-key=${secret-access-key}"

上記のコマンドでは、 --db復元するデータベースの名前を指定します。

テーブルを復元する

単一のテーブルをクラスターに復元するには、 tiup br restore tableコマンドを実行します。次の例では、バックアップ データからtest.usertableテーブルをターゲット クラスターに復元します。

tiup br restore table --pd "${PD_IP}:2379" \
--db "test" \
--table "usertable" \
--storage "s3://backup-101/snapshot-202209081330?access-key=${access-key}&secret-access-key=${secret-access-key}"

上記のコマンドでは、 --db復元するデータベースの名前を指定し、 --table復元するテーブルの名前を指定します。

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

より複雑なフィルター ルールを使用して複数のテーブルを復元するには、 tiup br restore fullコマンドを実行し、 テーブルフィルター --filterまたは-fで指定します。次の例では、 db*.tbl*フィルター ルールに一致するテーブルをバックアップ データからターゲット クラスターに復元します。

tiup br restore full \
--pd "${PD_IP}:2379" \
--filter 'db*.tbl*' \
--storage "s3://backup-101/snapshot-202209081330?access-key=${access-key}&secret-access-key=${secret-access-key}"

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

  • BR v5.1.0 以降では、スナップショットをバックアップすると、 BR はmysqlスキーマ内のシステム テーブルを自動的にバックアップしますが、デフォルトではこれらのシステム テーブルを復元しません。
  • v6.2.0 以降では、 BR--with-sys-tableを指定して一部のシステム テーブルのデータを復元できます。
  • v7.6.0 以降、 BR はデフォルトで--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                       |
| mysql.bind_info                  |
+----------------------------------+

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

+-----------------------------------------------------+
| capture_plan_baselines_blacklist                    |
| column_stats_usage                                  |
| gc_delete_range                                     |
| gc_delete_range_done                                |
| global_variables                                    |
| schema_index_usage                                  |
| stats_buckets                                       |
| stats_extended                                      |
| stats_feedback                                      |
| stats_fm_sketch                                     |
| stats_histograms                                    |
| stats_history                                       |
| stats_meta                                          |
| stats_meta_history                                  |
| stats_table_locked                                  |
| stats_top_n                                         |
| tidb                                                |
+-----------------------------------------------------+

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

  • v7.6.0 より前では、 BR はuserをcloud_adminとして、 hostを'%'としてユーザー データを復元しません。このユーザーはTiDB Cloud用に予約されています。v7.6.0 以降、 BR はデフォルトですべてのユーザー データ ( cloud_adminを含む) の復元をサポートします。

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

    • ターゲット クラスターには、バックアップ データと同じシステム テーブルがあります。
    • ターゲット クラスターのシステム権限テーブルの列数は、バックアップ データ内の列数と同じです。列の順序は重要ではありません。
    • ターゲット クラスターのシステム権限テーブル内の列は、バックアップ データ内の列と互換性があります。列のデータ型が長さのある型 (整数や文字列など) の場合、ターゲット クラスター内の長さはバックアップ データ内の長さ以上である必要があります。列のデータ型がENUM型の場合、ターゲット クラスター内のENUMの値の数は、バックアップ データ内の値のスーパーセットである必要があります。

パフォーマンスと影響

スナップショットバックアップのパフォーマンスと影響

バックアップ機能は、クラスターのbackup.num-threads (トランザクションのレイテンシーと QPS) に多少影響を及ぼします。ただし、バックアップ スレッドの数を調整するか、クラスターを追加することで、影響を軽減できます。

バックアップの影響を説明するために、このドキュメントでは、いくつかのスナップショット バックアップ テストのテスト結果をリストします。

  • (5.3.0 以前) TiKV ノード上のBRのバックアップ スレッドがノードの合計 CPU の 75% を占めると、QPS は元の QPS の 35% 減少します。
  • (5.4.0 以降) TiKV ノード上のBRスレッドが8以下で、クラスターの合計 CPU 使用率が 80% を超えない場合、 BRタスク (書き込みと読み取り) がクラスターに与える影響は最大 20% になります。
  • (5.4.0 以降) TiKV ノード上のBRスレッドが8以下で、クラスターの合計 CPU 使用率が 75% を超えない場合、 BRタスク (書き込みと読み取り) がクラスターに与える影響は最大 10% になります。
  • (5.4.0 以降) TiKV ノード上のBRスレッドが8以下で、クラスターの合計 CPU 使用率が 60% を超えない場合、 BRタスクはクラスターにほとんど影響を与えません (書き込みと読み取り)。

次の方法を使用して、バックアップ タスクがクラスターのパフォーマンスに与える影響を手動で制御できます。ただし、これら 2 つの方法では、バックアップ タスクの速度が低下すると同時に、バックアップ タスクがクラスターに与える影響も軽減されます。

  • バックアップ タスクの速度を制限するには、 --ratelimitパラメータを使用します。このパラメータは、バックアップ ファイルを外部storageに保存する速度を制限することに注意してください。バックアップ ファイルの合計サイズを計算するときは、 backup data size(after compressed)をベンチマークとして使用します。
  • TiKV 構成項目backup.num-threadsを調整して、バックアップ タスクで使用されるスレッドの数を制限します。内部テストによると、 BR がバックアップ タスクに使用するスレッドが8以下で、クラスターの合計 CPU 使用率が 60% を超えない場合、読み取りおよび書き込みのワークロードに関係なく、バックアップ タスクはクラスターにほとんど影響を与えません。

バックアップ スレッド数を制限することで、バックアップがクラスター パフォーマンスに与える影響を軽減できますが、これはバックアップ パフォーマンスに影響します。前述のテストでは、バックアップ速度はバックアップ スレッド数に比例することが示されています。スレッド数が少ない場合、バックアップ速度は約 20 MiB/スレッドです。たとえば、単一の TiKV ノード上の 5 つのバックアップ スレッドは、100 MiB/秒のバックアップ速度に達することができます。

スナップショット復元のパフォーマンスと影響

  • データの復元中、TiDB は TiKV CPU、ディスク IO、およびネットワーク帯域幅のリソースを最大限に活用しようとします。したがって、実行中のアプリケーションに影響を与えないように、空のクラスターでバックアップ データを復元することをお勧めします。

  • バックアップ データの復元速度は、クラスターの構成、展開、実行中のアプリケーションに大きく関係します。社内テストでは、単一の TiKV ノードの復元速度は 100 MiB/秒に達することがあります。スナップショット復元のパフォーマンスと影響はユーザー シナリオによって異なるため、実際の環境でテストする必要があります。

  • BR は、大規模なリージョンシナリオでリージョンの復元を高速化するために、粗粒度のリージョン分散アルゴリズムを提供します。このアルゴリズムは、コマンドライン パラメータ--granularity="coarse-grained"によって制御され、デフォルトで有効になっています。このアルゴリズムにより、各 TiKV ノードが安定して均等に分散されたダウンロード タスクを受け取ることができるため、各 TiKV ノードのリソースが十分に活用され、迅速な並列リカバリが実現します。実際のいくつかのケースでは、大規模なリージョンシナリオでクラスターのスナップショット復元速度が約 3 倍向上しています。次に例を示します。

    tiup br restore full \
--pd "${PDIP}:2379" \
--storage "s3://${Bucket}/${Folder}" \
--s3.region "${region}" \
--granularity "coarse-grained" \
--send-credentials-to-tikv=true \
--log-file restorefull.log

  • v8.0.0 以降、 brコマンドライン ツールに、 BR がTiKV ノードごとにダウンロードして取り込むファイルの最大数を制御するための--tikv-max-restore-concurrencyパラメータが導入されました。このパラメータを構成することで、ジョブ キューの最大長 (ジョブ キューの最大長 = 32 TiKV ノードの数 --tikv-max-restore-concurrency ) も制御できるため、 BRノードのメモリ消費を制御できます。

    通常の場合、 --tikv-max-restore-concurrencyクラスター構成に基づいて自動的に調整されるため、手動での構成は不要です。Grafana のTiKV-Details > Backup & Import > Import RPC count監視メトリックで、 BRがダウンロードするファイル数が長時間 0 に近いままであるのに対し、 BRが取り込むファイル数は一貫して上限に達している場合は、ファイル取り込みタスクが積み重なり、ジョブ キューが最大長に達したことを示しています。この場合、タスクの積み重なりの問題を軽減するために、次の対策を講じることができます。

    • ダウンロード速度を制限し、ファイルタスクの取り込みに十分なリソースを確保するには、パラメータ--ratelimitを設定します。たとえば、いずれかの TiKV ノードのディスク スループットがx MiB/sで、バックアップ ファイルをダウンロードするためのネットワーク帯域幅がx/2 MiB/sを超える場合は、パラメータを--ratelimit x/2に設定できます。いずれかの TiKV ノードのディスク スループットがx MiB/sで、バックアップ ファイルをダウンロードするためのネットワーク帯域幅がx/2 MiB/s以下の場合は、パラメータ--ratelimitを設定せずにそのままにしておきます。
    • --tikv-max-restore-concurrency増やすと、ジョブ キューの最大長が増加します。

参照

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