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

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

スナップショットバックアップは、クラスタ全体をバックアップする実装です。1 マルチバージョン同時実行制御 (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 +08:00' \
    --storage "s3://backup-101/snapshot-202209081330?access-key=${access-key}&secret-access-key=${secret-access-key}" 

上記のコマンドでは、次のようになります。

• --backupts : スナップショットの時点。形式はTSOまたはタイムスタンプ（例： 400036290571534337 、 2018-05-11 01:42:23 +08:00です。このスナップショットのデータがガベージコレクションされた場合、 tiup br backupコマンドはエラーを返し、 br終了します。タイムスタンプを使用してバックアップする場合は、タイムゾーンも指定することをお勧めします。指定しない場合、 brデフォルトでローカルタイムゾーンを使用してタイムスタンプを作成するため、バックアップの時点が不正確になる可能性があります。このパラメータを指定しない場合、 brバックアップ開始時刻に対応するスナップショットを選択します。
• --storage : バックアップデータのstorageアドレス。スナップショットバックアップは、Amazon S3、Google Cloud Storage、Azure Blob Storageをバックアップstorageとしてサポートしています。上記のコマンドでは、例としてAmazon S3を使用しています。詳細については、 外部ストレージサービスのURI形式参照してください。

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

• total-ranges : バックアップするファイルの総数を示します。
• ranges-succeed : 正常にバックアップされたファイルの数を示します。
• ranges-failed : バックアップに失敗したファイルの数を示します。
• backup-total-ranges : バックアップするテーブル (パーティションを含む) とインデックスの数を示します。
• write-CF-files : write CFデータを含むバックアップ SST ファイルの数を示します。
• default-CF-files : default CFデータを含むバックアップ SST ファイルの数を示します。

Full Backup <-------------------------------------------------------------------------------> 100.00%
Checksum <----------------------------------------------------------------------------------> 100.00%
*** ["Full Backup success summary"] *** [total-ranges=20] [ranges-succeed=20] [ranges-failed=0] [backup-checksum=3.597416ms] [backup-fast-checksum=2.36975ms] [backup-total-ranges=11] [backup-total-regions=10] [write-CF-files=14] [default-CF-files=6] [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以降、大規模リージョンのシナリオにおける潜在的なリストアボトルネックに対処するため、粗粒度のリージョン分散アルゴリズム（実験的）によるリストアの高速化がBRでサポートされます。この機能は、コマンドラインパラメータ--granularity="coarse-grained"を指定することで有効化できます。
• BR v8.0.0 以降では、粗粒度リージョン分散アルゴリズムによるスナップショット復元が一般提供 (GA) され、デフォルトで有効になっています。BRBR、粗粒度リージョン分散アルゴリズムの採用、データベースとテーブルのバッチ作成、SST ファイルのダウンロードと取り込み操作の相互影響の低減、テーブル統計の復元の高速化など、さまざまな最適化を実装することで、スナップショットの復元速度が大幅に向上しています。実際のケースでのテスト結果によると、スナップショット復元の SST ファイルのダウンロード速度は最大約 10 倍向上し、TiKV ノードあたりのデータ復元速度は 1.2 GiB/s で安定し、エンドツーエンドの復元速度は約 1.5～3 倍向上し、100 TiB のデータを 1 時間以内に復元できます。
• BR v8.2.0 以降では、コマンド ライン パラメータ--granularityは非推奨となり、粗粒度リージョン散乱アルゴリズムがデフォルトで有効になります。
• BR v8.3.0 以降、スナップショット復元タスクでは、TiKV およびTiFlashの使用可能なディスク容量チェックが導入されています。タスクの開始時に、 BR は復元する SST ファイルのサイズに基づいて、TiKV およびTiFlashに十分なディスク容量があるかどうかを確認します。TiKV v8.3.0 以降のバージョンでは、TiKV は各 SST ファイルをダウンロードする前に十分なディスク容量があるかどうかを確認します。これらのチェックのいずれかで容量が不足している場合、復元タスクはエラーで失敗します。1 --check-requirements=false設定することで復元タスクの開始時のチェックをスキップできますが、TiKV が各 SST ファイルをダウンロードする前のディスク容量チェックはスキップできません。

スナップショットバックアップを復元するには、コマンド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}"

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

• total-ranges : 復元するファイルの合計数を示します。
• ranges-succeed : 正常に復元されたファイルの数を示します。
• ranges-failed : 復元に失敗したファイルの数を示します。
• merge-ranges : データ範囲の結合にかかる時間を示します。
• split-region : 領域を分割して分散するのにかかる時間を示します。
• restore-files : TiKV が SST ファイルをダウンロードして取り込むのにかかる時間を示します。
• write-CF-files : write CFデータを含む復元された SST ファイルの数を示します。
• default-CF-files : default CFデータを含む復元された SST ファイルの数を示します。
• split-keys : 領域を分割するために生成されたキーの数を示します。

Split&Scatter Region <--------------------------------------------------------------------> 100.00%
Download&Ingest SST <---------------------------------------------------------------------> 100.00%
Restore Pipeline <------------------------------------------------------------------------> 100.00%
*** ["Full Restore success summary"] [total-ranges=20] [ranges-succeed=20] [ranges-failed=0] [merge-ranges=7.546971ms] [split-region=343.594072ms] [restore-files=1.57662s] [default-CF-files=6] [write-CF-files=14] [split-keys=9] [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]

データの復元中、対象テーブルのテーブルモードは自動的にrestoreに設定されます。モードrestoreのテーブルでは、読み取りおよび書き込み操作は許可されません。データの復元が完了すると、テーブルモードは自動的にnormalに戻り、通常通りテーブルの読み取りおよび書き込みが可能になります。このメカニズムにより、復元プロセス全体を通じてタスクの安定性とデータの一貫性が確保されます。

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

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 はデフォルトで一部のシステム テーブルのデータを復元します。
• v8.5.5以降、 BRはシステムテーブルの物理リストアをサポートするためにパラメータ--fast-load-sys-tablesを導入しました。このパラメータはデフォルトで有効になっています。このアプローチでは、DDL文RENAME TABLEを使用して、データベース__TiDB_BR_Temporary_mysqlのシステムテーブルとデータベースmysqlのシステムテーブルをアトミックにスワップします。SQL文REPLACE INTOを使用したシステムテーブルの論理リストアとは異なり、物理リストアではシステムテーブル内の既存データが完全に上書きされます。

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 は次のシステム テーブルを復元しません。

• 統計表（ mysql.stat_* ）。ただし、統計は復元可能です。3 統計のバックアップ参照してください。
• システム変数テーブル（ mysql.tidbとmysql.global_variables ）
• その他のシステムテーブル

+-----------------------------------------------------+
| capture_plan_baselines_blacklist                    |
| column_stats_usage                                  |
| gc_delete_range                                     |
| gc_delete_range_done                                |
| global_variables                                    |
| 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                                                |
+-----------------------------------------------------+

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

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

パフォーマンスと影響

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

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

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

• (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つの方法は、バックアップタスクがクラスターに与える影響を軽減する一方で、バックアップタスクの速度も低下させます。

• 推奨方法：バックアップタスクで使用されるワーカースレッドの数を制御するTiKV構成パラメータbackup.num-threadsを調整します。バックアップはCPUを大量に消費する処理であるため、このパラメータを調整することでTiKVのCPU使用率をより正確に制御し、リソースの分離と予測可能性を向上させることができます。ほとんどのシナリオでは、 num-threads調整するだけで、バックアップがクラスターに与える影響を制限するのに十分です。社内テストでは、スレッド数を8以下に設定し、クラスター全体のCPU使用率が60%未満であれば、バックアップがフォアグラウンドワークロードに与える影響はごくわずかであることが示されています。

• 代替方法：既にbackup.num-threads小さな値（例えば1 ）に設定しているものの、バックアップがクラスターに与える影響をさらに軽減したい場合は、 --ratelimitパラメータの使用を検討してください。このオプションは、バックアップファイルを外部storageに書き込む際に使用する帯域幅を MiB/s 単位で制限します。実際のレート制限効果は、圧縮データのサイズによって異なります。詳細については、ログのbackup data size (after compressed)フィールドを参照してください。 --ratelimit有効にすると、 BR は同時リクエスト数を減らすために自動的に--concurrencyを1に設定します。

注記：

--ratelimit有効にすると、バックアップスループットがさらに低下します。通常、オフピーク時にバックアップを実行しており、 backup.num-threadsを 1 に減らしてもフォアグラウンドワークロードへのバックアップの影響が見られる場合、クラスターのリソース制限に近づいていることを示しています。

このような状況では、次の代替案を検討できます。

• 利用可能なリソースを増やすにはクラスターをスケールアウトするします。
• Log Backup有効にすると、バックアップの負荷が軽減され、オンライン ワークロードの中断が最小限に抑えられます。

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

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

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

• バックアップデータの復元速度は、クラスタ構成、デプロイメント、実行中のアプリケーションに大きく依存します。スナップショット復元のパフォーマンスと影響は、ユーザーシナリオによって異なるため、実際の環境でテストする必要があります。

• BRは、大規模リージョンシナリオにおけるリージョン復元を高速化するために、粗粒度のリージョン分散アルゴリズムを提供します。このアルゴリズムにより、各TiKVノードが安定的かつ均等に分散されたダウンロードタスクを受け取ることができるため、各TiKVノードのリソースを最大限に活用し、迅速な並列リカバリを実現できます。いくつかの実例において、大規模リージョンシナリオにおいて、クラスターのスナップショット復元速度が約3倍向上しました。

• v8.0.0以降、コマンドラインツールbrに、TiKVノードごとにBRがダウンロードおよびインジェストするファイルの最大数を制御するためのパラメータ--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を増やします。

参照

• TiDB バックアップと復元のユースケース
• br コマンドラインマニュアル
• TiDB スナップショットのバックアップと復元のアーキテクチャ