バックアップと復元に関するFAQ

このドキュメントには、よくある質問（FAQ）とバックアップと復元（BR）に関するソリューションが記載されています。

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ディスクをバックアップディスクとしてマウントすることをお勧めします。詳細については、 単一のテーブルをネットワークディスクにバックアップしますを参照してください。

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

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によって維持されています。現時点では、ジョブメッセージの最大値はデフォルトで6 MBであるため、TiDBによって一度に送信されるすべてのテーブルスキーマの合計サイズは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クエリでregion is unavailableというエラーが報告されるのはなぜですか？

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

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

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

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

最後の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プロセスを同時に使用して、単一のクラスタのデータを復元できますか？

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

• 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はデータ検証エラーを報告します。