TiDBのバックアップと復元の概要
TiDBは、 Raftプロトコルと適切なデプロイメントトポロジーに基づいて、クラスタの高い可用性を実現しています。クラスタ内のノードがいくつか故障しても、クラスタは引き続き利用可能です。さらにデータの安全性を確保するため、TiDBは、自然災害や誤操作からデータを復旧するための最終手段として、バックアップ＆リストア（BR）機能を提供しています。
BRは以下の要件を満たしています。
- クラスターデータを最短5分のRPO（目標復旧時点）でディザスタリカバリ（DR）システムにバックアップすることで、災害発生時のデータ損失を軽減します。
- アプリケーションの動作不良が発生した場合は、エラー発生前の時点までデータをロールバックすることで対処します。
- 司法監督の要件を満たすために、履歴データの監査を実施する。
- 本番環境を複製することで、トラブルシューティング、パフォーマンスチューニング、シミュレーションテストに便利になります。
使用する前に
このセクションでは、TiDB のバックアップとリストアを使用するための前提条件について説明します。これには、制限事項、使用上のヒント、互換性の問題が含まれます。BR ツールと他の機能またはバージョンとの互換性性の詳細については、 を参照してください。
制限
- PITRは、空のクラスターへのデータ復元のみをサポートしています。
- PITRは、システムテーブルからユーザーテーブルまたは権限テーブルのデータを復元することをサポートしていません。
- BRは、クラスター上で複数のバックアップタスクを同時に実行することをサポートしていません。
- 復元中のテーブルをバックアップすることは推奨されません。バックアップされたデータに問題が発生する可能性があるためです。
- PITRを使用してクラスタを復元する場合、ログバックアップタスクを実行したり、TiCDCを使用してデータをダウンストリームクラスタにレプリケートしたりすることはできません。
いくつかのヒント
スナップショットバックアップ:
- アプリケーションへの影響を最小限に抑えるため、バックアップ作業はピーク時以外の時間帯に行うことをお勧めします。
- 複数のバックアップまたはリストアタスクは、一つずつ実行することをお勧めします。複数のバックアップタスクを並行して実行すると、パフォーマンスが低下します。さらに悪いことに、複数のタスク間の連携が不足すると、タスクの失敗やクラスタのパフォーマンス低下につながる可能性があります。
スナップショット復元:
- 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 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時にクラスタのスナップショットバックアップを実行します。
バックアップのパフォーマンスとTiDBクラスタへの影響
- クラスタのCPUとI/Oリソースが十分な場合、スナップショットバックアップがTiDBクラスタに与える影響は限定的で、通常は20%未満に抑えられます。TiDBクラスタを適切に構成することで、この影響をさらに10%以下にまで最小限に抑えることができます。CPUとI/Oリソースが不足している場合は、TiKV構成項目
backup.num-threadsを調整して、バックアップタスクで使用されるワーカースレッド数を変更し、バックアップタスクがTiDBクラスタに与える影響を軽減できます。TiKVノードのバックアップ速度はスケーラブルで、50MB/秒から100MB/秒の範囲です。詳細については、 とバックアップのパフォーマンスと影響参照してください。 - ログバックアップタスクのみの場合、クラスタへの影響は約5%です。ログバックアップは、3～5分ごとに最後の更新後に生成されたすべての変更をバックアップstorageにフラッシュするため、最短5分のリカバリポイント目標（RPO）を実現できます。
バックアップデータを復元する
バックアップ機能に対応して、完全復元とPITRの2種類の復元を実行できます。
フルバックアップを復元する
- クラスターのスナップショット バックアップの復元: スナップショット バックアップ データを、空のクラスター、またはデータの競合がないクラスター (同じスキーマまたはテーブルを持つ) に復元できます。詳細については、 スナップショットバックアップを復元する参照してください。さらに、バックアップ データから特定のデータベースまたはテーブルを復元し、不要なデータを除外することができます。詳細については、 バックアップデータから特定のデータベースまたはテーブルを復元する参照してください。
任意の時点へのデータ復元（PITR）
br restore pointコマンドを実行すると、リカバリ時点より前の最新のスナップショットバックアップデータを復元し、指定した時点までのバックアップデータをログに記録できます。BRは復元範囲を自動的に判断し、バックアップデータにアクセスして、ターゲットクラスタにデータを復元します。
TiDBクラスターのパフォーマンスと影響を回復する
- データの復元はスケーラブルな速度で実行されます。通常、速度は TiKV ノードあたり 1 GiB/秒です。詳細については、 パフォーマンスとインパクトを回復をご覧ください。
- 各 TiKV ノードでは、PITR は 30 GiB/h でログ データを復元できます。詳細については、 PITRのパフォーマンスと影響ご覧ください。
バックアップstorage
TiDBは、Amazon S3、Google Cloud Storage（GCS）、Azure Blob Storage、NFS、およびその他のS3互換ファイルstorageサービスへのデータバックアップをサポートしています。詳細については、以下のドキュメントを参照してください。
互換性
他の機能との互換性
TiDBの一部の機能が有効化または無効化されている場合、バックアップと復元が正常に動作しない可能性があります。バックアップおよび復元時にこれらの機能が一貫して有効化または無効化されていない場合、互換性の問題が発生する可能性があります。
バージョン互換性
注記：
バックアップおよび復元には、TiDBクラスタと同じメジャーバージョンのBRを使用することをお勧めします。
バックアップとリストアを実行する前に、 BR はTiDB クラスタのバージョンを自身のバージョンと比較し、互換性を確認します。バージョンに互換性がない場合、 BR はエラーを報告して終了します。バージョンチェックを強制的にスキップするには、 --check-requirements=falseを設定します。バージョンチェックをスキップすると、データに互換性の問題が生じる可能性があることに注意してください。
バージョン 7.0.0 以降、TiDB は SQL ステートメントによるバックアップおよびリストア操作を段階的にサポートしています。そのため、クラスタ データのバックアップおよびリストアを行う際には、TiDB クラスタと同じメジャー バージョンのBRツールを使用することを強く推奨します。また、メジャー バージョンをまたいでのデータ バックアップおよびリストア操作は避けてください。これにより、リストア操作のスムーズな実行とデータの一貫性が確保されます。バージョン 7.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.5.0間のBRバージョン互換性マトリックス
このセクションでは、TiDB v6.5.0からv8.5.0までのすべての長期サポート（LTS）バージョン（v6.5.0、v7.1.0、v7.5.0、v8.1.0、v8.5.0を含む）のBR互換性情報について説明します。
注記：
- 既知の問題：v7.2.0以降、新規作成されたクラスタの一部のシステムテーブルフィールドは、大文字と小文字を区別しなくなります。ただし、v7.2.0より前のバージョンからv7.2.0以降にオンラインでアップグレードされたクラスタの場合、対応するシステムテーブルフィールドは引き続き大文字と小文字を区別します。これら2種類のクラスタ間でシステムテーブルを含むバックアップおよびリストア操作を行うと、失敗する可能性があります。詳細については、 問題番号43717を参照してください。
- バージョン8.5.5以降、 BRは
--sys-check-collationパラメータを使用してシステムテーブルを復元する際に、照合順序の互換性チェックをサポートするようになりました。復元中、 BRはターゲットクラスタ照合順序で大文字小文字の競合が存在するかどうかを確認します。データがターゲット照合順序と互換性がある場合、 BRは以前のバージョンからのバックアップを正常に復元できます。そうでない場合、 BRはエラーを報告して復元を終了します。
以下の表は、フルバックアップの互換性マトリックスを示しています。なお、表の情報はすべて新規作成されたクラスターに適用されます。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.*'などです。-該当するシナリオに互換性の制限がないことを意味します。
