バックアップと復元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より前のバージョンよりも低くなります。 v5.4より前のデフォルト値のbackup.num-threadsはCPU * 0.75でした。つまり、バックアップタスクで使用されるスレッドの数が論理CPUコアの75％を占めていました。最大値は32でした。 v5.4以降、この構成アイテムのデフォルト値はCPU * 0.5で、最大値は8です。
オフラインクラスタでバックアップタスクを実行する場合、バックアップを高速化するために、 tikv-ctlを使用してbackup.num-threadsの値をより大きな数に変更できます。
エラーメッセージcould not read local://...:download sst failed場合、データの復元中に返されますが、どうすればよいですか？
データを復元する場合、各ノードはすべてのバックアップファイル（SSTファイル）にアクセスできる必要があります。デフォルトでは、 localのストレージが使用されている場合、バックアップファイルは異なるノードに分散しているため、データを復元することはできません。したがって、各TiKVノードのバックアップファイルを他のTiKVノードにコピーする必要があります。
バックアップ中にNFSディスクをバックアップディスクとしてマウントすることをお勧めします。詳細については、 1つのテーブルをネットワークディスクにバックアップしますを参照してください。
BRを使用したバックアップ中にクラスタにどの程度影響しますか？
TiDB v5.4.0以降のバージョンでは、BRは、バックアップタスクで使用されるデフォルトのCPU使用率を下げるだけでなく、ワークロードが重いクラスタでバックアップタスクで使用されるリソースを制限します。したがって、ワークロードが重いv5.4.0クラスタのバックアップタスクにデフォルト構成を使用する場合、クラスタのパフォーマンスに対するタスクの影響は、v5.4.0より前のクラスターの影響よりも大幅に小さくなります。詳細については、 BRオートチューンを参照してください。
以下は、単一ノードでの内部テストです。テスト結果は、フルスピードバックアップシナリオで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倍です。
バックアップタスクがクラスタのパフォーマンスに与える影響を手動で制御する必要がある場合は、次のソリューションを使用できます。これらの2つの方法は、クラスタへのバックアップタスクの影響を減らすことができますが、バックアップタスクの速度も低下させます。
--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システムスキーマのテーブルデータのバックアップと復元（実験的機能）を参照してください。
ルートを使用してBRを実行しようとしても、 Permission deniedた、またはNo such file or directoryエラーが発生しないようにするにはどうすればよいですか？
TiKVがバックアップディレクトリにアクセスできるかどうかを確認する必要があります。データをバックアップするには、TiKVに書き込み権限があるかどうかを確認してください。データを復元するには、読み取り権限があるかどうかを確認してください。
バックアップ操作中に、記憶媒体がローカルディスクまたはネットワークファイルシステム（NFS）の場合、BRを開始するユーザーとTiKVを開始するユーザーが一致していることを確認します（BRとTiKVが異なるマシン上にある場合、ユーザーは'UIDは一貫している必要があります）。そうしないと、 Permission deniedの問題が発生する可能性があります。
バックアップファイル（SSTファイル）はTiKVによって保存されるため、ルートアクセスでBRを実行すると、ディスクのアクセス許可が原因で失敗する可能性があります。
ノート：
データの復元中にも同じ問題が発生する可能性があります。 SSTファイルを初めて読み取るときに、読み取り権限が検証されます。 DDLの実行期間は、権限の確認とBRの実行の間に長い間隔がある可能性があることを示しています。長時間待つと、エラーメッセージ
Permission deniedが表示される場合があります。したがって、次の手順に従って、データを復元する前に権限を確認することをお勧めします。
プロセスクエリに対して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_ouoTiUPコマンドを使用して、クラスタのスタートアップ情報を照会します。
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バックアップディレクトリの権限を確認してください。たとえば、
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を使用して復元されたすべてのテーブルをTiCDC/Drainerブロックリストに追加します。
filter.rulesを使用してTiCDCのブロックリストを構成し、 syncer.ignore-tableを使用してDrainerのブロックリストを構成できます。
BRは、テーブルのSHARD_ROW_ID_BITSおよびPRE_SPLIT_REGIONS情報をバックアップしますか？復元されたテーブルには複数のリージョンがありますか？
はい。 BRは、テーブルのSHARD_ROW_ID_BITSおよびPRE_SPLIT_REGIONSの情報をバックアップします。復元されたテーブルのデータも複数のリージョンに分割されます。
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プロセスを並行して実行するテストは行われていないため、成功する保証はありません。