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

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

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

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

使用する前に

このセクションでは、TiDB バックアップとリストアを使用するための前提条件（制限事項、使用上のヒント、互換性の問題など）について説明します。BRBRと他の機能またはバージョンとの互換性の詳細については、 互換性参照してください。

制限

• 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ノードあたり1GiB/秒の速度です。詳細については、 パフォーマンスとインパクトを回復する参照してください。
• 各TiKVノードでは、PITRによりログデータを30GiB/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 v6.6.0 より前のBRの互換性情報は次のとおりです。

TiDB v6.5.0 と v8.1.0 間のBRバージョン互換性マトリックス

このセクションでは、TiDB v6.5.0 から v8.1.0 (v6.5.0、v7.1.0、v7.5.0、v8.1.0 を含む) までの長期サポート（LTS）バージョンすべてに関するBR互換性情報を紹介します。

注記：

既知の問題：バージョン7.2.0以降、新規作成されたクラスターの一部のシステムテーブルフィールドでは、大文字と小文字が区別されません。ただし、バージョン7.2.0より前のバージョンからバージョン7.2.0以降にオンラインアップグレードされたクラスターでは、対応するシステムテーブルフィールドの大文字と小文字は区別されます。これらの2種類のクラスター間でシステムテーブルを含むバックアップおよびリストア操作が失敗する可能性があります。詳細については、 問題番号 #43717参照してください。

以下の表は、フルバックアップの互換性マトリックスを示しています。表のすべての情報は、新規に作成されたクラスターに適用されることに注意してください。v7.2.0より前のバージョンからv7.2.0以降にアップグレードされたクラスターの動作は、v7.1.0からのバックアップの動作と一致します。

以下の表は、ログバックアップの互換性マトリックスを示しています。表のすべての情報は、新規に作成されたクラスターに適用されることに注意してください。v7.2.0より前のバージョンからv7.2.0以降にアップグレードされたクラスターの動作は、v7.1.0からのバックアップの動作と一致します。

注記：

• システム テーブル以外のデータのみをバックアップする場合 (完全バックアップまたはログ バックアップ)、すべてのバージョンは相互に互換性があります。
• mysqlシステム テーブルの復元に互換性がないシナリオでは、 --with-sys-table=false設定してすべてのシステム テーブルの復元をスキップするか、よりきめ細かいフィルターを使用して互換性のないシステム テーブルのみをスキップすることで、問題を解決できます (例: --filter '*.*' --filter "__TiDB_BR_Temporary_*.*" --filter '!mysql.*' --filter 'mysql.bind_info' --filter 'mysql.user' --filter 'mysql.global_priv' --filter 'mysql.global_grants' --filter 'mysql.default_roles' --filter 'mysql.role_edges' --filter '!sys.*' --filter '!INFORMATION_SCHEMA.*' --filter '!PERFORMANCE_SCHEMA.*' --filter '!METRICS_SCHEMA.*' --filter '!INSPECTION_SCHEMA.*' )。
• - 、対応するシナリオに互換性の制限がないことを意味します。

参照

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