スナップショットのバックアップと復元ガイド
このドキュメントでは、br コマンドライン ツール (以下brと呼びます) を使用して TiDB スナップショットをバックアップおよび復元する方法について説明します。データをバックアップおよび復元する前に、 brコマンドラインツールをインストールします必要があります。
スナップショットバックアップを使用すると、クラスタ全体をバックアップできます。これはマルチバージョン同時実行制御 (MVCC)に基づいており、指定されたスナップショット内のすべてのデータをターゲットstorageにバックアップします。バックアップデータのサイズは、クラスタ内の圧縮された単一レプリカのサイズとほぼ同じです。バックアップが完了したら、バックアップデータを空のクラスタまたは競合データを含まないクラスタ（同じスキーマまたは同じテーブルを持つクラスタ）に復元したり、クラスタをスナップショットバックアップの時点に復元したり、クラスタレプリカ設定に従って複数のレプリカを復元したりできます。
基本的なバックアップと復元に加えて、スナップショットバックアップと復元には以下の機能も備わっています。
クラスタスナップショットのバックアップ
注記：
- 以下の例では、Amazon S3 アクセス キーとシークレット キーを使用して権限を認証することを前提としていますIAMロールを使用して権限を認証する場合は、
--send-credentials-to-tikvfalseに設定する必要があります。- 他の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）となり、デフォルトで有効になっています。BRは、粗粒度リージョン分散アルゴリズムの採用、データベースとテーブルのバッチ作成、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 ファイルをダウンロードする前に十分なディスク空き容量があるかどうかを確認します。これらのチェックのいずれかで空き容量が不足している場合、復元タスクはエラーで失敗します。
--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スキーマ内のシステムテーブルを自動的にバックアップしますが、デフォルトではこれらのシステムテーブルを復元しません。 - バージョン6.2.0以降、 BRでは
--with-sys-tableを指定して、一部のシステムテーブルのデータを復元できます。 - バージョン7.6.0以降、 BRは
--with-sys-tableデフォルトで有効にしており、これはBRがデフォルトで一部のシステムテーブルのデータを復元することを意味します。 - バージョン 8.5.5 以降、 BRシステム テーブルの物理的な復元をサポートする
--fast-load-sys-tablesパラメーターが導入されました。このパラメーターはデフォルトで有効になっています。この方式ではRENAME TABLEDDL ステートメントを使用して、__TiDB_BR_Temporary_mysqlデータベースのシステム テーブルとmysqlデータベースのシステム テーブルをアトミックに交換します。REPLACE INTOSQL ステートメントを使用したシステム テーブルの論理的な復元とは異なり、物理的な復元ではシステム テーブル内の既存のデータが完全に上書きされます。
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_*)。ただし、統計は復元できます。 統計情報のバックアップご覧ください。 - システム変数テーブル（
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を有効にすることで、バックアップ負荷を軽減し、オンラインワークロードへの影響を最小限に抑えることができます。
バックアップスレッドの数を制限することで、クラスタのパフォーマンスに対するバックアップの影響を軽減できますが、これはバックアップのパフォーマンスに影響を与えます。前述のテスト結果から、バックアップ速度はバックアップスレッドの数に比例することがわかっています。スレッド数が少ない場合、バックアップ速度は約20 MiB/スレッドです。例えば、単一のTiKVノードで5つのバックアップスレッドを使用すると、100 MiB/秒のバックアップ速度を達成できます。
スナップショット復元のパフォーマンスと影響
データ復元中、TiDBはTiKVのCPU、ディスクI/O、およびネットワーク帯域幅のリソースを最大限に活用しようとします。そのため、実行中のアプリケーションへの影響を避けるため、バックアップデータは空のクラスタに復元することをお勧めします。
バックアップデータの復元速度は、クラスタ構成、デプロイメント、および実行中のアプリケーションに大きく左右されます。スナップショット復元のパフォーマンスと影響は、さまざまなユーザーシナリオによって異なるため、実際の環境でテストする必要があります。
BRは、大規模なリージョンシナリオにおけるリージョン復元を高速化するために、粗粒度リージョン分散アルゴリズムを提供します。このアルゴリズムにより、各TiKVノードが安定した均等に分散されたダウンロードタスクを受け取ることが保証され、各TiKVノードのリソースを最大限に活用して、迅速な並列リカバリを実現します。実際のいくつかの事例では、大規模なリージョンシナリオにおいて、クラスタのスナップショット復元速度が約3倍向上しました。
バージョン8.0.0以降、
brコマンドラインツールに--tikv-max-restore-concurrencyパラメータが導入され、 BRがTiKVノードごとにダウンロードおよび取り込むファイルの最大数を制御するようになりました。このパラメータを設定することで、ジョブキューの最大長（ジョブキューの最大長 = 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の値を増やします。