スナップショットのバックアップと復元ガイド
このドキュメントでは、br コマンドライン ツール (以下brと呼びます) を使用して TiDB スナップショットをバックアップおよび復元する方法について説明します。データをバックアップおよび復元する前に、まずbr コマンドライン ツールをインストールするを行う必要があります。
スナップショット バックアップは、クラスター全体をバックアップする実装です。これはマルチバージョン同時実行制御 (MVCC)に基づいており、指定されたスナップショット内のすべてのデータをターゲットstorageにバックアップします。バックアップ データのサイズは、クラスター内の圧縮された単一レプリカのサイズとほぼ同じです。バックアップが完了したら、バックアップ データを空のクラスター、または競合データを含まないクラスター (同じスキーマまたは同じテーブルを持つ) に復元したり、クラスターをスナップショット バックアップの時点に復元したり、複数のクラスターを復元したりできます。クラスターレプリカ設定に従ってレプリカを作成します。
基本的なバックアップと復元に加えて、スナップショット バックアップと復元では次の機能も提供します。
クラスターのスナップショットをバックアップする
注記：
- 次の例では、Amazon S3 アクセス キーと秘密キーがアクセス許可の承認に使用されることを前提としています。 IAMロールを使用して権限を承認する場合は、
--send-credentials-to-tikv～falseを設定する必要があります。- 他のstorageシステムまたは認証方法を使用して権限を認証する場合は、 バックアップストレージに従ってパラメータ設定を調整します。
br backup fullコマンドを実行すると、TiDB クラスターのスナップショットをバックアップできます。 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など) です。このスナップショットのデータがガベージ コレクションされた場合、br backupコマンドはエラーを返し、brは終了します。このパラメータを指定しないままにすると、brバックアップ開始時刻に対応するスナップショットを選択します。--storage: バックアップデータのstorageアドレス。スナップショット バックアップは、Amazon S3、Google Cloud Storage、および Azure Blob Storage をバックアップ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 restore fullコマンドを実行すると、スナップショット バックアップを復元できます。 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% まで進むと、復元タスクが完了し、合計復元時間、平均復元速度、合計データ サイズなどの統計が表示されます。
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 は、バックアップ データから指定したデータベースまたはテーブルの部分データを復元することをサポートします。この機能を使用すると、不要なデータをフィルタリングして除外し、特定のデータベースまたはテーブルのみをバックアップできます。
データベースを復元する
データベースをクラスターに復元するには、 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に指定します。
テーブルを復元する
単一のテーブルをクラスターに復元するには、 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は復元するテーブルの名前を指定します。
テーブルフィルターを使用して複数のテーブルを復元する
より複雑なフィルター ルールを使用して複数のテーブルを復元するには、 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スキーマ内のシステム テーブルをバックアップし、デフォルトでは復元しません。 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 |
| 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 |
| 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 |
+-----------------------------------------------------+
システム権限に関連するデータを復元するときは、次の点に注意してください。
BR は、
userをcloud_adminに、hostを'%'に持つユーザー データを復元しません。このユーザーはTiDB Cloud用に予約されています。cloud_adminに関連するユーザー権限は正しく復元できないため、クラスター内にcloud_adminという名前のユーザーまたはロールを作成しないでください。データを復元する前に、 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 つの方法では、クラスターに対するバックアップ タスクの影響を軽減しながら、バックアップ タスクの速度も低下します。
--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/秒に達する可能性があります。スナップショット復元のパフォーマンスと影響はユーザー シナリオによって異なるため、実際の環境でテストする必要があります。