TiDB スナップショットのバックアップと復元コマンド マニュアル

このドキュメントでは、次のようなアプリケーション シナリオに応じて、TiDB スナップショットのバックアップと復元のコマンドについて説明します。

• クラスタースナップショットをバックアップする
• データベースまたはテーブルをバックアップする
  • データベースをバックアップする
  • テーブルをバックアップする
  • テーブルフィルターを使用して複数のテーブルをバックアップする
• 統計のバックアップ
• バックアップデータを暗号化する
• クラスタースナップショットを復元する
• データベースまたはテーブルを復元する
  • データベースを復元する
  • テーブルを復元する
  • テーブルフィルターを使用して複数のテーブルを復元する
  • mysqlスキーマから実行プランバインディングを復元する
• 暗号化されたスナップショットを復元する

スナップショットのバックアップと復元の詳細については、以下を参照してください。

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

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

tiup br backup fullコマンドを使用して、TiDB クラスターの最新または指定されたスナップショットをバックアップできます。コマンドの詳細については、 tiup br backup full --helpコマンドを実行してください。

tiup br backup full \
    --pd "${PD_IP}:2379" \
    --backupts '2024-06-28 13:30:00 +08:00' \
    --storage "s3://${backup_collection_addr}/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}" \
    --ratelimit 128 \
    --log-file backupfull.log

上記のコマンドでは、

• --backupts : スナップショットの時点。形式はTSOまたは400036290571534337や2024-06-28 13:30:00 +08:00などのタイムスタンプです。このスナップショットのデータがガベージ コレクションされた場合、 tiup br backupコマンドはエラーを返し、'br' は終了します。このパラメータを指定しない場合、 brバックアップ開始時刻に対応するスナップショットを選択します。
• --ratelimit : バックアップ タスクを実行するTiKV あたりの最大速度。単位は MiB/s です。
• --log-file : brログが書き込まれる対象ファイル。

注記：

BRツールは、GC への自己適応をすでにサポートしています。バックアップ中に TiDB の GC セーフ ポイントが前進しないように、 backupTS (デフォルトでは最新の PD タイムスタンプ) を PD のsafePointに自動的に登録し、GC 構成を手動で設定する必要がなくなります。

バックアップ中は、以下のようにターミナルに進行状況バーが表示されます。進行状況バーが 100% に進むと、バックアップが完了します。

Full Backup <---------/................................................> 17.12%.

データベースまたはテーブルをバックアップする

バックアップと復元 (BR) は、クラスター スナップショットまたは増分データ バックアップから、指定されたデータベースまたはテーブルの部分的なデータのバックアップをサポートします。この機能を使用すると、スナップショット バックアップと増分データ バックアップから不要なデータを除外し、ビジネスに不可欠なデータのみをバックアップできます。

データベースをバックアップする

クラスター内のデータベースをバックアップするには、 tiup br backup dbコマンドを実行します。

次の例では、 testデータベースを Amazon S3 にバックアップします。

tiup br backup db \
    --pd "${PD_IP}:2379" \
    --db test \
    --storage "s3://${backup_collection_addr}/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}" \
    --ratelimit 128 \
    --log-file backuptable.log

上記のコマンドでは、 --dbデータベース名を指定し、その他のパラメータはTiDB クラスターのスナップショットをバックアップすると同じです。

テーブルをバックアップする

クラスター内のテーブルをバックアップするには、 tiup br backup tableコマンドを実行します。

次の例では、 test.usertableテーブルを Amazon S3 にバックアップします。

tiup br backup table \
    --pd "${PD_IP}:2379" \
    --db test \
    --table usertable \
    --storage "s3://${backup_collection_addr}/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}" \
    --ratelimit 128 \
    --log-file backuptable.log

上記のコマンドでは、 --dbと--tableそれぞれデータベース名とテーブル名を指定し、その他のパラメータはTiDB クラスターのスナップショットをバックアップすると同じです。

テーブルフィルターを使用して複数のテーブルをバックアップする

より多くの条件で複数のテーブルをバックアップするには、 tiup br backup fullコマンドを実行し、 テーブルフィルター --filterまたは-fで指定します。

次の例では、 db*.tbl*フィルター ルールに一致するテーブルを Amazon S3 にバックアップします。

tiup br backup full \
    --pd "${PD_IP}:2379" \
    --filter 'db*.tbl*' \
    --storage "s3://${backup_collection_addr}/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}" \
    --ratelimit 128 \
    --log-file backupfull.log

