チェックポイントの復元

スナップショットの復元やログの復元は、ディスクの枯渇やノードのクラッシュなどの回復可能なエラーにより中断される可能性があります。TiDB v7.1.0 より前では、エラーに対処した後でも中断前の復元の進行状況は無効になり、復元を最初からやり直す必要がありました。大規模なクラスターの場合、これにはかなりの追加コストがかかります。

TiDB v7.1.0 以降、バックアップと復元 (BR) にチェックポイント復元機能が導入され、中断された復元を続行できるようになりました。この機能により、中断された復元の回復の進行状況のほとんどを保持できます。

アプリケーションシナリオ

TiDB クラスターが大きく、障害後に再度リストアする余裕がない場合は、チェックポイントリストア機能を使用できます。br コマンドラインツール (以下、 brと略します) は、リストアされたシャードを定期的に記録します。これにより、次回のリストア再試行では、異常終了に近い回復進行ポイントを使用できます。

実装の詳細

チェックポイント復元の実装は、スナップショット復元とログ復元の 2 つの部分に分かれています。

スナップショットの復元

スナップショット復元の実装はスナップショットバックアップと同様です。 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 ノード (meta-kv) によってバックアップされたデータメタデータをタイムスタンプ順に復元するプロセスです。チェックポイント復元では、まず、meta-kv データに基づいて、バックアップクラスターと復元されたクラスターの間に 1 対 1 の ID マッピング関係を確立します。これにより、meta-kv の ID が複数の復元再試行間で一貫して維持され、meta-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停止する原理は、 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に復元されたデータのメタ情報を永続化できません。5 br 30 秒ごとにメタ情報を永続化するため、中断前の最後の 30 秒間に復元されたデータは永続化できず、次の再試行時に再度復元する必要があります。

復元中にクラスターデータの変更を避ける

復元が失敗した後は、クラスター内でのテーブルの書き込み、削除、または作成を避けてください。これは、バックアップデータにテーブル名を変更するための DDL 操作が含まれている可能性があるためです。クラスターデータを変更すると、チェックポイント復元では、削除されたテーブルまたは既存のテーブルが外部操作の結果であるかどうかを判断できず、次回の復元再試行の精度に影響します。