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

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

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

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

使用する前に

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

制限

• PITR は空のクラスターへのデータの復元のみをサポートします。
• PITR はクラスター レベルの復元のみをサポートし、データベース レベルまたはテーブル レベルの復元はサポートしません。
• PITR は、システム テーブルからユーザー テーブルまたは権限テーブルのデータを復元することをサポートしていません。
• BR は、クラスター上で複数のバックアップ タスクを同時に実行することをサポートしていません。
• 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 Cloudに TiDB クラスターを作成することをお勧めします。TiDB TiDB Cloud は、アプリケーションに集中できるように、完全に管理されたデータベースを提供します。
• TiDB Operatorを使用したデータのバックアップと復元 : Kubernetes 上でTiDB Operator を使用して TiDB クラスターをデプロイする場合は、Kubernetes CustomResourceDefinition (CRD) を使用してデータをバックアップおよび復元することをお勧めします。

BR機能

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

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

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

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

クラスターデータをバックアップする

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

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

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

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

バックアップのパフォーマンスと 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/秒です。詳細については、 パフォーマンスとインパクトを回復する参照してください。
• 各 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ツールを使用し、メジャー バージョン間でデータのバックアップおよび復元操作を実行しないようにすることを強くお勧めします。これにより、復元操作のスムーズな実行とデータの一貫性が確保されます。v7.6.0 以降、 BR はデフォルトで一部のmysqlシステム テーブルにデータを復元します。つまり、 --with-sys-tableオプションはデフォルトでtrueに設定されています。異なるバージョンの TiDB クラスターにデータを復元するときに、システム テーブルのスキーマが異なるために[BR:Restore:ErrRestoreIncompatibleSys]incompatible system tableに似たエラーが発生した場合は、 --with-sys-table=false設定してシステム テーブルの復元をスキップし、このエラーを回避できます。

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

参照

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