統計のバックアップ

TiDB v7.5.0 以降、 brコマンドライン ツールに--ignore-statsパラメータが導入されました。このパラメータをfalseに設定すると、 brコマンドライン ツールは列、インデックス、およびテーブルの統計のバックアップをサポートします。この場合、バックアップから復元された TiDB データベースの統計収集タスクを手動で実行したり、自動収集タスクの完了を待ったりする必要はありません。この機能により、データベースのメンテナンス作業が簡素化され、クエリのパフォーマンスが向上します。

このパラメータをfalseに設定しない場合、 brコマンドライン ツールはデフォルト設定の--ignore-stats=true使用します。つまり、データのバックアップ中に統計はバックアップされません。

以下は、クラスター スナップショット データをバックアップし、テーブル統計を--ignore-stats=falseでバックアップする例です。

tiup br backup full \
--storage local:///br_data/ --pd "${PD_IP}:2379" --log-file restore.log \
--ignore-stats=false

上記の構成でデータをバックアップした後、データを復元すると、バックアップにテーブル統計が含まれている場合、 brコマンドライン ツールはテーブル統計を自動的に復元します (v8.0.0 以降、 brコマンドライン ツールは、バックアップ統計を復元するかどうかを制御する--load-statsパラメーターを導入しました。デフォルトの動作では、バックアップ統計が復元されます。ほとんどの場合、これをfalseに設定する必要はありません)。

tiup br restore full \
--storage local:///br_data/ --pd "${PD_IP}:2379" --log-file restore.log

バックアップと復元機能では、データをバックアップするときに、統計情報を JSON 形式でbackupmetaファイル内に保存します。データを復元するときに、統計情報を JSON 形式でクラスターに読み込みます。詳細については、 ロード統計参照してください。

バックアップデータを暗号化する

BR はバックアップ側でのバックアップデータの暗号化とAmazon S3にバックアップする際のstorage側サポートしています。必要に応じていずれかの暗号化方法を選択できます。

TiDB v5.3.0 以降では、次のパラメータを設定することでバックアップ データを暗号化できます。

• --crypter.method : 暗号化アルゴリズム。 aes128-ctr 、 aes192-ctr 、またはaes256-ctrになります。デフォルト値はplaintextで、データが暗号化されていないことを示します。
• --crypter.key : 16 進文字列形式の暗号化キー。アルゴリズムaes128-ctrの場合は 128 ビット (16 バイト) のキー、アルゴリズムaes192-ctrの場合は 24 バイトのキー、アルゴリズムaes256-ctrの場合は 32 バイトのキーです。
• --crypter.key-file : キー ファイルcrypter.keyを渡さずに、キーが保存されているファイル パスをパラメーターとして直接渡すことができます。

次に例を示します。

tiup br backup full\
    --pd ${PD_IP}:2379 \
    --storage "s3://${backup_collection_addr}/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}" \
    --crypter.method aes128-ctr \
    --crypter.key 0123456789abcdef0123456789abcdef

注記：

• キーが失われた場合、バックアップ データをクラスターに復元することはできません。
• 暗号化機能は、 brおよび TiDB クラスター v5.3.0 以降のバージョンで使用する必要があります。暗号化されたバックアップ データは、v5.3.0 より前のクラスターでは復元できません。

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

tiup br restore fullコマンドを実行すると、TiDB クラスターのスナップショットを復元できます。

tiup br restore full \
    --pd "${PD_IP}:2379" \
    --with-sys-table \
    --storage "s3://${backup_collection_addr}/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}" \
    --ratelimit 128 \
    --log-file restorefull.log

上記のコマンドでは、

• --with-sys-table : BR は、アカウント権限データ、SQL バインディング、統計情報など、一部のシステム テーブルのデータを復元します ( 統計のバックアップを参照)。ただし、統計テーブル ( mysql.stat_* ) とシステム変数テーブル ( mysql.tidbとmysql.global_variables ) は復元されません。詳細については、 mysqlスキーマ内のテーブルを復元する参照してください。
• --ratelimit : 復元タスクを実行するTiKV あたりの最大速度。単位は MiB/s です。
• --log-file : brログが書き込まれる対象ファイル。

