バックアップの自動調整v5.4.0 の新機能

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

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

利用シーン

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

または、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:書き込み負荷の高いクラスターの場合、自動調整によりワークロードとバックアップタスクが「正のフィードバックループ」に陥る可能性があります。この時点で、オートチューンは、クラスターのワークロードが高くないことを誤って想定し、バックアップをより高速に実行できるようにする可能性があります。このような場合、オートチューンは効果がありません。
- 解決策: バックアップタスクで使用されるスレッドの数を制限するために、 backup.num-threadsを手動でより小さな数に調整します。動作原理は次のとおりです。
  バックアッププロセスには、CPU リソースを消費する多数の SST デコード、エンコード、圧縮、および圧縮解除が含まれます。さらに、以前のテストケースでは、バックアッププロセス中に、バックアップに使用されるスレッドプールの CPU 使用率が 100% に近いことが示されています。これは、バックアップタスクが多くの CPU リソースを消費することを意味します。バックアップタスクで使用されるスレッドの数を調整することで、TiKV はバックアップタスクで使用される CPU コアを制限できるため、バックアップタスクがクラスターのパフォーマンスに与える影響を軽減できます。
問題 2:ホットスポットのあるクラスターの場合、ホットスポットのある TiKV ノードでのバックアップタスクが過度に制限され、バックアッププロセス全体が遅くなる可能性があります。
- 解決策: ホットスポットノードを削除するか、ホットスポットノードの自動調整を無効にします (これにより、クラスターのパフォーマンスが低下する可能性があります)。
問題 3:トラフィックのジッタが高いシナリオの場合、自動調整は一定の間隔 (既定では 1 分) で速度制限を調整するため、トラフィックのジッタが大きい場合は処理できない可能性があります。詳細については、 auto-tune-refresh-intervalを参照してください。
- 解決策: 自動調整を無効にします。

実装

自動調整は、バックアップタスクで使用されるスレッドプールのサイズを調整して、クラスターの全体的な 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 コアを示します。

|--------| 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 使用率が黄色の領域を超えていないことがわかります。