📣
TiDB Cloud Essential はパブリックプレビュー中です。このページは自動翻訳されたものです。原文はこちらからご覧ください。
TiDB Cloud
TiDB Self-Managed
Learning Center
お問い合わせ

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

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

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

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

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

br backup full \
    --pd "${PD_IP}:2379" \
    --backupts '2022-09-08 13:30: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や2018-05-11 01:42:23など) です。このスナップショットのデータがガベージ コレクションされた場合、 br backupコマンドはエラーを返し、「br」は終了します。このパラメータを指定しないままにすると、 brバックアップ開始時刻に対応するスナップショットを選択します。
  • --ratelimit : バックアップ タスクを実行するTiKV ごとの最大速度。単位は MiB/s です。
  • --log-file : brログが書き込まれる対象ファイル。

注記：

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

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

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

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

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

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

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

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

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 クラスターのスナップショットをバックアップすると同じです。

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

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

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

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 クラスターのスナップショットをバックアップすると同じです。

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

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

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

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

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

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を渡さずに、キーが保存されているファイル パスをパラメータとして直接渡すことができます。

以下は例です。

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 より前のクラスターでは復元できません。

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

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

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を使用すると、指定したデータベースまたはテーブルの部分データをバックアップ データから復元できます。この機能を使用すると、復元中に不要なデータを除外できます。

データベースを復元する

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

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

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ファイル）にデータベース名が記録されており、同じ名前のデータベースにしかデータをリストアできないためです。推奨される方法は、バックアップ データを別のクラスター内の同じ名前のデータベースに復元することです。

テーブルを復元する

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

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

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に復元するテーブルの名前を指定し、その他のパラメータはデータベースを復元すると同じです。

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

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

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

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オプションと、復元するスキーマを指定する--filterオプションを含むbr restore fullコマンド-f実行mysqlます。

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

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;

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

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

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

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