TiDB Self-Managed
Learning Center
お問い合わせ

BR ユースケース

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

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

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

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

観客

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

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

前提条件

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

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

導入方法

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

クラスタのバージョン

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

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