バックアップオートチューンv5.4.0 の新機能

TiDB v5.4.0より前のバージョンでは、バックアップ＆リストア（BR）を使用してデータをバックアップすると、バックアップに使用されるスレッド数が論理CPUコアの75%を占めていました。速度制限がない場合、バックアッププロセスは大量のクラスターリソースを消費し、オンラインクラスターのパフォーマンスに大きな影響を与える可能性があります。スレッドプールのサイズを調整することでバックアップの影響を軽減することはできますが、CPU負荷を監視し、手動でスレッドプールのサイズを調整するのは面倒な作業です。

バックアップタスクがクラスタに与える影響を軽減するため、TiDB v5.4.0では自動チューニング機能が導入されました。この機能はデフォルトで有効になっています。クラスタリソースの使用率が高い場合、 BRはバックアップタスクが使用するリソースを自動的に制限し、クラスタへの影響を軽減します。自動チューニング機能はデフォルトで有効になっています。

使用シナリオ

バックアップタスクがクラスタに与える影響を軽減したい場合は、自動チューニング機能を有効にできます。この機能を有効にすると、TiDBはクラスタに過度の影響を与えることなく、可能な限り高速にバックアップタスクを実行します。

あるいは、TiKV設定項目backup.num-threadsまたはパラメータ--ratelimitを使用してバックアップ速度を制限することもできます。 --ratelimit設定されている場合、タスクが多すぎて速度制限を超えてしまうのを防ぐため、br のパラメータconcurrency自動的に1に調整されます。

オートチューンを使用する

自動調整機能は、追加の構成なしでデフォルトで有効になっています。

注記：

v5.3.xからv5.4.0以降のバージョンにアップグレードするクラスターでは、自動チューニング機能はデフォルトで無効になっています。手動で有効にする必要があります。

自動調整機能を手動で有効にするには、TiKV 構成項目backup.enable-auto-tuneをtrueに設定する必要があります。

TiKVは自動チューニング機能の動的な設定をサポートしています。この機能は、クラスターを再起動せずに有効化または無効化できます。自動チューニング機能を動的に有効化または無効化するには、次のコマンドを実行します。

tikv-ctl modify-tikv-config -n backup.enable-auto-tune -v <true|false>

オフライン クラスターでバックアップ タスクを実行する場合、バックアップを高速化するために、 backup.num-threadsの値をtikv-ctl使用してより大きな数値に変更できます。

制限事項

自動チューニングは、バックアップ速度を制限するための大まかなソリューションです。手動チューニングの必要性を軽減します。ただし、きめ細かな制御がないため、自動チューニングではバックアップがクラスターに与える影響を完全に排除できない場合があります。

自動調整機能には、次の問題と対応する解決策があります。

• 問題1：書き込み負荷の高いクラスタでは、自動チューニングによってワークロードとバックアップタスクが「正のフィードバックループ」に陥る可能性があります。つまり、バックアップタスクが過剰なリソースを消費し、クラスタが使用するリソースが少なくなるのです。この時点で、自動チューニングはクラスタのワークロードがそれほど高くないと誤って判断し、バックアップの実行速度を速めてしまう可能性があります。このような場合、自動チューニングは効果を発揮しません。

  • 解決策：バックアップタスクで使用されるスレッド数を制限したい場合は、手動でbackup.num-threads小さい数値に調整してください。動作原理は以下のとおりです。

    バックアッププロセスには、SSTのデコード、エンコード、圧縮、解凍といった多くの処理が含まれており、CPUリソースを消費します。さらに、過去のテストケースでは、バックアッププロセス中に、バックアップに使用されるスレッドプールのCPU使用率が100%に近づくことが確認されています。これは、バックアップタスクが多くのCPUリソースを消費していることを意味します。TiKVは、バックアップタスクで使用されるスレッド数を調整することで、バックアップタスクで使用されるCPUコア数を制限し、バックアップタスクがクラスターのパフォーマンスに与える影響を軽減します。

• 問題 2:ホットスポットのあるクラスターの場合、ホットスポットがある TiKV ノード上のバックアップ タスクが過度に制限され、全体的なバックアップ プロセスが遅くなることがあります。

  • 解決策: ホットスポット ノードを削除するか、ホットスポット ノードの自動調整を無効にします (これにより、クラスターのパフォーマンスが低下する可能性があります)。

• 問題3：トラフィックジッタが大きいシナリオでは、自動調整機能は一定間隔（デフォルトでは1分）で速度制限を調整するため、トラフィックジッタが大きい状況に対応できない可能性があります。詳細はauto-tune-refresh-intervalご覧ください。

  • 解決策: 自動調整を無効にします。

実装

自動チューニングは、バックアップ タスクで使用されるスレッド プールのサイズを調整して、クラスターの全体的な CPU 使用率が特定のしきい値を超えないようにします。

この機能には、TiKV設定ファイルに記載されていない関連する設定項目が2つあります。これらの設定項目は内部調整のみを目的としています。バックアップタスクを実行する際に、これらの設定項目を設定する必要はありません。

• backup.auto-tune-remain-threads :

  • 自動調整は、バックアップ タスクで使用されるリソースを制御し、同じノード上の他のタスクで少なくともbackup.auto-tune-remain-threadsコアが使用可能であることを保証します。
  • デフォルト値: round(0.2 * vCPU)

• backup.auto-tune-refresh-interval :

  • 自動調整により、 backup.auto-tune-refresh-interval分ごとに統計が更新され、バックアップ タスクで使用できる CPU コアの最大数が再計算されます。
  • デフォルト値: 1m

以下は、自動チューニングの動作例です。1 *バックアップ タスクで使用される CPU コアを示します。3 ^他のタスクで使用される CPU コアを示します。5 - 、アイドル状態の CPU コアを示します。

|--------| The server has 8 logical CPU cores.
|****----| By default, `backup.num-threads` is `4`. Note that auto-tune makes sure that the thread pool size is never larger than `backup.num-threads`.
|^^****--| By default, `auto-tune-remain-threads` = round(8 * 0.2) = 2. Auto-tune adjusts the size of the thread pool to `4`.
|^^^^**--| Because the cluster workload gets higher, auto-tune adjusts the size of the thread pool to `2`. After that, the cluster still has 2 idle CPU cores.

バックアップ CPU 使用率パネルでは、自動調整によって調整されたスレッド プールのサイズを確認できます。

上の画像では、黄色の半透明の領域がバックアップタスクに使用可能なスレッド数を表しています。バックアップタスクのCPU使用率は黄色の領域を超えていないことがわかります。