BR ユースケース

バックアップと復元 (BR)は、TiDB クラスター データの分散バックアップおよび復元用のツールです。

このドキュメントでは、一般的なバックアップと復元のシナリオについて説明します。

このドキュメントは、次の目標の達成を支援することを目的としています。

  • ネットワーク ディスクまたはローカル ディスクを正しく使用して、データのバックアップと復元を行ってください。
  • メトリックを監視して、バックアップまたは復元操作のステータスを取得します。
  • バックアップまたは復元操作中にパフォーマンスを調整する方法を学びます。
  • バックアップ操作中に発生する可能性のある異常をトラブルシューティングします。

観客

TiDB とTiKVの基本的な知識が必要です。

読み進める前に、 BRの概要 、特に使用制限いくつかのヒントを読んだことを確認してください。

前提条件

このセクションでは、TiDB の推奨デプロイ方法、クラスター バージョン、TiKV クラスターのハードウェア情報、およびユース ケース デモンストレーション用のクラスター構成を紹介します。

独自のハードウェアと構成に基づいて、バックアップまたは復元操作のパフォーマンスを見積もることができます。データのバックアップと復元には、ネットワーク ディスクを使用することをお勧めします。これにより、バックアップ ファイルを収集する手間が省け、特に TiKV クラスターが大規模な場合にバックアップ効率が大幅に向上します。

導入方法

TiUPを使用して TiDB クラスターをデプロイし、TiUP を使用して BR をインストールすることをお勧めします。

クラスタのバージョン

  • TiDB: v6.1.2
  • TiKV: v6.1.2
  • PD: v6.1.2
  • BR: v6.1.2

ノート:

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コマンドを実行する前に、ターゲット クラスターをチェックして、このクラスター内のテーブルに重複した名前がないことを確認します。

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 の類型を示しています。

img

バックアップ操作

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 使用率 (たとえば、バックアップ ワーカーとバックアップ エンドポイント)。

img

IO 使用率: バックアップ操作で動作している各 TiKV ノードの I/O 使用率。

img

BackupSST Generation Throughput : バックアップ操作で動作している各 TiKV ノードの backupSST 生成スループット。通常は約 150 MB/秒です。

img

One Backup Range Duration : 範囲をバックアップする期間。これは、KV をスキャンし、範囲を backupSST ファイルとして保存するための合計時間コストです。

img

1 つのバックアップ サブタスク期間: バックアップ タスクが分割された各サブタスクの期間。

ノート:

  • このタスクでは、バックアップする 1 つのテーブルに 3 つのインデックスがあり、タスクは通常 4 つのサブタスクに分割されます。
  • 次の画像のパネルには 20 個のポイントがあり、10 個が青、10 個が黄色であり、10 個のサブタスクがあることを示しています。リージョンのスケジューリングはバックアップ プロセス中に発生する可能性があるため、数回の再試行は正常です。

img

バックアップ エラー: バックアップ プロセス中に発生したエラー。通常の状況ではエラーは発生しません。多少のエラーが発生した場合でも、バックアップ操作には再試行メカニズムがあり、バックアップ時間が長くなる可能性がありますが、操作の正確性には影響しません。

img

Checksum Request Duration : バックアップ クラスタでの管理チェックサム リクエストの期間。

img

バックアップ結果の説明

バックアップが完了すると、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

img

img

チューニングされたパフォーマンスの結果は次のとおりです (データ サイズは同じです)。

  • バックアップ期間 ( 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 の類型を示しています。

img

復旧作業

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 使用率。

img

IO 使用率: 復元操作で動作している各 TiKV ノードの I/O 使用率。

img

リージョン:リージョン分布。リージョンが均等に分散されているほど、復元リソースがより適切に使用されます。

img

Process SST Duration : SST ファイルの処理の遅延。テーブルを復元する場合、 tableIDを変更した場合はtableIDを書き換える必要があります。それ以外の場合、 tableIDは名前が変更されます。一般に、書き換えの遅延は、名前の変更の遅延よりも長くなります。

img

ダウンロード SST スループット: 外部ストレージから SST ファイルをダウンロードするスループット。

img

復元エラー: 復元プロセス中に発生したエラー。

img

Checksum Request Duration : 管理チェックサム要求の期間。このリストアの所要時間は、バックアップの所要時間よりも長くなります。

img

復元結果の説明

リストアコマンドを実行する前に指定したログでは、このログからリストア操作の統計情報を取得できます。このログで「概要」を検索すると、次の情報が表示されます。

["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に増加

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 の類型を示しています。

img

バックアップ操作

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/ ) を共有します。

復元する前に、次の手順に従います。

  1. すべての backupSST ファイルを同じディレクトリーに集めます。
  2. 収集した backupSST ファイルをクラスターのすべての TiKV ノードにコピーします。
  3. backupmetaファイルをrestore endpointノードにコピーします。

トポロジー

次の図は、BR の類型を示しています。

img

復旧作業

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 ノードのバックアップ ディレクトリを削除します。

このページは役に立ちましたか?

Playground
新規
登録なしで TiDB の機能をワンストップでインタラクティブに体験できます。
製品
TiDB Cloud
TiDB
価格
PoC お問い合わせ
エコシステム
TiKV
TiFlash
OSS Insight
© 2024 PingCAP. All Rights Reserved.
Privacy Policy.