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

TiDB v5.4.0 より前では、バックアップ & リストア (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>

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

制限事項

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

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

• 問題 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

以下は、自動チューニングの動作例です。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 使用率は黄色の領域を超えないことがわかります。