TiDB Cloud
TiDB Self-Managed
Learning Center
お問い合わせ

バックアップと復元に関するよくある質問

このドキュメントには、バックアップと復元 (BR) に関するよくある質問 (FAQ) と解決策が記載されています。

TiDB v5.4.0 以降のバージョンで、ワークロードの高いクラスタでバックアップ タスクを実行すると、バックアップ タスクの速度が遅くなるのはなぜですか?

TiDB v5.4.0 から、BR はバックアップ タスクの自動調整機能を導入します。 v5.4.0 以降のバージョンのクラスターの場合、この機能はデフォルトで有効になっています。クラスターのワークロードが重い場合、この機能はバックアップ タスクで使用されるリソースを制限して、オンライン クラスターへの影響を軽減します。詳細については、 BR オートチューンを参照してください。

TiKV は動的構成自動調整機能をサポートしています。クラスターを再起動せずに、次の方法で機能を有効または無効にすることができます。

  • 自動調整を無効にする: TiKV 構成項目backup.enable-auto-tuneからfalseを設定します。
  • 自動調整を有効にする: backup.enable-auto-tune ～ trueを設定します。 v5.3.x から v5.4.0 以降のバージョンにアップグレードされたクラスターの場合、自動調整機能はデフォルトで無効になっています。手動で有効にする必要があります。

tikv-ctlを使用して自動調整を有効または無効にするには、 自動調整を使用するを参照してください。