復元中は、以下のようにターミナルに進行状況バーが表示されます。進行状況バーが 100% に進むと、復元タスクは完了です。 br 、復元されたデータを検証して、データのセキュリティを確保します。

Full Restore <---------/...............................................> 17.12%.

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

br使用すると、バックアップ データから指定されたデータベースまたはテーブルの部分的なデータを復元できます。この機能を使用すると、復元中に不要なデータを除外できます。

データベースを復元する

データベースをクラスターに復元するには、 tiup br restore dbコマンドを実行します。

次の例では、バックアップ データからtestデータベースをターゲット クラスターに復元します。

tiup br restore db \
    --pd "${PD_IP}:2379" \
    --db "test" \
    --ratelimit 128 \
    --storage "s3://${backup_collection_addr}/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}" \
    --log-file restore_db.log

上記のコマンドでは、 --db復元するデータベースの名前を指定し、その他のパラメータはTiDB クラスターのスナップショットを復元すると同じです。

注記：

バックアップデータをリストアする場合、 --dbで指定したデータベース名は、バックアップコマンドの-- dbで指定したデータベース名と同じである必要があります。そうでない場合、リストアは失敗します。これは、バックアップデータのメタファイル ( backupmetaファイル) にデータベース名が記録されており、同じ名前のデータベースにしかデータをリストアできないためです。推奨される方法は、バックアップデータを別のクラスター内の同じ名前のデータベースにリストアすることです。

テーブルを復元する

単一のテーブルをクラスターに復元するには、 tiup br restore tableコマンドを実行します。

次の例では、Amazon S3 からtest.usertableテーブルをターゲット クラスターに復元します。

tiup br restore table \
    --pd "${PD_IP}:2379" \
    --db "test" \
    --table "usertable" \
    --ratelimit 128 \
    --storage "s3://${backup_collection_addr}/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}" \
    --log-file restore_table.log

上記のコマンドでは、 --table復元するテーブルの名前を指定し、その他のパラメータはデータベースを復元すると同じです。

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

より複雑なフィルター ルールを使用して複数のテーブルを復元するには、 tiup br restore fullコマンドを実行し、 テーブルフィルター --filterまたは-fで指定します。

次の例では、 db*.tbl*フィルター ルールに一致するテーブルを Amazon S3 からターゲット クラスターに復元します。

tiup br restore full \
    --pd "${PD_IP}:2379" \
    --filter 'db*.tbl*' \
    --storage "s3://${backup_collection_addr}/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}" \
    --log-file restorefull.log

mysqlスキーマから実行プランバインディングを復元する

クラスターの実行プラン バインディングを復元するには、 --with-sys-tableオプションと、復元するmysqlスキーマを指定する--filterまたは-fオプションを含むtiup br restore fullコマンドを実行します。

以下はmysql.bind_infoテーブルを復元する例です。

tiup br restore full \
    --pd "${PD_IP}:2379" \
    --filter 'mysql.bind_info' \
    --with-sys-table \
    --ratelimit 128 \
    --storage "s3://${backup_collection_addr}/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}" \
    --log-file restore_system_table.log

復元が完了したら、実行プランのバインディング情報をSHOW GLOBAL BINDINGSで確認できます。

SHOW GLOBAL BINDINGS;

復元後の実行プラン バインディングの動的読み込みはまだ最適化中です (関連する問題は＃46527と＃46528です)。復元後に実行プラン バインディングを手動で再読み込みする必要があります。

-- Ensure that the mysql.bind_info table has only one record for builtin_pseudo_sql_for_bind_lock. If there are more records, you need to manually delete them.
SELECT count(*) FROM mysql.bind_info WHERE original_sql = 'builtin_pseudo_sql_for_bind_lock';
DELETE FROM bind_info WHERE original_sql = 'builtin_pseudo_sql_for_bind_lock' LIMIT 1;

-- Force to reload the binding information.
ADMIN RELOAD BINDINGS;

暗号化されたスナップショットを復元する

バックアップ データを暗号化した後、データを復元するには、対応する復号化パラメータを渡す必要があります。復号化アルゴリズムとキーが正しいことを確認してください。復号化アルゴリズムまたはキーが正しくない場合、データを復元することはできません。次に例を示します。

tiup br restore full\
    --pd "${PD_IP}:2379" \
    --storage "s3://${backup_collection_addr}/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}" \
    --crypter.method aes128-ctr \
    --crypter.key 0123456789abcdef0123456789abcdef