TiDB のバックアップと復元の概要

Raftプロトコルと合理的な導入トポロジーに基づいて、TiDB はクラスターの高可用性を実現します。クラスター内のいくつかのノードに障害が発生しても、クラスターは引き続き使用可能です。これに基づいて、データの安全性をさらに確保するために、TiDB は自然災害や誤操作からデータを回復する最後の手段としてバックアップ & リストア (BR) 機能を提供します。

BR は次の要件を満たします。

• クラスター データを災害復旧 (DR) システムにバックアップし、RPO は最短 5 分で、災害シナリオでのデータ損失を軽減します。
• エラー イベントの前の時点にデータをロールバックすることで、アプリケーションからの誤操作のケースに対処します。
• 司法監督の要件を満たすために履歴データの監査を実行します。
• 本番環境のクローンを作成すると、トラブルシューティング、パフォーマンス チューニング、シミュレーション テストに便利です。

ご使用の前に

このセクションでは、制限事項、使用上のヒント、互換性の問題など、TiDB のバックアップと復元を使用するための前提条件について説明します。

制限

• PITR は、空のクラスターへのデータの復元のみをサポートします。
• PITR はクラスター レベルのリストアのみをサポートし、データベース レベルまたはテーブル レベルのリストアはサポートしません。
• PITR は、システム テーブルからのユーザー テーブルまたは特権テーブルのデータの復元をサポートしていません。
• BR は、クラスター上での複数のバックアップ タスクの同時実行をサポートしていません。
• PITR の実行中は、ログ バックアップ タスクを実行したり、TiCDC を使用してデータをダウンストリーム クラスターに複製したりすることはできません。

いくつかのヒント

スナップショットバックアップ:

• アプリケーションへの影響を最小限に抑えるために、バックアップ操作はオフピーク時間帯に実行することをお勧めします。
• 複数のバックアップまたは復元タスクを 1 つずつ実行することをお勧めします。複数のバックアップ タスクを並行して実行すると、パフォーマンスが低下します。さらに悪いことに、複数のタスク間の連携が不足すると、タスクが失敗し、クラスターのパフォーマンスに影響を与える可能性があります。

スナップショットの復元:

• BR は、ターゲット クラスターのリソースを可能な限り使用します。したがって、データを新しいクラスターまたはオフライン クラスターに復元することをお勧めします。データを本番クラスターに復元することは避けてください。そうしないと、アプリケーションが必然的に影響を受けます。

バックアップstorageとネットワーク構成:

• バックアップ データは、Amazon S3、GCS、または Azure Blob Storage と互換性のあるstorageシステムに保存することをお勧めします。
• BR、TiKV、およびバックアップstorageシステムに十分なネットワーク帯域幅があること、およびバックアップstorageシステムが十分な読み取りおよび書き込みパフォーマンス (IOPS) を提供できることを確認する必要があります。そうしないと、バックアップおよび復元中にパフォーマンスのボトルネックになる可能性があります。

バックアップと復元を使用する

BRの使用方法は、TiDB の導入方法によって異なります。このドキュメントでは、br コマンドライン ツールを使用して、オンプレミス展開で TiDB クラスター データをバックアップおよび復元する方法を紹介します。

他の展開シナリオでこの機能を使用する方法については、次のドキュメントを参照してください。

• TiDB Cloud上にデプロイされた TiDB のバックアップと復元 : TiDB クラスターをTiDB Cloudに作成することをお勧めします。 TiDB Cloud は、アプリケーションに集中できるようにするフルマネージド データベースを提供します。
• TiDB Operatorを使用したデータのバックアップと復元 : Kubernetes 上でTiDB Operatorを使用して TiDB クラスターをデプロイする場合は、Kubernetes CustomResourceDefinition (CRD) を使用してデータをバックアップおよび復元することをお勧めします。

BRの特徴

TiDB BR は次の機能を提供します。

• クラスター データのバックアップ: 特定の時点でのクラスターの完全なデータをバックアップする (フル バックアップ)、または TiDB 内のデータ変更をバックアップする (ログ バックアップ、ログとは TiKV における KV の変更を意味します) ことができます。

• バックアップデータを復元します。

  • 完全バックアップを復元することも、完全バックアップ内の特定のデータベースやテーブルを復元することもできます。
  • バックアップ データ (フル バックアップおよびログ バックアップ) に基づいて、ターゲット クラスタをバックアップ クラスタの任意の時点に復元できます。このタイプの復元は、ポイント イン タイム リカバリ (略して PITR) と呼ばれます。

クラスターデータのバックアップ

完全バックアップでは、特定の時点でのクラスターのすべてのデータがバックアップされます。 TiDB は、次の完全バックアップ方法をサポートしています。

• クラスターのスナップショットをバックアップする: TiDB クラスターのスナップショットには、特定の時点でのトランザクション的に一貫したデータが含まれています。詳細はスナップショットバックアップを参照してください。