さらに、自動調整により、バックアップ タスクで使用されるデフォルトのスレッド数が減少します。詳細については、 backup.num-threads ](/tikv-configuration-file.md#num-threads-1) を参照してください。そのため、Grafana ダッシュボードでは、バックアップ タスクで使用される速度、CPU 使用率、および I/O リソース使用率が、v5.4.0 より前のバージョンよりも低くなります。 v5.4.0 より前では、デフォルト値のbackup.num-threadsはCPU * 0.75でした。つまり、バックアップ タスクで使用されるスレッドの数は、論理 CPU コアの 75% を占めていました。その最大値は32でした。 v5.4.0 以降、この構成項目のデフォルト値はCPU * 0.5で、最大値は8です。

オフライン クラスターでバックアップ タスクを実行する場合、バックアップを高速化するために、 tikv-ctlを使用してbackup.num-threadsの値をより大きな数値に変更できます。

データの復元中にエラー メッセージcould not read local://...:download sst failedが返された場合はどうすればよいですか?

データを復元する場合、各ノードはすべてのバックアップ ファイル (SST ファイル) にアクセスできる必要があります。デフォルトでは、 localのストレージが使用されている場合、バックアップ ファイルが異なるノードに分散しているため、データを復元できません。したがって、各 TiKV ノードのバックアップ ファイルを他の TiKV ノードにコピーする必要があります。

バックアップ中は、NFS ディスクをバックアップ ディスクとしてマウントすることをお勧めします。詳細については、 1 つのテーブルをネットワーク ディスクにバックアップするを参照してください。

バックアップ操作はクラスターにどの程度の影響を与えますか?

TiDB v5.4.0 以降のバージョンの場合、BR はバックアップ タスクで使用されるデフォルトの CPU 使用率を削減するだけでなく、負荷の高いクラスター内のバックアップ タスクで使用されるリソースを制限するBR オートチューンつの機能も導入します。したがって、負荷の高い v5.4.0 クラスターでバックアップ タスクのデフォルト構成を使用すると、タスクがクラスターのパフォーマンスに与える影響は、v5.4.0 より前のクラスターよりも大幅に小さくなります。

以下は、単一ノードでの内部テストです。テスト結果は、全速バックアップシナリオで v5.4.0 と v5.3.0 のデフォルト構成を使用する場合、BR を使用したバックアップがクラスター パフォーマンスに与える影響がまったく異なることを示しています。詳細なテスト結果は次のとおりです。

  • BR が v5.3.0 のデフォルト構成を使用する場合、書き込み専用ワークロードの QPS は 75% 減少します。
  • BR が v5.4.0 のデフォルト構成を使用する場合、同じワークロードの QPS は 25% 減少します。ただし、この構成を使用すると、BR を使用したバックアップ タスクの期間がそれに応じて長くなります。所要時間は v5.3.0 構成の 1.7 倍です。

次のいずれかのソリューションを使用して、クラスターのパフォーマンスに対するバックアップ タスクの影響を手動で制御できます。これらの方法は、クラスターに対するバックアップ タスクの影響を軽減しますが、バックアップ タスクの速度も低下させることに注意してください。

  • --ratelimitパラメータを使用して、バックアップ タスクの速度を制限します。このパラメータは、バックアップ ファイルを外部ストレージに保存する速度を制限することに注意してください。バックアップ ファイルの合計サイズを計算するときは、バックアップ ログのbackup data size(after compressed)をベンチマークとして使用します。
  • TiKV 構成項目backup.num-threadsを調整して、バックアップ タスクで使用されるスレッドの数を制限します。 BR がバックアップ タスクに8以下のスレッドを使用し、クラスターの合計 CPU 使用率が 60% を超えない場合、読み取りおよび書き込みワークロードに関係なく、バックアップ タスクはクラスターにほとんど影響を与えません。

BR はシステム テーブルをバックアップしますか?データの復元中に競合が発生しますか?

v5.1.0 より前では、BR はバックアップ中にシステム スキーマmysql.*からデータを除外します。 v5.1.0 以降、BR はデフォルトで、システム スキーマを含むすべてのデータをバックアップしますmysql.* 。

mysql.*のシステム テーブルを復元する技術的な実装はまだ完了していないため、システム スキーマmysqlのテーブルはデフォルトでは復元されません。つまり、競合は発生しません。詳細については、 mysqlスキーマで作成されたテーブルを復元します (実験的)を参照してください。

root を使用して BR を実行しようとしても失敗した場合でも、 Permission deniedまたはNo such file or directoryエラーを処理するにはどうすればよいですか?

TiKV がバックアップ ディレクトリにアクセスできるかどうかを確認する必要があります。データをバックアップするには、TiKV に書き込み権限があるかどうかを確認します。データを復元するには、読み取り権限があるかどうかを確認してください。

バックアップ操作中、ストレージ メディアがローカル ディスクまたはネットワーク ファイル システム (NFS) の場合、BR を起動するユーザーと TiKV を起動するユーザーが一致していることを確認します (BR と TiKV が異なるマシン上にある場合、ユーザーは' UID は一貫している必要があります)。そうしないと、 Permission deniedの問題が発生する可能性があります。

バックアップ ファイル (SST ファイル) は TiKV によって保存されるため、root アクセスで BR を実行すると、ディスクのアクセス許可が原因で失敗する場合があります。

ノート：

データの復元中に同じ問題が発生する可能性があります。 SST ファイルが初めて読み取られるときに、読み取り許可が検証されます。 DDL の実行時間は、権限のチェックと BR の実行の間に長い間隔がある可能性があることを示唆しています。長時間待機すると、エラー メッセージPermission deniedが表示される場合があります。

したがって、次の手順に従って、データを復元する前に権限を確認することをお勧めします。

  1. プロセス クエリの Linux ネイティブ コマンドを実行します。

    ps aux | grep tikv-server

    上記のコマンドの出力:

    tidb_ouo  9235 10.9  3.8 2019248 622776 ?      Ssl  08:28   1:12 bin/tikv-server --addr 0.0.0.0:20162 --advertise-addr 172.16.6.118:20162 --status-addr 0.0.0.0:20188 --advertise-status-addr 172.16.6.118:20188 --pd 172.16.6.118:2379 --data-dir /home/user1/tidb-data/tikv-20162 --config conf/tikv.toml --log-file /home/user1/tidb-deploy/tikv-20162/log/tikv.log
tidb_ouo  9236  9.8  3.8 2048940 631136 ?      Ssl  08:28   1:05 bin/tikv-server --addr 0.0.0.0:20161 --advertise-addr 172.16.6.118:20161 --status-addr 0.0.0.0:20189 --advertise-status-addr 172.16.6.118:20189 --pd 172.16.6.118:2379 --data-dir /home/user1/tidb-data/tikv-20161 --config conf/tikv.toml --log-file /home/user1/tidb-deploy/tikv-20161/log/tikv.log

    または、次のコマンドを実行できます。

    ps aux | grep tikv-server | awk '{print $1}'

    上記のコマンドの出力:

    tidb_ouo
tidb_ouo

  2. TiUP コマンドを使用して、クラスターの起動情報を照会します。

    tiup cluster list

    上記のコマンドの出力:

    [root@Copy-of-VM-EE-CentOS76-v1 br]# tiup cluster list
Starting component `cluster`: /root/.tiup/components/cluster/v1.5.2/tiup-cluster list
Name          User      Version  Path                                               PrivateKey
----          ----      -------  ----                                               ----------
tidb_cluster  tidb_ouo  v5.0.2   /root/.tiup/storage/cluster/clusters/tidb_cluster  /root/.tiup/storage/cluster/clusters/tidb_cluster/ssh/id_rsa

  3. バックアップディレクトリの権限を確認してください。たとえば、 backupはバックアップ データ ストレージ用です。

    ls -al backup

    上記のコマンドの出力:

    [root@Copy-of-VM-EE-CentOS76-v1 user1]# ls -al backup
total 0
drwxr-xr-x  2 root root   6 Jun 28 17:48 .
drwxr-xr-x 11 root root 310 Jul  4 10:35 ..

    上記の出力から、 tikv-serverインスタンスがユーザーtidb_ouoによって開始されていることがわかります。しかし、ユーザーtidb_ouoにはbackupに対する書き込み権限がありません。したがって、バックアップは失敗します。

Io(Os...)エラーを処理するにはどうすればよいですか?

これらの問題のほとんどは、TiKV がディスクにデータを書き込むときに発生するシステム コール エラーです (例: Io(Os {code: 13, kind: PermissionDenied...})またはIo(Os {code: 2, kind: NotFound...}) )。

このような問題を解決するには、まずバックアップ ディレクトリのマウント方法とファイル システムを確認し、別のフォルダまたは別のハードディスクにデータをバックアップしてみてください。

たとえば、 sambaによって構築されたネットワーク ディスクにデータをバックアップするときに、 Code: 22(invalid argument)エラーが発生する場合があります。

rpc error: code = Unavailable desc =... BR でエラーが発生しましたか?

このエラーは、リストア (BR を使用) するクラスターの容量が不足している場合に発生する可能性があります。このクラスターの監視メトリクスまたは TiKV ログを確認することで、原因をさらに確認できます。

この問題を処理するには、クラスター リソースをスケールアウトし、復元中の同時実行数を減らして、 RATE_LIMITオプションを有効にします。

localストレージを使用する場合、バックアップ ファイルはどこに保存されますか?

localのストレージを使用すると、BR が実行されているノードにbackupmetaが生成され、各リージョンのリーダー ノードにバックアップ ファイルが生成されます。

バックアップデータのサイズはどうですか？バックアップのレプリカはありますか?

データのバックアップ中に、各リージョンのリーダー ノードでバックアップ ファイルが生成されます。バックアップのサイズはデータ サイズと同じで、冗長レプリカはありません。したがって、データの合計サイズは、ほぼ TiKV データの合計数をレプリカの数で割ったものになります。

ただし、ローカル ストレージからデータを復元する場合は、各 TiKV がすべてのバックアップ ファイルにアクセスできる必要があるため、レプリカの数は TiKV ノードの数と同じになります。

BR が TiCDC/ Drainerの上流クラスターにデータを復元する場合、どうすればよいですか?

  • BR を使用して復元されたデータは、ダウンストリームに複製できません。これは、BR は SST ファイルを直接インポートしますが、現在、ダウンストリーム クラスターはこれらのファイルをアップストリームから取得できないためです。

  • v4.0.3 より前では、BR 復元中に生成された DDL ジョブにより、TiCDC/ Drainerで予期しない DDL が実行される場合がありました。したがって、TiCDC/ Drainer の上流クラスターで復元を実行する必要がある場合は、BR を使用して復元されたすべてのテーブルをDrainer / Drainerブロック リストに追加します。

filter.rulesを使用して TiCDC のブロック リストを構成し、 syncer.ignore-tableを使用してDrainerのブロック リストを構成できます。

BR は、テーブルのSHARD_ROW_ID_BITSおよびPRE_SPLIT_REGIONS情報をバックアップしますか?復元されたテーブルには複数のリージョンがありますか?

はい。 BR は、テーブルのSHARD_ROW_ID_BITSおよびPRE_SPLIT_REGIONSの情報をバックアップします。復元されたテーブルのデータも複数のリージョンに分割されます。

the entry too large, the max entry size is 6291456, the size of data is 7690800というエラー メッセージで復元が失敗した場合はどうすればよいですか?

--ddl-batch-size ～ 128以下の値を設定することで、一度に作成するテーブルの数を減らすことができます。

BR を使用して [ --ddl-batch-size ](/br/br-batch-create-table.md#how to use) の値が1より大きいバックアップ データを復元する場合、TiDB はテーブル作成の DDL ジョブを DDL ジョブ キューに書き込みます。これは TiKV によって維持されます。現時点では、TiDB が一度に送信するすべてのテーブル スキーマの合計サイズは 6 MB を超えてはなりません。これは、ジョブ メッセージの最大値がデフォルトで6 MBであるためです (この値を変更することはお勧めしません。詳細については、 txn-entry-size-limitおよび を参照してください)。 raft-entry-max-size ）。したがって、 --ddl-batch-sizeを過度に大きな値に設定すると、TiDB によって一度にバッチで送信されるテーブルのスキーマ サイズが指定された値を超えるため、BR はentry too large, the max entry size is 6291456, the size of data is 7690800エラーを報告します。

BR を使用してバックアップ データを復元した後、SQL クエリで the region is unavailableエラーが報告されるのはなぜですか?

BR を使用してバックアップされたクラスターに TiFlash がある場合、 TableInfoは BR がバックアップ データを復元するときに TiFlash 情報を格納します。復元するクラスターに TiFlash がない場合、 region is unavailableエラーが報告されます。

BR は、一部の履歴バックアップのインプレース完全復元をサポートしていますか?

いいえ。BR は、一部の履歴バックアップのインプレース完全復元をサポートしていません。

BR を Kubernetes の増分バックアップに使用するにはどうすればよいですか?

最後の BR バックアップのcommitTsフィールドを取得するには、kubectl を使用してkubectl -n ${namespace} get bk ${name}コマンドを実行します。このフィールドの内容を--lastbackuptsとして使用できます。

BR backupTS を Unix 時間に変換するにはどうすればよいですか?

BR backupTSのデフォルトは、バックアップ開始前に PD から取得した最新のタイムスタンプです。 pd-ctl tso timestampを使用してタイムスタンプを解析して正確な値を取得するか、 backupTS >> 18を使用して推定値をすばやく取得できます。

BR がバックアップ データを復元した後、テーブルとインデックスの TiDB の統計を更新するためにテーブルでANALYZEステートメントを実行する必要がありますか?

BR は統計をバックアップしません (v4.0.9 を除く)。したがって、バックアップデータを復元した後、手動で実行するかANALYZE TABLE 、または TiDB が自動的に実行されるのを待つ必要がありますANALYZE 。

v4.0.9 では、BR はデフォルトで統計をバックアップしますが、これは大量のメモリを消費します。バックアップ プロセスが正常に行われるようにするため、v4.0.10 以降、統計のバックアップはデフォルトで無効になっています。

テーブルでANALYZEを実行しない場合、TiDB は不正確な統計のために最適化された実行計画を選択できません。クエリのパフォーマンスが重要な問題でない場合は、 ANALYZEを無視できます。

複数の BR プロセスを同時に使用して、1 つのクラスターのデータを復元できますか?

次の理由により、複数の BR プロセスを同時に使用して 1 つのクラスターのデータを復元することは強くお勧めしません。

  • BR がデータを復元すると、PD の一部のグローバル構成が変更されます。そのため、複数の BR プロセスを同時にデータ復元に使用すると、これらの構成が誤って上書きされ、クラスター状態が異常になる可能性があります。
  • BR はデータを復元するために多くのクラスター リソースを消費するため、実際には、BR プロセスを並行して実行しても、復元速度は限られた範囲でしか改善されません。
  • データ復元のために複数の BR プロセスを並行して実行するテストは行われていないため、成功することは保証されていません。

バックアップ ログでkey locked Errorが報告された場合はどうすればよいですか?

ログのエラー メッセージ: log - ["backup occur kv error"][error="{\"KvError\":{\"locked\":

バックアップ プロセス中にキーがロックされている場合、BR はロックの解決を試みます。このエラーがたまにしか発生しない場合は、バックアップの正確性に影響はありません。

バックアップ操作が失敗した場合はどうすればよいですか?

ログのエラー メッセージ: log - Error: msg:"Io(Custom { kind: AlreadyExists, error: \"[5_5359_42_123_default.sst] is already exists in /dir/backup_local/\" })"

バックアップ操作が失敗し、前述のメッセージが表示された場合は、次のいずれかの操作を実行してから、バックアップを再度開始します。

  • バックアップのディレクトリを変更します。たとえば、 /dir/backup_local/を/dir/backup-2020-01-01/に変更します。
  • すべての TiKV ノードと BR ノードのバックアップ ディレクトリを削除します。

BR バックアップまたは復元後に、監視ノードに表示されるディスク使用量が一貫していない場合はどうすればよいですか?

この不一致は、バックアップで使用されるデータ圧縮率が、復元で使用されるデフォルトの圧縮率と異なることが原因で発生します。チェックサムが成功した場合、この問題は無視できます。

配置ルールをクラスターに復元するとエラーが発生するのはなぜですか?

v6.0.0 より前では、BR は配置ルールをサポートしていません。 v6.0.0 以降、BR は配置ルールをサポートし、コマンドライン オプション--with-tidb-placement-mode=strict/ignoreを導入して、配置ルールのバックアップおよび復元モードを制御します。デフォルト値strictでは、BR は配置ルールをインポートして検証しますが、値がignoreの場合はすべての配置ルールを無視します。

BR がnew_collations_enabled_on_first_bootstrap不一致を報告するのはなぜですか?

TiDB v6.0.0 以降、デフォルト値のnew_collations_enabled_on_first_bootstrapがfalseからtrueに変更されました。 BR は上流クラスタのnew_collations_enabled_on_first_bootstrap構成をバックアップし、この構成の値が上流クラスタと下流クラスタの間で一致しているかどうかを確認します。値が一致する場合、BR は上流のクラスターにバックアップされたデータを下流のクラスターに安全に復元します。値が一致しない場合、BR はデータの復元を実行せず、エラーを報告します。

v6.0.0 の以前のバージョンの TiDB クラスター内のデータをバックアップしており、このデータを v6.0.0 以降のバージョンの TiDB クラスターに復元するとします。この状況では、 new_collations_enabled_on_first_bootstrapの値がアップストリーム クラスターとダウンストリーム クラスター間で一貫しているかどうかを手動で確認する必要があります。

  • 値が一貫している場合は、復元コマンドに--check-requirements=falseを追加して、この構成チェックをスキップできます。
  • 値に矛盾があり、強制的に復元を実行すると、BR はデータ検証エラーを報告します。

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