重要
このページは英語版のページを機械翻訳しています。原文はこちらからご覧ください。

BRAuto- Tunev5.4.0の新機能

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

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

ユーザーシナリオ

クラスタへのバックアップタスクの影響を減らしたい場合は、自動調整機能を有効にすることができます。この機能を有効にすると、BRは、クラスタに過度の影響を与えることなく、バックアップタスクを可能な限り高速に実行します。

または、TiKV構成項目backup.num-threadsまたはパラメーター--ratelimitを使用して、バックアップ速度を制限することもできます。

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

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

ノート：

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>

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

制限事項

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

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

  • 問題1：書き込みが多いクラスターの場合、自動調整によってワークロードとバックアップタスクが「正のフィードバックループ」に陥る可能性があります。バックアップタスクが占めるリソースが多すぎるため、クラスタが使用するリソースが少なくなります。この時点で、自動調整は、クラスタに重いワークロードがないことを誤って想定し、BRをより高速に実行できるようにする可能性があります。このような場合、自動調整は効果がありません。

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

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

  • 問題2：ホットスポットのあるクラスターの場合、ホットスポットのあるTiKVノードでのバックアップタスクが過度に制限され、バックアッププロセス全体の速度が低下する可能性があります。

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

  • 問題3：トラフィックジッターが高いシナリオでは、自動調整によって一定の間隔（デフォルトでは1分）で制限速度が調整されるため、トラフィックジッターが高い場合は処理できない可能性があります。詳細については、 auto-tune-refresh-intervalを参照してください。

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

実装

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

この機能には、TiKV構成ファイルにリストされていない2つの関連する構成項目があります。これらの2つの構成項目は、内部調整専用です。バックアップタスクを実行するときに、これら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

以下は、自動調整がどのように機能するかの例です。 *は、バックアップタスクで使用されるCPUコアを示します。 ^は、他のタスクで使用されるCPUコアを示します。 -はアイドル状態の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使用率]パネルで、自動調整によって調整されたスレッドプールのサイズを確認できます。

Grafana dashboard example of backup auto-tune metrics

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

このページの内容