BR ユースケース
バックアップと復元 (BR)は、TiDB クラスター データの分散バックアップおよび復元用のツールです。
このドキュメントでは、一般的なバックアップと復元のシナリオについて説明します。
- 1 つのテーブルをネットワーク ディスクにバックアップする (運用環境に推奨)
- ネットワーク ディスクからのデータの復元 (本番環境に推奨)
- 1 つのテーブルをローカル ディスクにバックアップする
- ローカル ディスクからデータを復元する
このドキュメントは、次の目標の達成を支援することを目的としています。
- ネットワーク ディスクまたはローカル ディスクを正しく使用して、データのバックアップと復元を行ってください。
- メトリックを監視して、バックアップまたは復元操作のステータスを取得します。
- バックアップまたは復元操作中にパフォーマンスを調整する方法を学びます。
- バックアップ操作中に発生する可能性のある異常をトラブルシューティングします。
観客
TiDB とTiKVの基本的な知識が必要です。
読み進める前に、 BRの概要 、特に使用制限といくつかのヒントを読んだことを確認してください。
前提条件
このセクションでは、TiDB の推奨デプロイ方法、クラスター バージョン、TiKV クラスターのハードウェア情報、およびユース ケース デモンストレーション用のクラスター構成を紹介します。
独自のハードウェアと構成に基づいて、バックアップまたは復元操作のパフォーマンスを見積もることができます。データのバックアップと復元には、ネットワーク ディスクを使用することをお勧めします。これにより、バックアップ ファイルを収集する手間が省け、特に TiKV クラスターが大規模な場合にバックアップ効率が大幅に向上します。
導入方法
TiUPを使用して TiDB クラスターをデプロイし、TiUP を使用して BR をインストールすることをお勧めします。
クラスタのバージョン
- TiDB: v6.3.0
- TiKV: v6.3.0
- PD: v6.3.0
- BR: v6.3.0
ノート:
TiDB/TiKV/PD/BRの最新バージョンを使用し、BR バージョンが TiDB バージョンと一致していることを確認することをお勧めします。
TiKV ハードウェア情報
- オペレーティング システム: CentOS Linux リリース 7.6.1810 (コア)
- CPU: 16 コア共通 KVM プロセッサ
- RAM: 32GB
- ディスク: 500 GB SSD * 2
- NIC: 10 ギガビット ネットワーク カード
クラスタ構成
BR は直接 TiKV クラスターにコマンドを送信し、TiDBサーバーに依存しないため、BR を使用する場合に TiDBサーバーを構成する必要はありません。
- TiKV: デフォルト設定
- PD: デフォルト設定
その他
上記の前提条件に加えて、バックアップと復元を実行する前に、次のチェックも実行する必要があります。
バックアップ前の確認
br backup
コマンドを実行する前に、次の条件が満たされていることを確認してください。
- TiDB クラスターで実行されている DDL ステートメントはありません。
- ターゲット ストレージ デバイスには、必要な容量 (バックアップ クラスターのディスク容量の 1/3 以上) が必要です。
復旧前の確認
br restore
コマンドを実行する前に、ターゲット クラスターをチェックして、このクラスター内のテーブルに重複した名前がないことを確認します。
1 つのテーブルをネットワーク ディスクにバックアップする (運用環境に推奨)
br backup
コマンドを実行して、単一テーブル データ--db batchmark --table order_line
をネットワーク ディスクの指定されたパスlocal:///br_data
にバックアップします。
バックアップの前提条件
- バックアップ前の確認
- 高性能 SSD ハードディスク ホストを NFSサーバーとして構成してデータを保存し、すべての BR ノード、TiKV ノード、および TiFlash ノードを NFS クライアントとして構成します。 NFS クライアントがサーバーにアクセスできるように、NFSサーバーに同じパス (たとえば、
/br_data
) をマウントします。 - NFSサーバーとすべての NFS クライアント間の合計転送速度は、少なくとも
the number of TiKV instances * 150MB/s
に達する必要があります。そうしないと、ネットワーク I/O がパフォーマンスのボトルネックになる可能性があります。
ノート:
- データバックアップ時は、リーダーレプリカのデータのみをバックアップするため、クラスター内にTiFlashレプリカが存在する場合でも、BRはTiFlashノードをマウントせずにバックアップを完了できます。
- データを復元する場合、BR はすべてのレプリカのデータを復元します。また、TiFlash ノードは、リストアを完了するために BR のバックアップ データにアクセスする必要があります。したがって、復元の前に、TiFlash ノードを NFSサーバーにマウントする必要があります。
トポロジー
次の図は、BR の類型を示しています。
バックアップ操作
br backup
コマンドを実行します。
bin/br backup table \
--db batchmark \
--table order_line \
-s local:///br_data \
--pd ${PD_ADDR}:2379 \
--log-file backup-nfs.log
バックアップのモニタリング メトリック
バックアップ プロセス中は、監視パネルの次のメトリックに注意して、バックアップ プロセスのステータスを取得します。
バックアップ CPU 使用率: バックアップ操作で動作している各 TiKV ノードの CPU 使用率 (たとえば、バックアップ ワーカーとバックアップ エンドポイント)。
IO 使用率: バックアップ操作で動作している各 TiKV ノードの I/O 使用率。
BackupSST Generation Throughput : バックアップ操作で動作している各 TiKV ノードの backupSST 生成スループット。通常は約 150 MB/秒です。
One Backup Range Duration : 範囲をバックアップする期間。これは、KV をスキャンし、範囲を backupSST ファイルとして保存するための合計時間コストです。
1 つのバックアップ サブタスク期間: バックアップ タスクが分割された各サブタスクの期間。
ノート:
- このタスクでは、バックアップする 1 つのテーブルに 3 つのインデックスがあり、タスクは通常 4 つのサブタスクに分割されます。
- 次の画像のパネルには 20 個のポイントがあり、10 個が青、10 個が黄色であり、10 個のサブタスクがあることを示しています。リージョンのスケジューリングはバックアップ プロセス中に発生する可能性があるため、数回の再試行は正常です。
バックアップ エラー: バックアップ プロセス中に発生したエラー。通常の状況ではエラーは発生しません。多少のエラーが発生した場合でも、バックアップ操作には再試行メカニズムがあり、バックアップ時間が長くなる可能性がありますが、操作の正確性には影響しません。
Checksum Request Duration : バックアップ クラスタでの管理チェックサム リクエストの期間。
バックアップ結果の説明
バックアップが完了すると、BR はバックアップの概要をコンソールに出力します。
バックアップコマンドを実行する前に指定したログでは、このログからバックアップ操作の統計情報を取得できます。このログで「概要」を検索すると、次の情報が表示されます。
["Full backup Success summary:
total backup ranges: 2,
total success: 2,
total failed: 0,
total take(Full backup time): 31.802912166s,
total take(real time): 49.799662427s,
total size(MB): 5997.49,
avg speed(MB/s): 188.58,
total kv: 120000000"]
["backup checksum"=17.907153678s]
["backup fast checksum"=349.333µs]
["backup total regions"=43]
[BackupTS=422618409346269185]
[Size=826765915]
上記のログには、次の情報が含まれています。
total take(Full backup time)
: バックアップ期間total take(real time)
: アプリケーションの総実行時間total size(MB)
: バックアップ データのサイズavg speed(MB/s)
: バックアップ スループットtotal kv
: バックアップされた KV ペアの数backup checksum
: バックアップ チェックサム期間backup fast checksum
: 各テーブルのチェックサム、KV ペア、およびバイトを計算する合計時間backup total regions
: バックアップ リージョンの総数BackupTS
: バックアップ データのスナップショット タイムスタンプSize
: 圧縮後のディスク内のバックアップ データの実際のサイズ
上記の情報から、単一の TiKV インスタンスのスループットを計算できます: avg speed(MB/s)
/ tikv_count
= 62.86
。
性能調整
バックアップ プロセス中に TiKV のリソース使用率が明らかなボトルネックにならない場合 (たとえば、 バックアップのモニタリング メトリックで、backup-worker の最大 CPU 使用率が1500%
前後で、全体の I/O 使用率が30%
未満である場合)、 --concurrency
(デフォルトでは4
) の値を増やして、パフォーマンスを調整できます。ただし、このパフォーマンス チューニング方法は、多くの小さなテーブルのユース ケースには適していません。次の例を参照してください。
bin/br backup table \
--db batchmark \
--table order_line \
-s local:///br_data/ \
--pd ${PD_ADDR}:2379 \
--log-file backup-nfs.log \
--concurrency 16
チューニングされたパフォーマンスの結果は次のとおりです (データ サイズは同じです)。
- バックアップ期間 (
total take(s)
):986.43
から535.53
に短縮 - バックアップ スループット (
avg speed(MB/s)
):358.09
から659.59
に増加 - 単一の TiKV インスタンスのスループット (
avg speed(MB/s)/tikv_count
):89
から164.89
に増加
ネットワーク ディスクからのデータの復元 (本番環境に推奨)
br restore
コマンドを使用して、完全なバックアップ データをオフライン クラスターに復元します。現在、BR はオンライン クラスターへのデータの復元をサポートしていません。
復元の前提条件
トポロジー
次の図は、BR の類型を示しています。
復旧作業
br restore
コマンドを実行します。
bin/br restore table --db batchmark --table order_line -s local:///br_data --pd 172.16.5.198:2379 --log-file restore-nfs.log
復元のモニタリング メトリック
復元プロセス中は、監視パネルの次のメトリックに注意して、復元プロセスのステータスを取得してください。
CPU : 復元操作における各稼働中の TiKV ノードの CPU 使用率。
IO 使用率: 復元操作で動作している各 TiKV ノードの I/O 使用率。
リージョン:リージョン分布。リージョンが均等に分散されているほど、復元リソースがより適切に使用されます。
Process SST Duration : SST ファイルの処理の遅延。テーブルを復元する場合、 tableID
を変更した場合はtableID
を書き換える必要があります。それ以外の場合、 tableID
は名前が変更されます。一般に、書き換えの遅延は、名前の変更の遅延よりも長くなります。
ダウンロード SST スループット: 外部ストレージから SST ファイルをダウンロードするスループット。
復元エラー: 復元プロセス中に発生したエラー。
Checksum Request Duration : 管理チェックサム要求の期間。このリストアの所要時間は、バックアップの所要時間よりも長くなります。
復元結果の説明
リストアコマンドを実行する前に指定したログでは、このログからリストア操作の統計情報を取得できます。このログで「概要」を検索すると、次の情報が表示されます。
["Table Restore summary:
total restore tables: 1,
total success: 1,
total failed: 0,
total take(Full restore time): 17m1.001611365s,
total take(real time): 16m1.371611365s,
total kv: 5659888624,
total size(MB): 353227.18,
avg speed(MB/s): 367.42"]
["restore files"=9263]
["restore ranges"=6888]
["split region"=49.049182743s]
["restore checksum"=6m34.879439498s]
[Size=48693068713]
上記のログには、次の情報が含まれています。
total take(Full restore time)
: 復元期間total take(real time)
: アプリケーションの総実行時間total size(MB)
: 復元するデータのサイズtotal kv
: 復元された KV ペアの数avg speed(MB/s)
: 復元スループットsplit region
:リージョン分割デュレーションrestore checksum
: 復元チェックサム期間Size
: ディスク内の復元されたデータの実際のサイズ
上記の情報から、次の項目を計算できます。
- 単一の TiKV インスタンスのスループット:
avg speed(MB/s)
/tikv_count
=91.8
- 単一の TiKV インスタンスの平均復元速度:
total size(MB)
/(split time
+restore time
)/tikv_count
=87.4
性能調整
復元プロセス中に TiKV のリソース使用量が明らかなボトルネックにならない場合は、値--concurrency
を増やすことができます (デフォルトは128
)。次の例を参照してください。
bin/br restore table --db batchmark --table order_line -s local:///br_data/ --pd 172.16.5.198:2379 --log-file restore-concurrency.log --concurrency 1024
チューニングされたパフォーマンスの結果は次のとおりです (データ サイズは同じです)。
- 回復時間 (
total take(s)
):961.37
から443.49
に減少 - 復元スループット (
avg speed(MB/s)
):367.42
から796.47
に増加 - 単一の TiKV インスタンスのスループット (
avg speed(MB/s)
/tikv_count
):91.8
から199.1
に増加 - 単一の TiKV インスタンスの平均復元速度 (
total size(MB)
/(split time
+restore time
)/tikv_count
):87.4
から162.3
に増加
1 つのテーブルをローカル ディスクにバックアップする (テスト環境に推奨)
br backup
コマンドを実行して、単一のテーブル--db batchmark --table order_line
をローカル ディスクの指定されたパスlocal:///home/tidb/backup_local
にバックアップします。
バックアップの前提条件
- バックアップ前の確認
- 各 TiKV ノードには、backupSST ファイルを格納するための個別のディスクがあります。
backup_endpoint
のノードには、backupmeta
のファイルを格納するための個別のディスクがあります。- TiKV と
backup_endpoint
ノードは、バックアップ用に同じディレクトリ (たとえば、/home/tidb/backup_local
) を共有します。
トポロジー
次の図は、BR の類型を示しています。
バックアップ操作
br backup
コマンドを実行します。
bin/br backup table \
--db batchmark \
--table order_line \
-s local:///home/tidb/backup_local/ \
--pd ${PD_ADDR}:2379 \
--log-file backup_local.log
バックアップ プロセス中は、監視パネルのメトリックに注意して、バックアップ プロセスのステータスを取得します。詳細はバックアップのモニタリング メトリックを参照してください。
バックアップ結果の説明
バックアップコマンドを実行する前に指定したログでは、このログからリストア操作の統計情報を取得できます。このログで「概要」を検索すると、次の情報が表示されます。
["Table backup summary:
total backup ranges: 4,
total success: 4,
total failed: 0,
total take(s): 551.31,
total kv: 5659888624,
total size(MB): 353227.18,
avg speed(MB/s): 640.71"]
["backup total regions"=6795]
["backup checksum"=6m33.962719217s]
["backup fast checksum"=22.995552ms]
上記のログには、次の情報が含まれています。
total take(s)
: バックアップ期間total size(MB)
: データサイズavg speed(MB/s)
: バックアップのスループットbackup checksum
: バックアップ チェックサム期間
上記の情報から、単一の TiKV インスタンスのスループットを計算できます: avg speed(MB/s)
/ tikv_count
= 160
。
ローカル ディスクからデータを復元する (テスト環境に推奨)
br restore
コマンドを実行して、完全なバックアップ データをオフライン クラスターに復元します。現在、BR はオンライン クラスターへのデータの復元をサポートしていません。
復元の前提条件
- 復元前の確認
- TiKV クラスターとバックアップ データには、重複するデータベースまたはテーブルがありません。現在、BR はテーブル ルートをサポートしていません。
- 各 TiKV ノードには、backupSST ファイルを格納するための個別のディスクがあります。
restore_endpoint
のノードには、backupmeta
のファイルを格納するための個別のディスクがあります。- TiKV と
restore_endpoint
ノードは、復元のために同じディレクトリ (たとえば、/home/tidb/backup_local/
) を共有します。
復元する前に、次の手順に従います。
- すべての backupSST ファイルを同じディレクトリーに集めます。
- 収集した backupSST ファイルをクラスターのすべての TiKV ノードにコピーします。
backupmeta
ファイルをrestore endpoint
ノードにコピーします。
トポロジー
次の図は、BR の類型を示しています。
復旧作業
br restore
コマンドを実行します。
bin/br restore table --db batchmark --table order_line -s local:///home/tidb/backup_local/ --pd 172.16.5.198:2379 --log-file restore_local.log
復元プロセス中は、監視パネルのメトリックに注意して、復元プロセスのステータスを取得してください。詳細は復元のモニタリング メトリックを参照してください。
復元結果の説明
リストアコマンドを実行する前に指定したログでは、このログからリストア操作の統計情報を取得できます。このログで「概要」を検索すると、次の情報が表示されます。
["Table Restore summary:
total restore tables: 1,
total success: 1,
total failed: 0,
total take(s): 908.42,
total kv: 5659888624,
total size(MB): 353227.18,
avg speed(MB/s): 388.84"]
["restore files"=9263]
["restore ranges"=6888]
["split region"=58.7885518s]
["restore checksum"=6m19.349067937s]
上記のログには、次の情報が含まれています。
total take(s)
: 復元期間total size(MB)
: データサイズavg speed(MB/s)
: 復元スループットsplit region
: リージョン分割のデュレーションrestore checksum
: 復元チェックサム期間
上記の情報から、次の項目を計算できます。
- 単一の TiKV インスタンスのスループット:
avg speed(MB/s)
/tikv_count
=97.2
- 単一の TiKV インスタンスの平均復元速度:
total size(MB)
/(split time
+restore time
)/tikv_count
=92.4
バックアップ中のエラー処理
このセクションでは、バックアップ プロセス中に発生する可能性のある一般的なエラーについて説明します。
key locked Error
ログのエラー メッセージ: log - ["backup occur kv error"][error="{\"KvError\":{\"locked\":
バックアップ プロセス中にキーがロックされている場合、BR はロックの解決を試みます。少数のこのエラーは、バックアップの正確性には影響しません。
バックアップの失敗
ログのエラー メッセージ: log - Error: msg:"Io(Custom { kind: AlreadyExists, error: \"[5_5359_42_123_default.sst] is already exists in /dir/backup_local/\" })"
バックアップ操作が失敗し、前述のメッセージが表示された場合は、次の操作のいずれかを実行してから、バックアップ操作を再度開始します。
- バックアップのディレクトリを変更します。たとえば、
/dir/backup-2020-01-01/
を/dir/backup_local/
に変更します。 - すべての TiKV ノードと BR ノードのバックアップ ディレクトリを削除します。