チェックポイント復元
スナップショットリストアまたはログリストアは、ディスク枯渇やノードクラッシュなどの回復可能なエラーにより中断される可能性があります。TiDB v7.1.0より前のバージョンでは、エラーに対処した後でも中断前のリカバリの進行状況が無効になり、リストアを最初からやり直す必要がありました。大規模クラスターでは、これはかなりの追加コストが発生します。
TiDB v7.1.0以降、バックアップ＆リストア（BR）にチェックポイント・リストア機能が導入され、中断されたリストアを再開できるようになりました。この機能により、中断されたリストアのリカバリ進行状況の大部分を保持できます。
アプリケーションシナリオ
TiDBクラスタが大規模で、障害発生後に再度リストアを行う余裕がない場合は、チェックポイントリストア機能を使用できます。brコマンドラインツール（以下、 br ）は、リストアされたシャードを定期的に記録します。これにより、次回のリストア再試行では、異常終了に近いリカバリ進捗ポイントを使用できます。
実施原則
チェックポイント復元の実装は、スナップショット復元とログ復元の2つの部分に分かれています。詳細については、 実装の詳細参照してください。
スナップショットの復元
スナップショット復元の実装はスナップショットバックアップと同様です。3 br 、キー範囲（リージョン）内のすべてのSSTファイルを一括で復元します。復元が完了すると、 brこの範囲と復元されたクラスタテーブルのテーブルIDを記録します。チェックポイント復元機能は、復元されたキー範囲を永続化するために、新しい復元情報を定期的に外部storageにアップロードします。
br復元を再試行する際、外部storageから復元されたキー範囲を読み取り、対応するテーブル ID と照合します。復元中、 brチェックポイント復元で記録されたキー範囲と重複し、同じテーブル ID を持つキー範囲をスキップします。
brリストアを再試行する前にテーブルを削除した場合、再試行時に新しく作成されたテーブルのテーブルIDは、以前のチェックポイントリストアで記録されたテーブルIDと異なります。この場合、 br以前のチェックポイントリストア情報をバイパスし、テーブルを再度リストアします。つまり、新しいIDを持つ同じテーブルは、古いIDのチェックポイントリストア情報を無視し、新しいIDに対応する新しいチェックポイントリストア情報を記録することになります。
MVCC (Multi-Version Concurrency Control) メカニズムを使用しているため、指定されたタイムスタンプを持つデータを順序なしで繰り返し書き込むことができます。
スナップショット復元を使用してデータベースまたはテーブルのDDLを復元する場合、パラメータifExistsが追加されます。既に作成済みとみなされる既存のデータベースまたはテーブルの場合、パラメータbrを指定すると復元は自動的にスキップされます。
ログの復元
ログリストアは、TiKVノードによってバックアップされたデータメタデータ（メタKV）をタイムスタンプ順にリストアするプロセスです。チェックポイントリストアではまず、メタKVデータに基づいて、バックアップクラスタとリストアされたクラスタ間の1対1のIDマッピング関係を確立します。これにより、メタKVのIDが複数回のリストア試行間で一貫性を保ち、メタKVを再度リストアできるようになります。
スナップショットバックアップファイルとは異なり、ログバックアップファイルの範囲は重複する可能性があります。そのため、キー範囲を復旧進捗メタデータとして直接使用することはできません。また、ログバックアップファイルの数が多すぎる場合もあります。ただし、各ログバックアップファイルは、ログバックアップメタデータ内で固定の位置を持ちます。つまり、ログバックアップメタデータ内の一意の位置を、復旧進捗メタデータとして各ログバックアップファイルに割り当てることができます。
ログバックアップメタデータには、ファイルメタデータの配列が含まれます。配列内の各ファイルメタデータは、複数のログバックアップファイルで構成されたファイルを表します。ファイルメタデータには、連結されたファイル内のログバックアップファイルのオフセットとサイズが記録されます。したがって、トリプル「 br (log backup metadata name, file metadata array offset, log backup file array offset)を使用してログバックアップファイルを一意に識別できます。
使用制限
チェックポイント復元はGCメカニズムに依存しており、復元されたすべてのデータを記録することはできません。詳細については、以下のセクションで説明します。
GCは一時停止されます
ログの復元中は、復元されたデータの順序が不規則であるため、キーの削除レコードが書き込みレコードよりも先に復元される可能性があります。このタイミングでGCが起動されると、キーのすべてのデータが削除され、GCはキーのそれ以降の書き込みレコードを処理できなくなります。このような状況を回避するため、 brログの復元中にGCを一時停止します。3 br途中で終了した場合、GCは一時停止状態のままになります。
ログの復元が完了すると、GCは手動で起動することなく自動的に再起動されます。ただし、復元を続行しない場合は、以下の手順でGCを手動で有効にすることができます。
br GCを一時停止する原理は、 SET config tikv gc.ratio-threshold = -1.0実行してgc.ratio-threshold負の数に設定し、GCを一時停止することです。 gc.ratio-thresholdの値を変更することで、GCを手動で有効にすることができます。例えば、デフォルト値にリセットするには、 SET config tikv gc.ratio-threshold = 1.1実行します。
一部のデータは再度復元する必要があります
br復元を再試行すると、復元中のデータやチェックポイントによって記録されていないデータなど、復元されたデータの一部を再度復元する必要がある場合があります。
中断の原因がエラーである場合、
br終了前に復元されたデータのメタ情報を保持します。この場合、次回の再試行では復元中のデータのみを再度復元する必要があります。brプロセスがシステムによって中断された場合、br外部storageに復元されたデータのメタ情報を永続化できません。5br30秒ごとにメタ情報を永続化するため、中断前の30秒間に復元されたデータは永続化できず、次回の再試行時に再度復元する必要があります。
復元中にクラスタデータを変更しないようにする
リストアに失敗した後は、クラスタ内でのテーブルの書き込み、削除、または作成は避けてください。バックアップデータには、テーブル名変更のためのDDL操作が含まれている可能性があるためです。クラスタデータを変更すると、チェックポイントリストアでは、削除されたテーブルまたは既存のテーブルが外部操作によるものかどうかを判断できず、次回のリストア再試行の精度に影響します。
クロスメジャーバージョンのチェックポイントリカバリは推奨されません
メジャーバージョン間のチェックポイントリカバリは推奨されません。v8.5.0より前のLong-Term Support（LTS）バージョンを使用してbrリカバリが失敗したクラスターの場合、v8.5.0以降のLTSバージョンを使用してリカバリを続行することはできません。また、その逆も同様です。
実装の詳細
チェックポイント復元操作は、スナップショット復元と PITR 復元の 2 つの部分に分かれています。
スナップショットの復元
初期復元中に、 brターゲットクラスタに__TiDB_BR_Temporary_Snapshot_Restore_Checkpointデータベースを作成します。このデータベースには、チェックポイントデータ、上流クラスタID、およびバックアップデータの BackupTS が記録されます。
復元が失敗した場合は、同じコマンドを使用して再試行できます。1 br __TiDB_BR_Temporary_Snapshot_Restore_Checkpointデータベースからチェックポイント情報を自動的に読み取り、最後の復元ポイントから再開します。
リストアに失敗し、異なるチェックポイント情報を持つバックアップデータを同じクラスタにリストアしようとすると、 brエラーを報告します。これは、現在の上流クラスタIDまたはBackupTSがチェックポイントレコードと異なることを示しています。リストアクラスタがクリーンアップされている場合は、 __TiDB_BR_Temporary_Snapshot_Restore_Checkpointデータベースを手動で削除し、別のバックアップで再試行できます。
PITR復元
PITR（ポイントインタイムリカバリ） 、スナップショットの復元フェーズとログの復元フェーズで構成されます。
初期リストアでは、まずbrがスナップショットリストアフェーズに入ります。このフェーズは、前のスナップショットの復元と同じプロセスに従います。BRは、チェックポイントデータ、上流クラスタID、およびバックアップデータのBackupTS（つまり、ログリストアの開始時点start-ts ）を__TiDB_BR_Temporary_Snapshot_Restore_Checkpointデータベースに記録します。このフェーズでリストアが失敗した場合、チェックポイントリストアを再開する際にログリストアのstart-ts調整することはできません。
初期復元中にログ復元フェーズに入ると、 brターゲットクラスタに__TiDB_BR_Temporary_Log_Restore_Checkpointデータベースを作成します。このデータベースには、チェックポイントデータ、アップストリームクラスタID、および復元時間範囲（ start-tsとrestored-ts ）が記録されます。このフェーズで復元に失敗した場合は、再試行時にチェックポイントデータベースに記録されているのと同じstart-tsとrestored-ts指定する必要があります。そうでない場合、 brエラーを報告し、現在指定されている復元時間範囲またはアップストリームクラスタIDがチェックポイントレコードと異なることを通知します。復元クラスタがクリーンアップされている場合は、 __TiDB_BR_Temporary_Log_Restore_Checkpointデータベースを手動で削除し、別のバックアップで再試行できます。
初期リストア中のログリストアフェーズに入る前に、 br restored-ts時点における上流および下流のクラスタデータベースとテーブルIDのマッピングを構築します。このマッピングはシステムテーブルmysql.tidb_pitr_id_mapに保存され、データベースIDとテーブルIDの重複割り当てを防止します。7 mysql.tidb_pitr_id_mapデータを削除すると、PITRリストアデータの不整合が発生する可能性があります。