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

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

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

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

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

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}" \
    --log-file backupfull.log

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

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

注記：

  • v8.5.0以降、 BRツールは、バックアップパフォーマンスを向上させるために、フルバックアップ中のテーブルレベルのチェックサム計算をデフォルト（ --checksum=false ）で無効にします。
  • BRツールは既にGCへの自己適応をサポートしています。バックアップ中にTiDBのGCセーフポイントが先に進まないように、PDのタイムスタンプ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}" \
    --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}" \
    --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}" \
    --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 : 暗号化アルゴリズム。2、4、6 aes192-ctr aes128-ctrかaes256-ctrなります。デフォルト値はplaintextで、データは暗号化されません。
  • --crypter.key : 16進文字列形式の暗号化キー。アルゴリズムaes128-ctrの場合は128ビット（16バイト）、アルゴリズムaes192-ctrの場合は24バイト、アルゴリズムaes256-ctrの場合は32バイトのキーとなります。
  • --crypter.key-file : キーファイル。2 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コマンドを実行します。

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

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

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