TiDB のバックアップと復元の概要
Raftプロトコルと合理的な展開トポロジに基づいて、TiDB はクラスターの高可用性を実現します。クラスター内のいくつかのノードに障害が発生した場合でも、クラスターは引き続き使用できます。これに基づいて、データの安全性をさらに確保するために、TiDB は、自然災害や誤操作からデータを回復するための最後の手段として、バックアップと復元 (BR) 機能を提供します。
BR は次の要件を満たしています。
- 最短 5 分の RPO でクラスター データをディザスター リカバリー (DR) システムにバックアップし、災害シナリオでのデータ損失を減らします。
- エラー イベントの前の時点にデータをロールバックすることにより、アプリケーションからの誤操作のケースを処理します。
- 司法監督の要件を満たすために履歴データの監査を実行します。
- 本番環境のクローンを作成します。これは、トラブルシューティング、パフォーマンス チューニング、およびシミュレーション テストに便利です。
ご使用になる前に
このセクションでは、制限、使用上のヒント、互換性の問題など、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 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 クラスターへの影響
- TiDB クラスターに対するバックアップの影響は 20% 未満に抑えられており、TiDB クラスターを適切に構成することで、この値を 10% 以下に減らすことができます。 TiKV ノードのバックアップ速度はスケーラブルで、50 MB/秒から 100 MB/秒の範囲です。詳細については、 バックアップのパフォーマンスと影響を参照してください。
- ログ バックアップ タスクのみの場合、クラスターへの影響は約 5% です。ログ バックアップは、最後の更新後に生成されたすべての変更を 3 ~ 5 分ごとにバックアップstorageにフラッシュします。これにより、目標復旧時点 (RPO) を 5 分で達成できます。
バックアップデータの復元
バックアップ機能に対応して、フル リストアと 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サービスへのデータのバックアップをサポートしています。詳細については、次のドキュメントを参照してください。
互換性
他の機能との互換性
一部の TiDB 機能が有効または無効になっていると、バックアップと復元がうまくいかないことがあります。これらの機能がバックアップと復元中に一貫して有効または無効にされない場合、互換性の問題が発生する可能性があります。
特徴 | 問題 | 解決 |
---|---|---|
GBK 文字セット | v5.4.0 より前のバージョンのBRは、 charset=GBK テーブルの復元をサポートしていません。 v5.4.0 より前の TiDB クラスターへのcharset=GBK テーブルの復元をサポートするBRのバージョンはありません。 | |
クラスタ化されたインデックス | #565 | リストア中のtidb_enable_clustered_index グローバル変数の値がバックアップ中の値と一致していることを確認してください。そうしないと、 default not found エラーやデータ インデックスの不整合など、データの不整合が発生する可能性があります。 |
新しい照合順序 | #352 | 復元中のnew_collations_enabled_on_first_bootstrap 変数の値がバックアップ中の値と一致していることを確認してください。そうしないと、不整合なデータ インデックスが発生し、チェックサムが渡されない可能性があります。詳細については、 FAQ - BR がnew_collations_enabled_on_first_bootstrap の不一致を報告するのはなぜですか?を参照してください。 |
グローバル一時テーブル | v5.3.0 以降のバージョンのBR を使用してデータをバックアップおよび復元していることを確認してください。そうしないと、バッキングされたグローバル一時テーブルの定義でエラーが発生します。 | |
TiDB Lightning物理インポート | 上流のデータベースがTiDB Lightningの物理インポートモードを使用している場合、ログバックアップでデータをバックアップできません。データのインポート後に完全バックアップを実行することをお勧めします。詳細については、 アップストリーム データベースが物理インポート モードでTiDB Lightningを使用してデータをインポートすると、ログ バックアップ機能が使用できなくなります。なぜ?を参照してください。 |
バージョンの互換性
バックアップとリストアを実行する前に、 BR はTiDB クラスターのバージョンを自身のものと比較して確認します。メジャー バージョンの不一致がある場合、 BR は終了するよう促します。バージョン チェックを強制的にスキップするには、 --check-requirements=false
を設定します。バージョン チェックをスキップすると、互換性が失われる可能性があることに注意してください。
バックアップ版(縦)\ 復元版(横) | TiDB v6.0 に復元する | TiDB v6.1 に復元する | TiDB v6.2 に復元する | TiDB v6.3 に復元する | TiDB v6.4 に復元する | TiDB v6.5 に復元する |
---|---|---|---|---|---|---|
TiDB v6.0 スナップショット バックアップ | 互換性 | 互換性 | 互換性 | 互換性 | 互換性 | 互換性 |
TiDB v6.1 スナップショット バックアップ | 互換性あり (既知の問題#36379 : バックアップ データに空のスキーマが含まれている場合、 BR がエラーを報告する場合があります。) | 互換性 | 互換性 | 互換性 | 互換性 | 互換性 |
TiDB v6.2 スナップショット バックアップ | 互換性あり (既知の問題#36379 : バックアップ データに空のスキーマが含まれている場合、 BR がエラーを報告する場合があります。) | 互換性 | 互換性 | 互換性 | 互換性 | 互換性 |
TiDB v6.3 スナップショット バックアップ | 互換性あり (既知の問題#36379 : バックアップ データに空のスキーマが含まれている場合、 BR がエラーを報告する場合があります。) | 互換性 | 互換性 | 互換性 | 互換性 | 互換性 |
TiDB v6.3 ログ バックアップ | なし | なし | 非互換 | 互換性 | 互換性 | 互換性 |
TiDB v6.4 ログ バックアップ | なし | なし | 非互換 | 互換性 | 互換性 | 互換性 |
TiDB v6.5 ログ バックアップ | なし | なし | 非互換 | 互換性 | 互換性 | 互換性 |