バックアップと復元に関するよくある質問
このドキュメントには、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-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の値をより大きな数値に変更できます。
PITRの問題
PITRとクラスターフラッシュバックの違いは何ですか?
ユースケースの観点から見ると、PITR は通常、クラスターが完全にサービス停止になった場合、またはデータが破損して他のソリューションを使用して回復できない場合に、クラスターのデータを指定された時点に復元するために使用されます。 PITR を使用するには、データ回復用の新しいクラスターが必要です。クラスターのフラッシュバック機能は、ユーザーの誤操作やその他の要因によって引き起こされるデータ エラーのシナリオ向けに特別に設計されており、データ エラーが発生する前の最新のタイムスタンプにクラスターのデータをインプレースで復元できます。
ほとんどの場合、フラッシュバックは、RPO (ゼロに近い) と RTO がはるかに短いため、人的ミスによって引き起こされたデータ エラーに対しては、PITR よりも優れた回復ソリューションです。ただし、クラスターが完全に使用できない場合、現時点ではフラッシュバックを実行できないため、この場合クラスターを回復する唯一のソリューションは PITR です。したがって、PITR は、フラッシュバックよりも RPO (最大 5 分) と RTO が長いにもかかわらず、データベースのディザスタ リカバリ戦略を策定する際には常に必須のソリューションです。
アップストリーム データベースが物理インポート モードでTiDB Lightningを使用してデータをインポートすると、ログ バックアップ機能が使用できなくなります。なぜ？
現在、ログ バックアップ機能はTiDB Lightningに完全には適合していません。そのため、 TiDB Lightningの物理モードでインポートしたデータはログデータにバックアップできません。
ログ バックアップ タスクを作成するアップストリーム クラスターでは、データのインポートにTiDB Lightning物理モードを使用しないでください。代わりに、 TiDB Lightning論理モードを使用できます。物理モードを使用する必要がある場合は、インポートの完了後にスナップショット バックアップを実行して、PITR をスナップショット バックアップ後の時点に復元できるようにします。
インデックス追加の高速化機能が PITR と互換性がないのはなぜですか?
問題: #38045
現在、 インデックス加速度機能で作成されたインデックス データは PITR でバックアップできません。
したがって、PITR リカバリの完了後、 BR はインデックス アクセラレーションによって作成されたインデックス データを削除し、再作成します。インデックス アクセラレーションによって多数のインデックスが作成された場合、またはログ バックアップ中にインデックス データが大きい場合は、インデックスの作成後にフル バックアップを実行することをお勧めします。
クラスターはネットワーク パーティションの障害から回復しましたが、ログ バックアップ タスクの進行状況のチェックポイントはまだ再開されません。なぜ？
問題: #13126
クラスター内でネットワーク パーティションに障害が発生すると、バックアップ タスクはログのバックアップを続行できなくなります。一定の再試行時間が経過すると、タスクはERROR状態に設定されます。この時点で、バックアップ タスクは停止しました。
この問題を解決するには、 br log resumeコマンドを手動で実行してログ バックアップ タスクを再開する必要があります。
PITR を実行すると、 execute over region idエラーが返された場合はどうすればよいですか?
問題: #37207
この問題は通常、完全データ インポート中にログ バックアップを有効にし、その後 PITR を実行してデータ インポート中の特定の時点でデータを復元した場合に発生します。
具体的には、長時間 (24 時間など) に大量のホットスポット書き込みがあり、各 TiKV ノードの OPS が 50k/s を超えている場合に、この問題が発生する可能性があります (メトリクスは次のとおりです)。 Grafana: TiKV-詳細->バックアップ ログ->ハンドル イベント レート)。
データのインポート後にスナップショット バックアップを実行し、このスナップショット バックアップに基づいて PITR を実行することをお勧めします。
br restore pointコマンドを使用してダウンストリーム クラスターを復元した後、 TiFlashからデータにアクセスできなくなります。どうすればいいですか？
現在、PITR は復元フェーズ中にTiFlashにデータを直接書き込むことをサポートしていません。代わりに、br コマンドライン ツールはALTER TABLE table_name SET TIFLASH REPLICA *** DDL を実行してデータを複製します。したがって、 TiFlashレプリカは、PITR がデータの復元を完了した直後には使用できません。代わりに、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 またはDrainerの上流クラスターに複製できないのはなぜですか?
BRを使用して復元されたデータは、ダウンストリームに複製できません。これは、 BR がSST ファイルを直接インポートしますが、現在ダウンストリーム クラスターがアップストリームからこれらのファイルを取得できないためです。
v4.0.3 より前では、リストア中に生成された DDL ジョブにより、 TiCDC/ Drainerで予期しない DDL 実行が発生する可能性がありました。したがって、 TiCDC/ Drainerの上流クラスターでリストアを実行する必要がある場合は、 br コマンドライン ツールを使用してリストアされたすべてのテーブルを TiCDC/ Drainerブロック リストに追加します。
filter.rulesを使用して TiCDC のブロック リストを構成し、 syncer.ignore-tableを使用してDrainerのブロック リストを構成できます。
復元中にnew_collation_enabled不一致が報告されるのはなぜですか?
TiDB v6.0.0 以降、デフォルト値new_collations_enabled_on_first_bootstrapがfalseからtrueに変更されました。 BR は、上流クラスタのmysql.tidbテーブル内のnew_collation_enabled設定をバックアップし、この設定の値が上流クラスタと下流クラスタ間で一貫しているかどうかを確認します。値が一貫している場合、 BR は上流クラスターにバックアップされたデータを下流クラスターに安全に復元します。値が矛盾している場合、 BR はデータの復元を実行せず、エラーを報告します。
以前のバージョンの v6.0.0 の TiDB クラスターにデータをバックアップしており、このデータを v6.0.0 以降のバージョンの TiDB クラスターに復元するとします。この状況では、値new_collations_enabled_on_first_bootstrapがアップストリーム クラスターとダウンストリーム クラスター間で一致しているかどうかを手動で確認する必要があります。
- 値が一貫している場合は、restore コマンドに
--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 =...復元中にエラーが発生しました。
このエラーは、復元するクラスターの容量が不十分な場合に発生する可能性があります。このクラスターの監視メトリクスまたは TiKV ログを確認することで、原因をさらに確認できます。
この問題に対処するには、クラスター リソースをスケールアウトし、復元中の同時実行性を減らし、 RATE_LIMITオプションを有効にしてみてください。
リストアが失敗しthe entry too large, the max entry size is 6291456, the size of data is 7690800 」というエラー メッセージが表示された場合はどうすればよいですか?
--ddl-batch-size ～ 128 、またはそれより小さい値を設定すると、バッチで作成されるテーブルの数を減らすことができます。
BRを使用して1より大きい--ddl-batch-sizeの値を持つバックアップ データを復元すると、TiDB はテーブル作成の DDL ジョブを TiKV によって維持される DDL ジョブ キューに書き込みます。現時点では、ジョブ メッセージの最大値はデフォルトで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エラーが報告されます。
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 ファイル) にアクセスできる必要があります。デフォルトでは、 localstorageが使用されている場合、バックアップ ファイルが異なるノードに分散しているため、データを復元できません。したがって、各 TiKV ノードのバックアップ ファイルを他の TiKV ノードにコピーする必要があります。バックアップ データは、Amazon S3、Google Cloud Storage (GCS)、Azure Blob Storage、または NFS に保存することをお勧めします。
root を使用してbrを実行しようとしても無駄であった場合でも、 Permission denied 」またはNo such file or directoryエラーを処理するにはどうすればよいですか?
TiKV がバックアップ ディレクトリにアクセスできるかどうかを確認する必要があります。データをバックアップするには、TiKV に書き込み権限があるかどうかを確認してください。データを復元する場合は、読み取り権限があるかどうかを確認してください。
バックアップ操作中に、storageメディアがローカル ディスクまたはネットワーク ファイル システム (NFS) である場合、 brを起動するユーザーと TiKV を起動するユーザーが一致していることを確認してください ( brと TiKV が別のマシン上にある場合、ユーザーは' UID は一貫している必要があります)。そうしないと、 Permission denied問題が発生する可能性があります。
バックアップ ファイル (SST ファイル) は TiKV によって保存されるため、 rootユーザーとして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はバックアップ データ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.*'特に指定がない限り、 BR にmysqlテーブルを復元しないよう指示します。-f 'mysql.usertable'mysql.usertableを復元する必要があることを示します。
mysql.usertableのみを復元する必要がある場合は、次のコマンドを実行します。
br restore full -f 'mysql.usertable' -s $external_storage_url --with-sys-table
テーブルフィルターを設定した場合でも、 BR は次のシステム テーブルを復元しないことに注意してください。
- 統計テーブル (
mysql.stat_*) - システム変数テーブル (
mysql.tidb、mysql.global_variables) - その他のシステムテーブル
バックアップと復元についてその他知っておきたいこと
バックアップデータのサイズはどれくらいですか?バックアップのレプリカはありますか?
データのバックアップ中に、各リージョンのLeaderノード上にバックアップ ファイルが生成されます。バックアップのサイズはデータ サイズと等しく、冗長レプリカはありません。したがって、合計データ サイズは、TiKV データの合計数をレプリカの数で割ったものとほぼなります。
ただし、ローカルstorageからデータを復元する場合は、各 TiKV がすべてのバックアップ ファイルにアクセスできる必要があるため、レプリカの数は TiKV ノードの数と同じになります。
BRを使用したバックアップまたは復元後、監視ノードに表示されるディスク使用量が一貫していないのはなぜですか?
この不一致は、バックアップで使用されるデータ圧縮率がリストアで使用されるデフォルトの圧縮率と異なることが原因で発生します。チェックサムが成功した場合は、この問題を無視してかまいません。
BR がバックアップ データを復元した後、テーブルに対してANALYZEステートメントを実行して、テーブルとインデックス上の TiDB の統計を更新する必要がありますか?
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情報をバックアップします。復元されたテーブルのデータも複数のリージョンに分割されます。