完全バックアップは多くのstorage領域を占有し、特定の時点のクラスター データのみが含まれます。必要に応じて復元ポイントを選択する場合、つまりポイントインタイム リカバリ (PITR) を実行する場合は、次の 2 つのバックアップ方法を同時に使用できます。

• ログのバックアップを開始します。ログ バックアップの開始後、タスクはすべての TiKV ノードで実行を継続し、TiDB 増分データを小さなバッチで指定されたstorageに定期的にバックアップします。
• スナップショットバックアップを定期的に実行してください。クラスタ全体のデータをバックアップstorageにバックアップします。たとえば、毎日午前 0:00 にクラスタ スナップショット バックアップを実行します。

バックアップのパフォーマンスと TiDB クラスターへの影響

• クラスター内の CPU および I/O リソースが十分である場合、スナップショット バックアップによる TiDB クラスターへの影響は限定的であり、通常は 20% 未満にとどまります。 TiDB クラスターを適切に構成すると、この影響をさらに 10% 以下に最小限に抑えることができます。 CPU および I/O リソースが不十分な場合は、TiKV 構成項目backup.num-threadsを調整してバックアップ タスクで使用されるワーカー スレッドの数を変更し、TiDB クラスターに対するバックアップ タスクの影響を軽減できます。 TiKV ノードのバックアップ速度は拡張可能で、50 MB/秒から 100 MB/秒の範囲です。詳細については、 バックアップのパフォーマンスと影響を参照してください。
• ログ バックアップ タスクのみがある場合、クラスターへの影響は約 5% です。ログ バックアップでは、最後の更新後に生成されたすべての変更が 3 ～ 5 分ごとにバックアップstorageにフラッシュされ、最短 5 分で目標復旧時点 (RPO) を達成できます。

バックアップデータを復元する

バックアップ機能に応じて、フル リストアと PITR の 2 種類のリストアを実行できます。

• 完全バックアップを復元する

  • クラスターのスナップショット バックアップの復元: スナップショット バックアップ データを、空のクラスター、またはデータの競合がないクラスター (同じスキーマまたはテーブルを持つ) に復元できます。詳細はスナップショットバックアップを復元するを参照してください。さらに、バックアップ データから特定のデータベースまたはテーブルを復元し、不要なデータを除外することができます。詳細はバックアップデータから特定のデータベースまたはテーブルを復元するを参照してください。

• データを任意の時点に復元 (PITR)

  • br restore pointコマンドを実行すると、復旧時点より前の最新のスナップショット バックアップ データと、指定した時点のログ バックアップ データを復元できます。 BR は、リストア範囲を自動的に決定し、バックアップ データにアクセスし、ターゲット クラスタにデータを順番にリストアします。

パフォーマンスの復元と TiDB クラスターへの影響

• データの復元はスケーラブルな速度で実行されます。通常、速度は TiKV ノードあたり 100 MiB/秒です。 br新しいクラスターへのデータの復元のみをサポートし、ターゲット クラスターのリソースを可能な限り使用します。詳細については、 パフォーマンスと影響を復元するを参照してください。
• 各 TiKV ノードでは、PITR は 30 GiB/h でログ データを復元できます。詳細については、 PITR のパフォーマンスと影響を参照してください。

バックアップstorage

TiDB は、Amazon S3、Google Cloud Storage (GCS)、Azure Blob Storage、NFS、およびその他の S3 互換ファイルstorageサービスへのデータのバックアップをサポートしています。詳細については、次のドキュメントを参照してください。

• URIでバックアップstorageを指定する
• バックアップストレージへのアクセス権限を構成する

互換性

他の機能との互換性

一部の TiDB 機能が有効または無効になっている場合、バックアップと復元が失敗する可能性があります。これらの機能がバックアップおよび復元中に一貫して有効または無効にされていない場合、互換性の問題が発生する可能性があります。

バージョンの互換性

注記：

バックアップと復元には、TiDB クラスターと同じメジャー バージョンのBRを使用することをお勧めします。

バックアップと復元を実行する前に、 BR はTiDB クラスターのバージョンをそれ自体のバージョンと比較し、互換性をチェックします。バージョンに互換性がない場合、 BR はエラーを報告して終了します。バージョンチェックを強制的にスキップするには、 --check-requirements=falseを設定します。バージョンチェックをスキップすると、データに非互換性が生じる可能性があることに注意してください。

v7.0.0 から、TiDB は SQL ステートメントを使用したバックアップおよび復元操作の実行を段階的にサポートします。したがって、クラスター データをバックアップおよび復元する場合は、TiDB クラスターと同じメジャー バージョンのBRツールを使用し、メジャー バージョンをまたいでデータのバックアップおよび復元操作を実行しないことを強くお勧めします。これにより、復元操作のスムーズな実行とデータの整合性が確保されます。

TiDB v6.6.0 より前のBRの互換性情報は次のとおりです。

こちらも参照

• TiDB スナップショットのバックアップおよび復元ガイド
• TiDB ログのバックアップと PITR ガイド
• バックアップストレージ