チェックポイントバックアップ
スナップショット バックアップは、ディスクの枯渇やノードのクラッシュなどの回復可能なエラーにより中断される場合があります。 TiDB v6.5.0 より前では、エラーが解決された後でも中断前にバックアップされたデータは無効になるため、バックアップを最初から開始する必要がありました。大規模なクラスターの場合、これにはかなりの追加コストがかかります。
TiDB v6.5.0 では、バックアップ & リストア (BR) にチェックポイント バックアップ機能が導入され、中断されたバックアップを継続できるようになりました。この機能により、中断されたバックアップのほとんどのデータを保持できます。
アプリケーションシナリオ
TiDB クラスターが大きく、障害後に再度バックアップする余裕がない場合は、チェックポイント バックアップ機能を使用できます。 br コマンドライン ツール (以下、 brと呼びます) は、バックアップされたシャードを定期的に記録します。このようにして、次回のバックアップの再試行では、異常終了に近いバックアップの進行状況を使用できます。
実装の詳細
スナップショット バックアップ中、 brテーブルを対応するキー スペースにエンコードし、バックアップ RPC リクエストを生成してから TiKV ノードに送信します。バックアップ要求を受信した後、TiKV ノードは要求された範囲内のデータをバックアップします。 TiKV ノードは、リージョンのデータのバックアップを完了するたびに、この範囲のバックアップ情報をbrに返します。
br 、TiKV ノードから返された情報を記録します。これはbrバックアップされたキー範囲を取得するのに役立ちます。チェックポイント バックアップ機能は、バックアップされたキー範囲を保持できるように、新しいバックアップ情報を外部storageに定期的にアップロードします。
brはバックアップを再試行するときに、外部storageからバックアップされたキー範囲を読み取り、バックアップ タスクのキー範囲と比較します。差分データは、チェックポイント バックアップでまだバックアップする必要があるキー範囲を決定するのにbrます。
使用制限
チェックポイント バックアップは GC メカニズムに依存しているため、バックアップされたすべてのデータを回復することはできません。以下のセクションで詳細を説明します。
バックアップの再試行は GC の前に行う必要があります
バックアップ中、データがガベージ コレクションされるのを避けるために、 br PD 内のバックアップ スナップショットのgc-safepointを定期的に更新します。 br終了すると、 gc-safepoint更新が間に合わなくなります。その結果、次のバックアップの再試行前に、データがガベージ コレクションされる可能性があります。
この状況を回避するために、 gcttlが指定されていない場合、 brデフォルトでgc-safepointを約 1 時間保持します。必要に応じて、 gcttlパラメータを設定して保存期間を延長できます。
次の例では、保持期間gc-safepointを延長するためにgcttl ～ 15 時間 (54000 秒) を設定します。
br backup full \
--storage local:///br_data/ --pd "${PD_IP}:2379" \
--gcttl 54000
注記：
バックアップ前に作成された
gc-safepointスナップショット バックアップの完了後に削除されます。手動で削除する必要はありません。
一部のデータは再度バックアップする必要があります
バックアップbr試行すると、バックアップ中のデータやチェックポイントによって記録されなかったデータなど、バックアップされた一部のデータを再度バックアップする必要がある場合があります。
中断がエラーによって引き起こされた場合、
brは終了前にバックアップされたデータのメタ情報を永続化します。この場合、次回の再試行では、バックアップ中のデータのみを再度バックアップする必要があります。brプロセスがシステムによって中断されると、br外部storageにバックアップされたデータのメタ情報を永続化できなくなります。br30 秒ごとにメタ情報を永続化するため、中断前の最後の 30 秒間にバックアップされたデータは永続化できないため、次の再試行時に再度バックアップする必要があります。