TiDB バックアップと復元の使用法の概要
このドキュメントでは、バックアップ方法の選択方法、バックアップ データの管理方法、バックアップおよび復元ツールのインストールおよび展開方法など、TiDB のバックアップおよび復元機能を使用するベスト プラクティスについて説明します。
推奨される実践方法
TiDB のバックアップおよび復元機能を使用する前に、推奨されるバックアップおよび復元ソリューションを理解しておくことをお勧めします。
データをバックアップするにはどうすればよいですか?
TiDB は 2 種類のバックアップを提供します。どれを使えばいいのでしょうか？完全バックアップには、特定の時点でのクラスターの完全なデータが含まれます。ログ バックアップには、TiDB に書き込まれたデータ変更が含まれます。両方のタイプのバックアップを同時に使用することをお勧めします。
- ログ バックアップの開始:
br log startコマンドを実行して、ログ バックアップ タスクを開始します。その後、タスクはすべての TiKV ノードで実行を継続し、TiDB データの変更を指定されたstorageに小さなバッチで定期的にバックアップします。 - 定期的にスナップショット (フル) バックアップを実行する:
br backup fullコマンドを実行して、クラスターのスナップショットを指定したstorageにバックアップします。たとえば、毎日午前 0 時にクラスターのスナップショットをバックアップします。
バックアップデータはどのように管理すればいいのでしょうか？
BR は基本的なバックアップおよび復元機能のみを提供し、バックアップ管理はサポートしません。したがって、バックアップ データを管理する方法を自分で決定する必要があります。これには次のような疑問が含まれる可能性があります。
- どのバックアップstorageシステムを選択すればよいですか?
- バックアップ タスク中にバックアップ データをどのディレクトリに配置する必要がありますか?
- フルバックアップデータやログバックアップデータのディレクトリはどのように整理すればよいでしょうか？
- storageシステム内の過去のバックアップ データはどのように処理すればよいですか?
次のセクションでは、これらの質問に 1 つずつ答えていきます。
バックアップstorageシステムを選択する
バックアップ データは、Amazon S3、Google Cloud Storage (GCS)、または Azure Blob Storage に保存することをお勧めします。これらのシステムを使用すると、バックアップ容量や帯域幅の割り当てについて心配する必要がなくなります。
TiDB クラスターが自社構築のデータセンターにデプロイされている場合は、次の方法が推奨されます。
- バックアップstorageシステムとしてMinIOを構築し、S3 プロトコルを使用してデータを MinIO にバックアップします。
- ネットワーク ファイル システム (NAS など) ディスクを br コマンド ライン ツールおよびすべての TiKV インスタンスにマウントし、POSIX ファイル システム インターフェイスを使用してバックアップ データを対応する NFS ディレクトリに書き込みます。
注記：
Amazon S3、GCS、または Azure Blob Storage プロトコルをサポートする NFS またはstorageシステムを選択しない場合、バックアップされたデータは各 TiKV ノードで生成されます。バックアップ データを収集すると、データの冗長性や運用および保守の問題が発生する可能性があるため、これはBR の推奨される使用方法ではないことに注意してください。
バックアップデータのディレクトリを整理する
- スナップショット バックアップとログ バックアップは、統合管理のために同じディレクトリに保存します (例:
backup-${cluster-id}。 - 各スナップショット バックアップを、バックアップ日付を含むディレクトリ (例:
backup-${cluster-id}/fullbackup-202209081330に保存します。 - ログのバックアップを固定ディレクトリ (例:
backup-${cluster-id}/logbackupに保存します。ログ バックアップ プログラムは、毎日バックアップされるデータを区別するために、logbackupディレクトリの下にサブディレクトリを毎日作成します。
過去のバックアップデータを処理する
各バックアップ データのライフ サイクルを、たとえば 7 日間に設定する必要があるとします。このようなライフサイクルはバックアップ保持期間と呼ばれ、バックアップのチュートリアルでも説明されます。
- PITR を実行するには、復元ポイントの前に完全バックアップを復元し、完全バックアップと復元ポイントの間にログ バックアップを復元する必要があります。したがって、完全なスナップショットの前にのみログ バックアップを削除することをお勧めします。バックアップ保持期間を超えたログ バックアップの場合は、
br log truncateコマンドを使用して、指定した時点より前にバックアップを削除できます。 - 保存期間を超えたバックアップ データについては、バックアップ ディレクトリを削除またはアーカイブできます。
データを復元するにはどうすればよいですか?
- 完全バックアップ データのみを復元するには、
br restoreを使用して、指定したバックアップの完全復元を実行します。 - ログ バックアップを開始し、定期的に完全バックアップを実行している場合は、
br restore pointコマンドを実行して、バックアップ保持期間内の任意の時点にデータを復元できます。
BRをデプロイて使用する
BRを展開するには、次の要件が満たされていることを確認してください。
- BR、TiKV ノード、およびバックアップstorageシステムは、バックアップ速度を超えるネットワーク帯域幅を提供します。ターゲット クラスタが特に大きい場合、バックアップおよび復元速度のしきい値はバックアップ ネットワークの帯域幅によって制限されます。
- バックアップstorageシステムは、十分な読み取りおよび書き込みパフォーマンス (IOPS) を提供します。そうしないと、バックアップまたは復元中にパフォーマンスのボトルネックになる可能性があります。
- TiKV ノードには、少なくとも 2 つの追加の CPU コアとバックアップ用の高性能ディスクが搭載されています。そうしないと、バックアップがクラスター上で実行されているサービスに影響を与える可能性があります。
- BR は、 8 コアと 16 GiBメモリを超えるノード上で実行されます。
バックアップおよび復元機能は、コマンドライン ツール、SQL コマンドの実行、 TiDB Operator の使用など、いくつかの方法で使用できます。次のセクションでは、これら 3 つの方法について詳しく説明します。
br コマンドライン ツールを使用する (推奨)
TiDB は、br コマンドライン ツールを使用したバックアップと復元をサポートしています。
tiup install brからTiUPオンラインを使用して br コマンドライン ツールをインストールしますまでのコマンドを実行できます。brコマンドを使用してデータをバックアップおよび復元する方法の詳細については、次のドキュメントを参照してください。
SQL ステートメントを使用する
TiDB は、SQL ステートメントを使用した完全バックアップと復元をサポートしています。
BACKUP: 完全なスナップショット データをバックアップします。RESTORE: スナップショットバックアップデータを復元します。SHOW BACKUPS|RESTORES: バックアップと復元の進行状況を表示します。
Kubernetes でTiDB Operatorを使用する
Kubernetes では、 TiDB Operatorを使用して TiDB クラスター データを Amazon S3、GCS、または Azure Blob Storage にバックアップし、そのようなシステムのバックアップ データからデータを復元できます。詳細はTiDB Operatorを使用したデータのバックアップと復元を参照してください。