チェックポイントバックアップ

スナップショット バックアップは、ディスクの枯渇やノードのクラッシュなどの回復可能なエラーにより中断される場合があります。 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にバックアップされたデータのメタ情報を永続化できなくなります。 br 30 秒ごとにメタ情報を永続化するため、中断前の最後の 30 秒間にバックアップされたデータは永続化できないため、次の再試行時に再度バックアップする必要があります。

このページは役に立ちましたか?