バックアップと復元に関するよくある質問
このドキュメントでは、TiDB バックアップ & リストア (BR) に関するよくある質問 (FAQ) と解決策を示します。
誤ってデータを削除または更新した後、データをすばやく回復するにはどうすればよいですか?
TiDB v6.4.0では、フラッシュバック機能が導入されました。この機能を使用すると、GC時間内に特定の時点のデータを迅速に復旧できます。そのため、誤操作が発生した場合でも、この機能を使用してデータを復旧できます。詳細はフラッシュバッククラスタとフラッシュバックデータベースご覧ください。
TiDB v5.4.0 以降のバージョンでは、ワークロードが高いクラスターでバックアップ タスクを実行すると、バックアップ タスクの速度が遅くなるのはなぜですか?
TiDB v5.4.0以降、 BRはバックアップタスクの自動チューニング機能を導入しました。v5.4.0以降のバージョンのクラスターでは、この機能はデフォルトで有効になっています。クラスターのワークロードが高い場合、この機能はバックアップタスクで使用されるリソースを制限し、オンラインクラスターへの影響を軽減します。詳細については、 バックアップオートチューンを参照してください。
TiKVは自動チューニング機能をサポートしています。 動的構成機能は、クラスターを再起動せずに以下の方法で有効化または無効化できます。
- 自動調整を無効にする: TiKV 構成項目
backup.enable-auto-tuneをfalseに設定します。 - 自動チューニングを有効にする：
backup.enable-auto-tunetrueに設定します。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です。
オフライン クラスターでバックアップ タスクを実行する場合、バックアップを高速化するために、 backup.num-threadsの値をtikv-ctl使用してより大きな数値に変更できます。
PITRの問題
PITRとクラスターフラッシュバックの違いは何ですか?
ユースケースの観点から見ると、PITRは通常、クラスターが完全にサービスを停止している場合、またはデータが破損していて他のソリューションでは復旧できない場合に、クラスターのデータを特定の時点に復元するために使用されます。PITRを使用するには、データ復旧用の新しいクラスターが必要です。クラスターフラッシュバック機能は、ユーザーの誤操作やその他の要因によって引き起こされるデータエラーシナリオ向けに特別に設計されており、クラスターのデータをデータエラーが発生する前の最新のタイムスタンプにインプレースで復元できます。
ほとんどの場合、人為的なミスによるデータエラーの場合、フラッシュバックはPITRよりも優れたリカバリソリューションです。これは、RPO（ほぼゼロ）とRTOがはるかに短いためです。しかし、フラッシュバックを実行できないためにクラスタが完全に利用できなくなった場合、PITRがクラスタをリカバリする唯一のソリューションとなります。そのため、PITRは、RPO（最大5分）とRTOがフラッシュバックよりも長いにもかかわらず、データベースのディザスタリカバリ戦略を策定する際には、常に必須のソリューションとなります。
上流データベースがTiDB Lightningを使用して物理インポートモードでデータをインポートすると、ログバックアップ機能が利用できなくなります。なぜですか？
現在、ログバックアップ機能はTiDB Lightningに完全には対応していません。そのため、 TiDB Lightningの物理モードでインポートされたデータはログデータにバックアップできません。
ログバックアップタスクを作成する上流クラスターでは、 TiDB Lightning物理モードを使用してデータをインポートしないでください。代わりに、 TiDB Lightning論理モードを使用できます。物理モードを使用する必要がある場合は、インポート完了後にスナップショットバックアップを実行し、PITR をスナップショットバックアップ後の時点に復元できるようにします。
クラスターはネットワークパーティション障害から回復しましたが、ログバックアップタスクの進行状況のチェックポイントがまだ再開されません。なぜでしょうか？
問題: ＃13126
クラスタ内でネットワークパーティション障害が発生すると、バックアップタスクはログのバックアップを続行できなくなります。一定の再試行時間後、タスクは状態ERRORに設定されます。この時点で、バックアップタスクは停止しています。
この問題を解決するには、 br log resumeコマンドを手動で実行して、ログ バックアップ タスクを再開する必要があります。
br restore pointコマンドを使用してダウンストリームクラスターを復元した後、 TiFlashからデータにアクセスできなくなりました。どうすればよいでしょうか？
現在、PITRはリストアフェーズ中にTiFlashへの直接データ書き込みをサポートしていません。代わりに、brコマンドラインツールがALTER TABLE table_name SET TIFLASH REPLICA *** DDLを実行してデータを複製します。そのため、PITRによるデータリストアが完了した直後にTiFlashレプリカが利用可能になるわけではありません。TiKVノードからデータが複製されるまで、一定時間待つ必要があります。レプリケーションの進行状況を確認するには、 INFORMATION_SCHEMA.tiflash_replica表のprogress情報を確認してください。
ログ バックアップ タスクのstatusがERRORになった場合はどうすればよいでしょうか?
ログバックアップタスクの実行中に、タスクが失敗し、再試行しても回復できない場合、タスクステータスはERRORなります。以下に例を示します。
br log status --pd x.x.x.x:2379
● Total 1 Tasks.
> #1 <
name: task1
status: ○ ERROR
start: 2022-07-25 13:49:02.868 +0000
end: 2090-11-18 14:07:45.624 +0000
storage: s3://tmp/br-log-backup0ef49055-5198-4be3-beab-d382a2189efb/Log
speed(est.): 0.00 ops/s
checkpoint[global]: 2022-07-25 14:46:50.118 +0000; gap=11h31m29s
error[store=1]: KV:LogBackup:RaftReq
error-happen-at[store=1]: 2022-07-25 14:54:44.467 +0000; gap=11h23m35s
error-message[store=1]: retry time exceeds: and error failed to get initial snapshot: failed to get the snapshot (region_id = 94812): Error during requesting raftstore: message: "read index not ready, reason can not read index due to merge, region 94812" read_index_not_ready { reason: "can not read index due to merge" region_id: 94812 }: failed to get initial snapshot: failed to get the snapshot (region_id = 94812): Error during requesting raftstore: message: "read index not ready, reason can not read index due to merge, region 94812" read_index_not_ready { reason: "can not read index due to merge" region_id: 94812 }: failed to get initial snapshot: failed to get the snapshot (region_id = 94812): Error during requesting raftstore: message: "read index not ready, reason can not read index due to merge, region 94812" read_index_not_ready { reason: "can not read index due to merge" region_id: 94812 }
この問題を解決するには、エラーメッセージで原因を確認し、指示に従ってください。問題が解決したら、次のコマンドを実行してタスクを再開してください。
br log resume --task-name=task1 --pd x.x.x.x:2379
バックアップタスクが再開された後、 br log statusでステータスを確認できます。タスクステータスがNORMALになると、バックアップタスクが続行されます。
● Total 1 Tasks.
> #1 <
name: task1
status: ● NORMAL
start: 2022-07-25 13:49:02.868 +0000
end: 2090-11-18 14:07:45.624 +0000
storage: s3://tmp/br-log-backup0ef49055-5198-4be3-beab-d382a2189efb/Log
speed(est.): 15509.75 ops/s
checkpoint[global]: 2022-07-25 14:46:50.118 +0000; gap=6m28s
注記：
この機能は、複数のバージョンのデータをバックアップします。長時間のバックアップタスクが失敗し、ステータスが
ERRORになると、このタスクのチェックポイントデータはsafe pointに設定され、safe pointのデータは24時間以内にガベージコレクションされません。そのため、エラーからの再開後、バックアップタスクは最後のチェックポイントから続行されます。タスクが24時間以上失敗し、最後のチェックポイントデータがガベージコレクションされている場合、タスクを再開するとエラーが報告されます。この場合、まずbr log stopコマンドを実行してタスクを停止し、新しいバックアップタスクを開始するしかありません。
br log resumeコマンドを使用して中断されたタスクを再開したときに、エラー メッセージErrBackupGCSafepointExceeded返された場合、どうすればよいですか?
Error: failed to check gc safePoint, checkpoint ts 433177834291200000: GC safepoint 433193092308795392 exceed TS 433177834291200000: [BR:Backup:ErrBackupGCSafepointExceeded]backup GC safepoint exceeded
ログバックアップタスクを一時停止すると、MVCCデータがガベージコレクションされるのを防ぐため、一時停止中のタスクプログラムは現在のチェックポイントをサービスセーフポイントとして自動的に設定します。これにより、24時間以内に生成されたMVCCデータが保持されます。バックアップチェックポイントのMVCCデータが24時間以上経過している場合、そのチェックポイントのデータはガベージコレクションされ、バックアップタスクを再開できなくなります。
この問題を解決するには、 br log stop使用して現在のタスクを削除し、 br log start使用してログバックアップタスクを作成します。同時に、後続の PITR のためにフルバックアップを実行できます。
機能の互換性の問題
br コマンドライン ツールを使用して復元されたデータが TiCDC のアップストリーム クラスターに複製できないのはなぜですか?
BRを使用して復元されたデータは、下流に複製できません。これは、 BR がSST ファイルを直接インポートしますが、下流クラスターが現在上流からこれらのファイルを取得できないためです。
v4.0.3より前のバージョンでは、リストア中に生成されたDDLジョブによって、TiCDCで予期しないDDL実行が発生する可能性があります。そのため、TiCDCの上流クラスターでリストアを実行する必要がある場合は、brコマンドラインツールを使用してリストアしたすべてのテーブルをTiCDCのブロックリストに追加してください。
filter.rules使用して、TiCDC のブロック リストを構成できます。
復元中にnew_collation_enabled不一致が報告されるのはなぜですか?
TiDB v6.0.0以降、デフォルト値のnew_collations_enabled_on_first_bootstrap falseからtrueに変更されました。BRは上流クラスタのmysql.tidbテーブルにあるnew_collation_enabled設定をバックアップし、この設定の値が上流クラスタと下流クラスタ間で一致しているかどうかを確認します。値が一致している場合、 BRは上流クラスタにバックアップされたデータを下流クラスタに安全に復元します。値が一致していない場合、 BRはデータ復元を実行せず、エラーを報告します。
以前のバージョンのTiDBクラスタでデータをバックアップし、そのデータをv6.0.0以降のバージョンのTiDBクラスタにリストアするとします。この場合、上流クラスタと下流クラスタの間で値new_collations_enabled_on_first_bootstrapが一致しているかどうかを手動で確認する必要があります。
- 値が一貫している場合は、復元コマンドに
--check-requirements=false追加して、この構成チェックをスキップできます。 - 値が不一致の場合に強制的に復元を実行すると、 BR はデータ検証エラーを報告します。
配置ルールをクラスターに復元するとエラーが発生するのはなぜですか?
v6.0.0より前のバージョンでは、 BRは配置ルールサポートしていません。v6.0.0以降、 BRは配置ルールをサポートし、配置ルールのバックアップおよび復元モードを制御するためのコマンドラインオプション--with-tidb-placement-mode=strict/ignoreを導入しました。デフォルト値strictの場合、 BRは配置ルールをインポートして検証しますが、値がignoreの場合はすべての配置ルールを無視します。
データ復元の問題
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 =... error occurred」を処理するにはどうすればよいですか?
このエラーは、復元するクラスターの容量が不足している場合に発生する可能性があります。このクラスターの監視メトリックまたはTiKVログを確認することで、原因をさらに確認できます。
この問題に対処するには、クラスター リソースをスケール アウトし、復元の値tikv-max-restore-concurrencyを減らして、オプションratelimitを有効にしてみてください。
the entry too large, the max entry size is 6291456, the size of data is 7690800 」というエラー メッセージが表示されて復元が失敗した場合は、どうすればよいですか。
--ddl-batch-size ～ 128またはそれより小さい値を設定することで、バッチで作成されるテーブルの数を減らすことができます。
BRを使用して--ddl-batch-size 1より大きい値でバックアップ データをリストアする場合、TiDB はテーブル作成の DDL ジョブを TiKV が管理する DDL ジョブ キューに書き込みます。このとき、ジョブ メッセージの最大値がデフォルトで6 MBであるため (この値を変更することは推奨されません。詳細については、 txn-entry-size-limitとraft-entry-max-size参照してください)、TiDB が一度に送信したすべてのテーブル スキーマの合計サイズは 6 MB を超えてはなりません。したがって、 --ddl-batch-size過度に大きな値に設定すると、TiDB が一括して一度に送信したテーブルのスキーマ サイズが指定値を超え、 BR がentry too large, the max entry size is 6291456, the size of data is 7690800エラーを報告します。
localstorageを使用する場合、バックアップされたファイルはどこに保存されますか?
注記：
BRまたは TiKV ノードにネットワークファイルシステム (NFS) がマウントされていない場合、または Amazon S3、GCS、または Azure Blob Storage プロトコルをサポートする外部storageを使用している場合、 BRによってバックアップされたデータは各 TiKV ノードで生成されます。ただし、バックアップデータが各ノードのローカルファイルシステムに分散されるため、この方法はBR の導入方法として推奨されません。バックアップデータの収集は、データの冗長性や運用・保守上の問題を引き起こす可能性があります。また、バックアップデータの収集前にデータを直接復元すると、エラー
SST file not foundが発生します。
ローカルstorageを使用する場合、 BRが稼働しているノードにbackupmeta生成され、各リージョンのLeaderノードにバックアップファイルが生成されます。
データの復元中にcould not read local://...:download sst failed 」というエラー メッセージが返された場合、どうすればよいですか?
データを復元する場合、各ノードはすべてのバックアップファイル（SSTファイル）にアクセスできる必要があります。デフォルトでは、storageをlocal使用している場合、バックアップファイルが複数のノードに分散しているため、データを復元できません。そのため、各TiKVノードのバックアップファイルを他のTiKVノードにコピーする必要があります。バックアップデータは、Amazon S3、Google Cloud Storage（GCS）、Azure Blob Storage、またはNFSに保存することをお勧めします。
ルートを使用してbrを実行しようとしたが、実行できなかった場合、「 Permission deniedまたはNo such file or directory 」というエラーを処理するにはどうすればよいでしょうか?
TiKVがバックアップディレクトリにアクセスできるかどうかを確認する必要があります。データをバックアップするには、TiKVに書き込み権限があるかどうかを確認してください。データを復元するには、TiKVに読み取り権限があるかどうかを確認してください。
バックアップ操作中、storageメディアがローカルディスクまたはネットワークファイルシステム（NFS）の場合、 br起動するユーザーとTiKVを起動するユーザーが一致していることを確認してください（ brとTiKVが異なるマシン上にある場合は、ユーザーのUIDが一致している必要があります）。一致していない場合、 Permission denied問題が発生する可能性があります。
バックアップ ファイル (SST ファイル) は TiKV によって保存されるため、ディスク権限が原因でbr rootユーザーとして実行すると失敗する可能性があります。
注記：
データの復元時にも同じ問題が発生する可能性があります。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バックアップデータのstorage先です。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 ..手順2の出力から、インスタンス
tikv-serverユーザーtidb_ouoによって起動されたことがわかります。しかし、ユーザーtidb_ouoはbackupへの書き込み権限がありません。そのため、バックアップは失敗します。
mysqlスキーマ内のテーブルが復元されないのはなぜですか?
BR v5.1.0以降、フルバックアップを実行すると、 BRはmysqlスキーマ内のテーブルをバックアップします。BR v6.2.0より前のデフォルト設定では、 BRはユーザーデータのみを復元し、 mysqlスキーマ内のテーブルは復元しません。
ユーザーがmysqlスキーマに作成したテーブル（システムテーブルではない）を復元するには、 テーブルフィルターを使用して明示的にテーブルを含めます。次の例は、 BR が通常の復元を実行する際にmysql.usertableテーブルを復元する方法を示しています。
br restore full -f '*.*' -f '!mysql.*' -f 'mysql.usertable' -s $external_storage_url --with-sys-table
上記のコマンドでは、
-f '*.*'デフォルトのルールを上書きするために使用されます-f '!mysql.*'、特に指定がない限り、mysqlのテーブルを復元しないようにBRに指示します。-f 'mysql.usertable'mysql.usertable復元する必要があることを示します。
mysql.usertableのみを復元する必要がある場合は、次のコマンドを実行します。
br restore full -f 'mysql.usertable' -s $external_storage_url --with-sys-table
テーブルフィルター構成した場合でも、 BR は次のシステム テーブルを復元しないことに注意してください。
- 統計表（
mysql.stat_*）。ただし、統計は復元可能です。3 統計のバックアップ参照してください。 - システム変数テーブル（
mysql.tidbmysql.global_variables - その他のシステムテーブル
復元中にcannot find rewrite ruleというエラーに対処するにはどうすればよいですか?
復元クラスタ内に、バックアップデータ内の他のテーブルと同じ名前を持ちながら構造が不整合なテーブルがないか確認してください。多くの場合、この問題は復元クラスタ内のテーブルでインデックスが欠落していることが原因です。推奨される方法は、まず復元クラスタ内のそのようなテーブルを削除してから、復元を再試行することです。
バックアップと復元について知っておきたいこと
バックアップデータのサイズはどれくらいですか？バックアップのレプリカはありますか？
データのバックアップ中、各リージョンのLeaderノードにバックアップファイルが生成されます。バックアップのサイズはデータサイズと等しく、冗長レプリカは作成されません。したがって、合計データサイズは、TiKVデータの総数をレプリカ数で割った値とほぼ等しくなります。
ただし、ローカルstorageからデータを復元する場合、各 TiKV がすべてのバックアップ ファイルにアクセスできる必要があるため、レプリカの数は TiKV ノードの数と同じになります。
BRを使用してバックアップまたは復元した後、監視ノードに表示されるディスク使用量が一致しないのはなぜですか?
この不整合は、バックアップで使用されるデータ圧縮率が、復元時に使用されるデフォルトの圧縮率と異なるために発生します。チェックサムが成功した場合は、この問題は無視できます。
BRがバックアップ データを復元した後、テーブルとインデックスの TiDB の統計を更新するために、テーブルに対してANALYZEステートメントを実行する必要がありますか?
BRは統計情報をバックアップしません（v4.0.9を除く）。そのため、バックアップデータを復元した後は、 ANALYZE TABLE手動で実行するか、TiDBがANALYZE自動的に実行するのを待つ必要があります。
v4.0.9では、 BRはデフォルトで統計情報をバックアップしますが、メモリ消費量が多すぎます。バックアッププロセスが確実に実行されるよう、v4.0.10以降では統計情報のバックアップはデフォルトで無効化されています。
テーブルに対してANALYZE実行しないと、TiDBは統計情報が不正確であるため最適な実行プランを選択できません。クエリパフォーマンスが重要でない場合は、 ANALYZE無視できます。
複数の復元タスクを同時に開始して、単一のクラスターのデータを復元できますか?
次の理由により、単一のクラスターのデータを復元するために複数の復元タスクを同時に開始することは強く推奨されません。
- BR がデータを復元すると、PD の一部のグローバル構成が変更されます。そのため、複数の復元タスクを同時に実行すると、これらの構成が誤って上書きされ、クラスタの状態が異常になる可能性があります。
- BR はデータの復元に大量のクラスター リソースを消費するため、実際には復元タスクを並列で実行しても復元速度は限られた範囲でしか向上しません。
- データの復元のために複数の復元タスクを並行して実行するテストは行われていないため、成功することは保証されません。
BR はテーブルのSHARD_ROW_ID_BITSおよびPRE_SPLIT_REGIONS情報をバックアップしますか? リストアされたテーブルには複数のリージョンがありますか?
はい。BRはテーブルのSHARD_ROW_ID_BITSとPRE_SPLIT_REGIONS情報をバックアップします。復元されたテーブルのデータも複数のリージョンに分割されます。
回復プロセスが中断された場合、すでに回復されたデータを削除して、回復を再度開始する必要がありますか?
いいえ、必要ありません。BR v7.1.0以降、ブレークポイントからのデータの再開がサポートされています。予期せぬ状況でリカバリが中断された場合は、リカバリタスクを再開するだけで、中断したところから再開されます。
リカバリが完了したら、特定のテーブルを削除して再度リカバリできますか?
はい、特定のテーブルを削除した後でも、そのテーブルを再度リカバリできます。ただし、リカバリできるのはDROP TABLEまたはTRUNCATE TABLEステートメントで削除されたテーブルのみであり、 DELETE FROMステートメントではリカバリできないことに注意してください。これは、 DELETE FROMではMVCCバージョンを更新して削除対象データをマークするだけで、実際のデータ削除はGC後に行われるためです。
統計情報を復元するときにBR が大量のメモリを消費するのはなぜですか?
v7.6.0より前のバージョンでは、 BRによってバックアップされた統計データはテーブル情報と共に保存され、リカバリ時にメモリにロードされます。そのため、バックアップ統計データが非常に大きい場合、 BRは大量のメモリを占有する必要があります。
バージョン7.6.0以降、バックアップ統計は特定のファイルに個別に保存されます。BRはテーブルの復元を開始するまで、どのテーブルの統計データもロードしないBR、メモリを節約できます。