TiDB バックアップと復元の使用概要
このドキュメントでは、バックアップ方法の選択方法、バックアップ データの管理方法、バックアップおよび復元ツールのインストールおよび展開方法など、TiDB のバックアップおよび復元機能を使用するためのベスト プラクティスについて説明します。
推奨される方法
TiDB のバックアップおよび復元機能を使用する前に、推奨されるバックアップおよび復元ソリューションを理解しておくことをお勧めします。
データをバックアップするには？
TiDB は 2 種類のバックアップを提供します。どちらを使用する必要がありますか?完全バックアップには、特定の時点におけるクラスターの完全なデータが含まれます。ログ バックアップには、TiDB に書き込まれたデータの変更が含まれます。両方のタイプのバックアップを同時に使用することをお勧めします。
- Start log backup :
br log startコマンドを実行して、ログ バックアップ タスクを開始します。その後、タスクはすべての TiKV ノードで実行され続け、TiDB データの変更を指定されたstorageに小さなバッチで定期的にバックアップします。 - スナップショット (フル) バックアップを定期的に実行する:
br backup fullコマンドを実行して、クラスターのスナップショットを指定したstorageにバックアップします。たとえば、毎日午前 0:00 にクラスター スナップショットをバックアップします。
バックアップデータの管理方法は?
BR は基本的なバックアップおよび復元機能のみを提供し、バックアップ管理はサポートしていません。したがって、バックアップ データを管理する方法を自分で決定する必要があります。これには、次の質問が含まれる可能性があります。
- どのバックアップstorageシステムを選択すればよいですか?
- バックアップ タスク中にバックアップ データを配置するディレクトリを教えてください。
- フル バックアップ データとログ バックアップ データのディレクトリをどのように編成すればよいですか?
- storageシステム内の履歴バックアップ データをどのように処理しますか?
次のセクションでは、これらの質問に 1 つずつ回答します。
バックアップstorageシステムの選択
バックアップ データを Amazon S3、Google Cloud Storage (GCS)、または Azure Blob Storage に保存することをお勧めします。これらのシステムを使用すると、バックアップ容量と帯域幅の割り当てについて心配する必要はありません。
TiDB クラスターが自作のデータ センターにデプロイされている場合は、次のプラクティスが推奨されます。
- MinIOをバックアップstorageシステムとして構築し、S3 プロトコルを使用してデータを MinIO にバックアップします。
- ネットワーク ファイル システム (NAS などの NFS) ディスクを br コマンドライン ツールとすべての TiKV インスタンスにマウントし、POSIX ファイル システム インターフェイスを使用して、対応する NFS ディレクトリにバックアップ データを書き込みます。
ノート：
NFS、または Amazon S3、GCS、または Azure Blob Storage プロトコルをサポートする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を使用したデータのバックアップと復元を参照してください。