リソース制御を使用してリソースの分離を実現する

注記：

この機能はTiDB サーバーレスクラスターでは使用できません。

クラスター管理者は、リソース制御機能を使用して、リソース グループの作成、リソース グループのクォータの設定、およびそれらのグループへのユーザーのバインドを行うことができます。

TiDB リソース制御機能は、TiDBレイヤーのフロー制御機能と TiKVレイヤーの優先スケジューリング機能の 2 層のリソース管理機能を提供します。 2 つの機能は個別に有効にすることも、同時に有効にすることもできます。詳細はリソース制御用パラメータを参照してください。これにより、TiDBレイヤーがリソース グループに設定されたクォータに基づいてユーザーの読み取りおよび書き込みリクエストのフローを制御できるようになり、TiKVレイヤーが読み取りおよび書き込みクォータにマップされた優先順位に基づいてリクエストをスケジュールできるようになります。これにより、アプリケーションのリソース分離を確保し、サービス品質 (QoS) 要件を満たすことができます。

• TiDB フロー制御: TiDB フロー制御はトークンバケットアルゴリズムを使用します。バケット内に十分なトークンがなく、リソース グループがBURSTABLEオプションを指定していない場合、リソース グループへのリクエストは、トークン バケットにトークンがバックフィルされるのを待って再試行します。タイムアウトにより再試行が失敗する場合があります。

• TiKV スケジューリング: 必要に応じて絶対優先度（ PRIORITY ）を設定できます。 PRIORITYの設定に従って、さまざまなリソースがスケジュールされます。高PRIORITYのタスクが最初にスケジュールされます。絶対優先度を設定しない場合、TiKV は各リソース グループの値RU_PER_SECを使用して、各リソース グループの読み取りおよび書き込みリクエストの優先度を決定します。優先順位に基づいて、storageレイヤーは優先キューを使用してリクエストをスケジュールし、処理します。

v7.4.0 以降、リソース制御機能はTiFlashリソースの制御をサポートします。その原理は、TiDB フロー制御および TiKV スケジューリングの原理と似ています。

• TiFlashフロー制御: TiFlashパイプライン実行モデルを使用すると、 TiFlash はさまざまなクエリの CPU 消費量をより正確に取得し、それを差し引くためにリクエストユニット (RU)に変換できます。トラフィック制御はトークン バケット アルゴリズムを使用して実装されます。
• TiFlashスケジューリング: システム リソースが不十分な場合、 TiFlash は優先順位に基づいて複数のリソース グループ間でパイプライン タスクをスケジュールします。具体的なロジックは次のとおりです。まず、 TiFlash はリソース グループのPRIORITY評価し、次に CPU 使用率とRU_PER_SECを考慮します。その結果、 rg1とrg2のPRIORITY同じですが、 rg2のRU_PER_SECがrg1の 2 倍である場合、 rg2の CPU 使用率はrg1の 2 倍になります。

• TiFlashフロー制御: TiFlashパイプライン実行モデルを使用すると、 TiFlash はさまざまなクエリの CPU 消費量をより正確に取得し、それを差し引くためにリクエストユニット (RU)に変換できます。トラフィック制御はトークン バケット アルゴリズムを使用して実装されます。
• TiFlashスケジューリング: システム リソースが不十分な場合、 TiFlash は優先順位に基づいて複数のリソース グループ間でパイプライン タスクをスケジュールします。具体的なロジックは次のとおりです。まず、 TiFlash はリソース グループのPRIORITY評価し、次に CPU 使用率とRU_PER_SECを考慮します。その結果、 rg1とrg2のPRIORITY同じですが、 rg2のRU_PER_SECがrg1の 2 倍である場合、 rg2の CPU 使用率はrg1の 2 倍になります。

リソース制御のシナリオ

リソース制御機能の導入は、TiDB にとってマイルストーンです。分散データベース クラスターを複数の論理ユニットに分割できます。たとえ個々のユニットがリソースを過剰に使用しても、他のユニットが必要とするリソースがクラウドアウトされることはありません。

この機能を使用すると、次のことが可能になります。

• 異なるシステムからの複数の中小規模のアプリケーションを単一の TiDB クラスターに結合します。アプリケーションのワークロードが大きくなっても、他のアプリケーションの通常の動作には影響しません。システムのワークロードが低い場合は、設定されたクォータを超えている場合でも、ビジー状態のアプリケーションに必要なシステム リソースを割り当てることができ、リソースを最大限に活用することができます。
• すべてのテスト環境を単一の TiDB クラスターに結合するか、より多くのリソースを消費するバッチ タスクを単一のリソース グループにグループ化するかを選択します。重要なアプリケーションが常に必要なリソースを確実に取得できるようにしながら、ハードウェアの使用率を向上させ、運用コストを削減できます。
• システム内にワークロードが混在している場合、異なるワークロードを別々のリソース グループに入れることができます。リソース制御機能を使用すると、トランザクション アプリケーションの応答時間がデータ分析やバッチ アプリケーションの影響を受けないようにすることができます。
• クラスターで予期しない SQL パフォーマンスの問題が発生した場合は、SQL バインディングとリソース グループを使用して、SQL ステートメントのリソース消費を一時的に制限できます。

さらに、リソース制御機能を合理的に使用することで、クラスタ数を削減し、運用保守の困難を軽減し、管理コストを節約できます。

注記：

• リソース管理の有効性を評価するには、独立したコンピューティング ノードとstorageノードにクラスターを展開することをお勧めします。スケジュールやその他のクラスターのリソースに依存する機能は、リソースがインスタンス間で共有されるtiup playgroundによって作成されたデプロイメントではほとんど適切に動作しません。

制限事項

リソース制御により、追加のスケジューリング オーバーヘッドが発生します。したがって、この機能を有効にすると、パフォーマンスがわずかに低下する可能性があります (5% 未満)。

リクエストユニット(RU)とは

リクエスト ユニット (RU) は、システム リソースに対する TiDB の統合抽象化ユニットであり、現在、CPU、IOPS、および IO 帯域幅のメトリクスが含まれています。これは、データベースへの 1 回のリクエストによって消費されるリソースの量を示すために使用されます。要求によって消費される RU の数は、操作の種類、クエリまたは変更されるデータの量などのさまざまな要因によって異なります。現在、RU には次の表のリソースの消費統計が含まれています。

注記：

• 各書き込み操作は、最終的にすべてのレプリカに複製されます (デフォルトでは、TiKV には 3 つのレプリカがあります)。各レプリケーション操作は、異なる書き込み操作とみなされます。
• 上の表には、ネットワークとstorageの消費量を除いて、TiDB セルフホスト クラスターの RU 計算に関係するリソースのみがリストされています。 TiDB サーバーレス RU については、 TiDB サーバーレスの料金詳細を参照してください。
• 現在、 TiFlashリソース制御では、クエリのパイプライン タスクの実行によって消費される CPU 時間である SQL CPU と読み取り要求ペイロードのみが考慮されます。

リソース制御用パラメータ

リソース制御機能では、次のシステム変数またはパラメータが導入されます。

• TiDB: tidb_enable_resource_controlシステム変数を使用して、リソース グループのフロー制御を有効にするかどうかを制御できます。

• TiKV: resource-control.enabledパラメーターを使用して、リソース グループに基づいたリクエストのスケジューリングを使用するかどうかを制御できます。
• TiFlash: tidb_enable_resource_controlシステム変数とenable_resource_control構成項目 (v7.4.0 で導入) を使用して、 TiFlashリソース制御を有効にするかどうかを制御できます。

• TiKV: TiDB セルフホストの場合、 resource-control.enabledパラメーターを使用して、リソース グループ クォータに基づいてリクエストのスケジューリングを使用するかどうかを制御できます。 TiDB Cloudの場合、 resource-control.enabledパラメーターの値はデフォルトでtrueであり、動的変更はサポートされていません。
• TiFlash: TiDB セルフホストの場合、 tidb_enable_resource_controlシステム変数とenable_resource_control構成項目 (v7.4.0 で導入) を使用して、 TiFlashリソース制御を有効にするかどうかを制御できます。

TiDB v7.0.0 以降、 tidb_enable_resource_controlとresource-control.enabledがデフォルトで有効になります。これら 2 つのパラメータを組み合わせた結果を次の表に示します。

v7.4.0 以降、 TiFlash構成項目enable_resource_controlはデフォルトで有効になっています。 tidb_enable_resource_controlと連携してTiFlashリソース制御機能を制御します。 TiFlashリソース制御は、 enable_resource_controlとtidb_enable_resource_controlの両方が有効な場合にのみ、フロー制御と優先スケジューリングを実行します。さらに、 enable_resource_controlが有効な場合、 TiFlash はパイプライン実行モデルを使用します。

v7.4.0 以降、 TiFlash構成項目enable_resource_controlはデフォルトで有効になっています。 tidb_enable_resource_controlと連携してTiFlashリソース制御機能を制御します。 TiFlashリソース制御は、 enable_resource_controlとtidb_enable_resource_controlの両方が有効な場合にのみ、フロー制御と優先スケジューリングを実行します。さらに、 enable_resource_controlが有効な場合、 TiFlash はパイプライン実行モデルを使用します。

リソース制御メカニズムとパラメータの詳細については、 RFC: TiDB におけるグローバル リソース制御およびTiFlashリソース制御を参照してください。

リソース制御の使用方法

このセクションでは、リソース制御機能を使用してリソース グループを管理し、各リソース グループのリソース割り当てを制御する方法について説明します。

クラスター容量の見積もり

リソースを計画する前に、クラスターの全体的な容量を把握する必要があります。 TiDB は、クラスター容量を見積もるためのステートメントCALIBRATE RESOURCEを提供します。次のいずれかの方法を使用できます。

• 実際のワークロードに基づいて容量を見積もる
• ハードウェア導入に基づいて容量を見積もる

リソースマネージャーページ TiDB ダッシュボードで確認できます。詳細については、 CALIBRATE RESOURCEを参照してください。

TiDB セルフホストの場合、 CALIBRATE RESOURCEステートメントを使用してクラスター容量を見積もることができます。

TiDB Cloudの場合、 CALIBRATE RESOURCEステートメントは適用されません。

リソースグループの管理

リソース グループを作成、変更、または削除するには、 SUPERまたはRESOURCE_GROUP_ADMIN権限が必要です。

CREATE RESOURCE GROUPを使用してクラスターのリソース グループを作成できます。

既存のリソース グループの場合、 ALTER RESOURCE GROUPを使用して、リソース グループのRU_PER_SECオプション (1 秒あたりの RU バックフィルの速度) を変更できます。リソース グループへの変更はすぐに有効になります。

DROP RESOURCE GROUPを使用してリソース グループを削除できます。

リソースグループを作成する

以下にリソースグループの作成例を示します。

1. リソース グループを作成しますrg1 。リソース制限は 1 秒あたり 500 RU であり、このリソース グループ内のアプリケーションがリソースを超過することが許可されます。

   CREATE RESOURCE GROUP IF NOT EXISTS rg1 RU_PER_SEC = 500 BURSTABLE;
   

2. リソース グループを作成しますrg2 。 RU バックフィル レートは 600 RU/秒であり、このリソース グループ内のアプリケーションがリソースを超過することはありません。

   CREATE RESOURCE GROUP IF NOT EXISTS rg2 RU_PER_SEC = 600;
   

3. 絶対優先度をHIGHに設定してリソース グループrg3を作成します。絶対優先度は現在LOW|MEDIUM|HIGHをサポートしています。デフォルト値はMEDIUMです。

   CREATE RESOURCE GROUP IF NOT EXISTS rg3 RU_PER_SEC = 100 PRIORITY = HIGH;
   

リソースグループをバインドする

TiDB は、次の 3 レベルのリソース グループ設定をサポートしています。

• ユーザーレベル。 CREATE USERまたはALTER USERステートメントを使用して、ユーザーを特定のリソース グループにバインドします。ユーザーがリソース グループにバインドされると、ユーザーが作成したセッションは、対応するリソース グループに自動的にバインドされます。
• セッションレベル。 SET RESOURCE GROUPを介して現在のセッションのリソース グループを設定します。
• 発言レベル。 RESOURCE_GROUP()オプティマイザー ヒントを使用して、現在のステートメントのリソース グループを設定します。

ユーザーをリソース グループにバインドする

次の例では、ユーザーusr1を作成し、そのユーザーをリソース グループrg1にバインドします。 rg1は、 リソースグループの作成の例で作成されたリソース グループです。

CREATE USER 'usr1'@'%' IDENTIFIED BY '123' RESOURCE GROUP rg1;

次の例では、 ALTER USERを使用してユーザーusr2リソース グループrg2にバインドします。 rg2は、 リソースグループの作成の例で作成されたリソース グループです。

ALTER USER usr2 RESOURCE GROUP rg2;

ユーザーをバインドすると、新しく作成されたセッションのリソース消費は、指定されたクォータ (リクエスト ユニット、RU) によって制御されます。システムのワークロードが比較的高く、空き容量がない場合は、リソース消費率usr2クォータを超えないように厳密に制御されます。 BURSTABLEが構成されている場合、 usr1はrg1によってバインドされているため、 usr1の消費率がクォータを超えることが許可されます。

リクエストが多すぎてリソース グループのリソースが不足する場合、クライアントのリクエストは待機します。待機時間が長すぎる場合、リクエストはエラーを報告します。

注記：

• CREATE USERまたはALTER USERを使用してユーザーをリソース グループにバインドすると、その効果はユーザーの既存のセッションではなく、ユーザーの新しいセッションに対してのみ有効になります。
• TiDB は、クラスターの初期化中にdefaultリソース グループを自動的に作成します。このリソース グループのデフォルト値RU_PER_SECはUNLIMITED ( INTタイプの最大値、つまり2147483647に相当) で、 BURSTABLEモードです。リソース グループにバインドされていないステートメントは、自動的にこのリソース グループにバインドされます。このリソース グループは削除をサポートしていませんが、RU の構成は変更できます。

リソース グループからユーザーのバインドを解除するには、次のようにユーザーをdefaultグループに再度バインドするだけです。

ALTER USER 'usr3'@'%' RESOURCE GROUP `default`;

詳細については、 ALTER USER ... RESOURCE GROUPを参照してください。

現在のセッションをリソース グループにバインドする

セッションをリソース グループにバインドすることにより、対応するセッションのリソース使用量は、指定された使用量 (RU) によって制限されます。

次の例では、現在のセッションをリソース グループrg1にバインドします。

SET RESOURCE GROUP rg1;

現在のステートメントをリソース グループにバインドします

SQL ステートメントにRESOURCE_GROUP(resource_group_name)ヒントを追加すると、ステートメントがバインドされるリソース グループを指定できます。このヒントは、 SELECT 、 INSERT 、 UPDATE 、およびDELETEステートメントをサポートします。

次の例では、現在のステートメントをリソース グループrg1にバインドします。

SELECT /*+ RESOURCE_GROUP(rg1) */ * FROM t limit 10;

予想よりも多くのリソースを消費するクエリを管理する (暴走クエリ)

暴走クエリとは、予想よりも多くの時間またはリソースを消費するクエリ ( SELECTステートメントのみ) です。以下では、ランナウェイ クエリという用語は、ランナウェイ クエリを管理する機能を説明するために使用されます。

• v7.2.0 以降、リソース制御機能に暴走クエリの管理が導入されています。リソース グループの基準を設定して暴走クエリを特定し、リソースを使い果たしたり他のクエリに影響を与えたりすることを防ぐためのアクションを自動的に実行できます。 CREATE RESOURCE GROUPまたはALTER RESOURCE GROUPにQUERY_LIMITフィールドを含めることで、リソース グループの暴走クエリを管理できます。
• v7.3.0 以降、リソース制御機能に暴走監視の手動管理が導入され、特定の SQL ステートメントまたはダイジェストの暴走クエリを迅速に特定できるようになりました。ステートメントQUERY WATCHを実行して、リソース グループ内の暴走クエリ ウォッチ リストを手動で管理できます。

QUERY_LIMITパラメータ

サポートされている条件設定:

• EXEC_ELAPSED : クエリの実行時間がこの制限を超えると、クエリは暴走クエリとして識別されます。

サポートされている操作 ( ACTION ):

• DRYRUN : アクションは実行されません。レコードは暴走クエリに追加されます。主に条件設定が妥当かどうかを観察するために使用されます。
• COOLDOWN : クエリの実行優先度は最低レベルに下げられます。クエリは最も低い優先順位で実行を継続し、他の操作のリソースを占有しません。
• KILL : 識別されたクエリは自動的に終了し、 Query execution was interrupted, identified as runaway queryを報告します。

システム リソースを使い果たす同時実行の暴走クエリを回避するために、リソース制御機能には、暴走クエリを迅速に特定して隔離できる迅速な識別メカニズムが導入されています。この機能はWATCH句を通じて使用できます。クエリが暴走クエリとして識別されると、このメカニズムはクエリの一致する特徴 ( WATCHの後のパラメータによって定義される) を抽出します。次の期間 ( DURATIONで定義) では、暴走クエリの一致機能がウォッチ リストに追加され、TiDB インスタンスはクエリをウォッチ リストと一致させます。一致するクエリは、条件によって識別されるのを待つのではなく、暴走クエリとして直接マークされ、対応するアクションに従って分離されます。 KILL操作によりクエリが終了し、エラーが報告されますQuarantined and interrupted because of being in runaway watch list 。

WATCH素早く識別するために一致させる方法は 3 つあります。

• EXACT 、まったく同じ SQL テキストを持つ SQL ステートメントのみがすぐに識別されることを示します。
• SIMILAR同じパターンを持つすべての SQL ステートメントがプラン ダイジェストによって照合され、リテラル値が無視されることを示します。
• PLAN同じパターンを持つすべての SQL ステートメントがプラン ダイジェストによって照合されることを示します。

WATCHのDURATIONオプションは、識別アイテムの継続時間を示します。デフォルトでは無限です。

監視アイテムが追加された後、 QUERY_LIMIT構成が変更または削除されるたびに、マッチング機能もACTION変更または削除されません。 QUERY WATCH REMOVE使用して監視アイテムを削除できます。

QUERY_LIMITのパラメータは次のとおりです。

例

1. 1 秒あたり 500 RU のクォータを持つリソース グループrg1を作成し、60 秒を超える暴走クエリとして定義し、暴走クエリの優先順位を下げます。

   CREATE RESOURCE GROUP IF NOT EXISTS rg1 RU_PER_SEC = 500 QUERY_LIMIT=(EXEC_ELAPSED='60s', ACTION=COOLDOWN);
   

2. rg1リソース グループを変更して暴走クエリを終了し、次の 10 分間に同じパターンのクエリを直ちに暴走クエリとしてマークします。

   ALTER RESOURCE GROUP rg1 QUERY_LIMIT=(EXEC_ELAPSED='60s', ACTION=KILL, WATCH=SIMILAR DURATION='10m');
   

3. rg1リソース グループを変更して、暴走クエリのチェックをキャンセルします。

   ALTER RESOURCE GROUP rg1 QUERY_LIMIT=NULL;
   

QUERY WATCHパラメータ

QUERY WATCHのあらすじについて詳しくは、 QUERY WATCHをご覧ください。

パラメータは次のとおりです。

• RESOURCE GROUPはリソース グループを指定します。このステートメントによって追加された暴走クエリの一致機能は、リソース グループのウォッチ リストに追加されます。このパラメータは省略可能です。省略した場合は、 defaultリソースグループに適用されます。

• ACTIONの意味はQUERY LIMITと同じです。このパラメータは省略可能です。省略した場合、識別後の対応するアクションはリソースグループのQUERY LIMITで設定されたACTIONを採用し、 QUERY LIMITの設定とアクションは変わりません。リソース グループにACTION構成されていない場合、エラーが報告されます。

• QueryWatchTextOptionパラメーターにはSQL DIGEST 、 PLAN DIGEST 、およびSQL TEXTの 3 つのオプションがあります。

  • SQL DIGESTはSIMILARと同じです。次のパラメータは、文字列、ユーザー定義変数、または文字列の結果を生成するその他の式を受け入れます。文字列の長さは 64 である必要があり、これは TiDB のダイジェスト定義と同じです。
  • PLAN DIGESTはPLANと同じです。次のパラメータはダイジェスト文字列です。
  • SQL TEXT入力 SQL を生の文字列 ( EXACT ) として照合するか、次のパラメータに応じて解析してSQL DIGEST ( SIMILAR ) またはPLAN DIGEST ( PLAN ) にコンパイルします。

• デフォルトのリソース グループの暴走クエリ ウォッチ リストにマッチング機能を追加します (デフォルトのリソース グループに事前にQUERY LIMITを設定する必要があります)。

  QUERY WATCH ADD ACTION KILL SQL TEXT EXACT TO 'select * from test.t2';
  

• SQL を SQL ダイジェストに解析して、 rg1リソース グループの暴走クエリ ウォッチ リストに一致機能を追加します。 ACTIONが指定されていない場合は、 rg1リソース グループに対してすでに構成されているACTIONオプションが使用されます。

  QUERY WATCH ADD RESOURCE GROUP rg1 SQL TEXT SIMILAR TO 'select * from test.t2';
  

• PLAN DIGESTを使用して、 rg1リソース グループの暴走クエリ ウォッチ リストに一致機能を追加します。

  QUERY WATCH ADD RESOURCE GROUP rg1 ACTION KILL PLAN DIGEST 'd08bc323a934c39dc41948b0a073725be3398479b6fa4f6dd1db2a9b115f7f57';
  

• INFORMATION_SCHEMA.RUNAWAY_WATCHESをクエリして監視アイテム ID を取得し、監視アイテムを削除します。

  SELECT * from information_schema.runaway_watches ORDER BY id;
  

  *************************** 1. row ***************************
                  ID: 20003
  RESOURCE_GROUP_NAME: rg2
          START_TIME: 2023-07-28 13:06:08
          END_TIME: UNLIMITED
              WATCH: Similar
          WATCH_TEXT: 5b7fd445c5756a16f910192ad449c02348656a5e9d2aa61615e6049afbc4a82e
              SOURCE: 127.0.0.1:4000
              ACTION: Kill
  1 row in set (0.00 sec)
  

  QUERY WATCH REMOVE 20003;
  

可観測性

暴走クエリに関する詳細情報は、次のシステム テーブルとINFORMATION_SCHEMAから取得できます。

• mysql.tidb_runaway_queriesテーブルには、過去 7 日間に特定されたすべての暴走クエリの履歴レコードが含まれています。行の 1 つを例として取り上げます。

  MySQL [(none)]> SELECT * FROM mysql.tidb_runaway_queries LIMIT 1\G;
  *************************** 1. row ***************************
  resource_group_name: rg1
                 time: 2023-06-16 17:40:22
           match_type: identify
               action: kill
         original_sql: select * from sbtest.sbtest1
          plan_digest: 5b7d445c5756a16f910192ad449c02348656a5e9d2aa61615e6049afbc4a82e
          tidb_server: 127.0.0.1:4000
  

  前述の出力では、 match_type暴走クエリがどのように識別されるかを示します。値は次のいずれかになります。

  • identifyは暴走クエリの条件に一致することを意味します。
  • watch 、監視リストのクイック識別ルールに一致することを意味します。

• information_schema.runaway_watchesテーブルには、暴走クエリの迅速な識別ルールのレコードが含まれています。詳細については、 RUNAWAY_WATCHESを参照してください。

バックグラウンドタスクを管理する

データのバックアップや自動統計収集などのバックグラウンド タスクは優先度は低いですが、多くのリソースを消費します。これらのタスクは通常、定期的または不定期にトリガーされます。実行中に大量のリソースが消費されるため、オンラインの優先度の高いタスクのパフォーマンスに影響します。

v7.4.0 以降、TiDB リソース制御機能はバックグラウンド タスクの管理をサポートします。タスクがバックグラウンド タスクとしてマークされている場合、TiKV は、他のフォアグラウンド タスクのパフォーマンスへの影響を避けるために、このタイプのタスクによって使用されるリソースを動的に制限します。 TiKV は、すべてのフォアグラウンド タスクによって消費される CPU および IO リソースをリアルタイムで監視し、インスタンスの合計リソース制限に基づいてバックグラウンド タスクによって使用できるリソースのしきい値を計算します。すべてのバックグラウンド タスクは、実行中にこのしきい値によって制限されます。

BACKGROUNDパラメータ

TASK_TYPES : バックグラウンド タスクとして管理する必要があるタスク タイプを指定します。複数のタスク タイプを区切るには、カンマ ( , ) を使用します。

TiDB は、次のタイプのバックグラウンド タスクをサポートします。

• lightning : TiDB Lightningを使用してインポート タスクを実行します。 TiDB Lightningの物理インポート モードと論理インポート モードの両方がサポートされています。
• br : BRを使用してバックアップおよび復元タスクを実行します。 PITR はサポートされていません。
• ddl : Reorg DDL のバッチ データ ライトバック フェーズ中のリソース使用量を制御します。
• stats : 手動で実行されるか、TiDB によって自動的にトリガーされる統計を収集するタスク。
• background : 予約されたタスクタイプ。 tidb_request_source_typeシステム変数を使用して、現在のセッションのタスク タイプをbackgroundとして指定できます。

• lightning : TiDB Lightningを使用してインポート タスクを実行します。 TiDB Lightningの物理インポート モードと論理インポート モードの両方がサポートされています。
• br : BRを使用してバックアップおよび復元タスクを実行します。 PITR はサポートされていません。
• ddl : Reorg DDL のバッチ データ ライトバック フェーズ中のリソース使用量を制御します。
• stats : 手動で実行されるか、TiDB によって自動的にトリガーされる統計を収集するタスク。
• background : 予約されたタスクタイプ。 tidb_request_source_typeシステム変数を使用して、現在のセッションのタスク タイプをbackgroundとして指定できます。

デフォルトでは、バックグラウンド タスクとしてマークされているタスク タイプは""で、バックグラウンド タスクの管理は無効になっています。バックグラウンド タスク管理を有効にするには、 defaultリソース グループのバックグラウンド タスクの種類を手動で変更する必要があります。バックグラウンド タスクが識別され、一致すると、リソース制御が自動的に実行されます。これは、システム リソースが不十分な場合、フォアグラウンド タスクが確実に実行されるように、バックグラウンド タスクの優先順位が自動的に最も低いことを意味します。

注記：

現在、すべてのリソース グループのバックグラウンド タスクはdefaultリソース グループにバインドされています。 defaultを通じてバックグラウンド タスクの種類をグローバルに管理できます。バックグラウンド タスクを他のリソース グループにバインドすることは現在サポートされていません。

例

1. defaultリソース グループを変更し、 brとddlをバックグラウンド タスクとしてマークします。

   ALTER RESOURCE GROUP `default` BACKGROUND=(TASK_TYPES='br,ddl');
   

2. defaultリソース グループを変更して、バックグラウンド タスクの種類をデフォルト値に戻します。

   ALTER RESOURCE GROUP `default` BACKGROUND=NULL;
   

3. defaultリソース グループを変更して、バックグラウンド タスク タイプを空に設定します。この場合、このリソース グループのすべてのタスクはバックグラウンド タスクとして扱われません。

   ALTER RESOURCE GROUP `default` BACKGROUND=(TASK_TYPES="");
   

4. defaultリソース グループのバックグラウンド タスク タイプをビュー。

   SELECT * FROM information_schema.resource_groups WHERE NAME="default";
   

   出力は次のとおりです。

   +---------+------------+----------+-----------+-------------+---------------------+
   | NAME    | RU_PER_SEC | PRIORITY | BURSTABLE | QUERY_LIMIT | BACKGROUND          |
   +---------+------------+----------+-----------+-------------+---------------------+
   | default | UNLIMITED  | MEDIUM   | YES       | NULL        | TASK_TYPES='br,ddl' |
   +---------+------------+----------+-----------+-------------+---------------------+
   

5. 現在のセッションのタスクをバックグラウンド タイプとして明示的にマークするには、 tidb_request_source_typeを使用してタスク タイプを明示的に指定します。以下は例です。

   SET @@tidb_request_source_type="background";
   /* Add background task type */
   ALTER RESOURCE GROUP `default` BACKGROUND=(TASK_TYPES="background");
   /* Execute LOAD DATA in the current session */
   LOAD DATA INFILE "s3://resource-control/Lightning/test.customer.aaaa.csv"
   

リソース制御を無効にする

1. リソース制御機能を無効にするには、次のステートメントを実行します。

   SET GLOBAL tidb_enable_resource_control = 'OFF';
   

2. リソース グループの RU に基づくスケジューリングを無効にするには、TiKV パラメーターをresource-control.enabled ～ falseに設定します。

3. TiFlash設定項目enable_resource_control ～ falseを設定して、 TiFlashリソース制御を無効にします。

1. リソース制御機能を無効にするには、次のステートメントを実行します。

   SET GLOBAL tidb_enable_resource_control = 'OFF';
   

2. TiDB セルフホストの場合、 resource-control.enabledパラメーターを使用して、リソース グループ クォータに基づいてリクエストのスケジューリングを使用するかどうかを制御できます。 TiDB Cloudの場合、 resource-control.enabledパラメーターの値はデフォルトでtrueであり、動的変更はサポートされていません。 TiDB 専用クラスターでこれを無効にする必要がある場合は、 TiDB Cloudのサポートにお問い合わせください。

3. TiDB セルフホストの場合、 enable_resource_control構成項目を使用して、 TiFlashリソース制御を有効にするかどうかを制御できます。 TiDB Cloudの場合、 enable_resource_controlパラメーターの値はデフォルトでtrueであり、動的変更はサポートされていません。 TiDB 専用クラスターでこれを無効にする必要がある場合は、 TiDB Cloudのサポートにお問い合わせください。

RU 消費量をビュー

RU の消費に関する情報を表示できます。

SQLによるRU消費量をビュー

SQL ステートメントの RU 消費量は、次の方法で表示できます。

• システム変数tidb_last_query_info
• EXPLAIN ANALYZE
• 遅いクエリと対応するシステム テーブル
• statements_summary

システム変数tidb_last_query_infoをクエリして、最後の SQL 実行によって消費された RUをビュー。

TiDB はシステム変数tidb_last_query_infoを提供します。このシステム変数は、SQL の実行によって消費された RU など、最後に実行された DML ステートメントの情報を記録します。

例：

1. UPDATEステートメントを実行します。

   UPDATE sbtest.sbtest1 SET k = k + 1 WHERE id = 1;
   

   Query OK, 1 row affected (0.01 sec)
   Rows matched: 1  Changed: 1  Warnings: 0
   

2. システム変数tidb_last_query_infoをクエリして、最後に実行されたステートメントの情報を表示します。

   SELECT @@tidb_last_query_info;
   

   +------------------------------------------------------------------------------------------------------------------------+
   | @@tidb_last_query_info                                                                                                 |
   +------------------------------------------------------------------------------------------------------------------------+
   | {"txn_scope":"global","start_ts":446809472210829315,"for_update_ts":446809472210829315,"ru_consumption":4.34885578125} |
   +------------------------------------------------------------------------------------------------------------------------+
   1 row in set (0.01 sec)
   

   結果のru_consumption 、この SQL ステートメントの実行によって消費される RU です。

EXPLAIN ANALYZEによる SQL 実行中に消費された RU をビュー

EXPLAIN ANALYZEステートメントを使用すると、SQL 実行中に消費された RU の量を取得できます。 RU の量はキャッシュの影響を受けることに注意してください (たとえば、 コプロセッサキャッシュ )。同じ SQL が複数回実行されると、各実行で消費される RU の量が異なる場合があります。 RU 値は各実行の正確な値を表すものではありませんが、推定の参考として使用できます。

遅いクエリと対応するシステム テーブル

リソース制御を有効にすると、TiDB の遅いクエリログと対応するシステム テーブルINFORMATION_SCHEMA.SLOW_QUERYには、リソース グループ、対応する SQL の RU 消費量、および使用可能な RU の待機に費やされた時間が含まれます。

リソース制御を有効にすると、システム テーブルINFORMATION_SCHEMA.SLOW_QUERYには、リソース グループ、対応する SQL の RU 消費量、および使用可能な RU の待機に費やされた時間が含まれます。

statements_summaryによる RU 統計のビュー

TiDB のシステム テーブルINFORMATION_SCHEMA.statements_summaryには、SQL ステートメントの正規化および集計された統計が保存されます。システム テーブルを使用して、SQL ステートメントの実行パフォーマンスを表示および分析できます。また、リソース グループ名、RU 消費量、使用可能な RU を待機するのに費やした時間など、リソース制御に関する統計も含まれます。詳細については、 statements_summaryフィールドの説明を参照してください。

モニタリング指標とグラフ

TiDB はリソース制御に関する実行時情報を定期的に収集し、Grafana の[TiDB] > [リソース制御]ダッシュボードにメトリクスの視覚的なグラフを提供します。メトリクスについては、 TiDB の重要なモニタリング指標の「リソース制御」セクションで詳しく説明されています。

TiKV は、さまざまなリソース グループからのリクエスト QPS も記録します。詳細については、 TiKV モニタリング メトリクスの詳細を参照してください。

TiDB ダッシュボードの現在のRESOURCE_GROUPSのテーブルでリソース グループのデータを表示できます。詳細については、 リソースマネージャーページを参照してください。

注記：

このセクションは、TiDB セルフホスト型にのみ適用されます。現在、 TiDB Cloud はリソース制御メトリクスを提供していません。

TiDB はリソース制御に関するランタイム情報を定期的に収集し、Grafana の[TiDB] > [リソース制御]ダッシュボードにメトリクスの視覚的なグラフを提供します。

TiKV は、Grafana のTiKVダッシュボードにさまざまなリソース グループからのリクエスト QPS も記録します。

ツールの互換性

リソース制御機能は、データのインポート、エクスポート、その他のレプリケーション ツールの通常の使用には影響しません。 BR、 TiDB Lightning、および TiCDC は現在、リソース制御に関連する DDL 操作の処理をサポートしていません。また、それらのリソース消費はリソース制御によって制限されません。

FAQ

1. リソース グループを使用したくない場合は、リソース制御を無効にする必要がありますか?

   いいえ。リソース グループを指定しないユーザーは、無制限のリソースを持つdefaultリソース グループにバインドされます。すべてのユーザーがdefaultリソースグループに所属している場合、リソースの割り当て方法はリソース制御が無効な場合と同じになります。

2. データベース ユーザーを複数のリソース グループにバインドできますか?

   いいえ。データベース ユーザーは 1 つのリソース グループにのみバインドできます。ただし、セッションの実行中は、 SET RESOURCE GROUPを使用して、現在のセッションで使用されるリソース グループを設定できます。オプティマイザ ヒントRESOURCE_GROUP()使用して、実行中のステートメントのリソース グループを設定することもできます。

3. すべてのリソース グループのリソース割り当ての合計 ( RU_PER_SEC ) がシステム容量を超えるとどうなりますか?

   TiDB は、リソース グループの作成時に容量を検証しません。システムに十分な使用可能なリソースがある限り、TiDB は各リソース グループのリソース要件を満たすことができます。システム リソースが制限を超えると、TiDB は優先度の高いリソース グループからの要求を満たすことを優先します。同じ優先度のリクエストをすべて満たすことができない場合、TiDB はリソース割り当て ( RU_PER_SEC ) に従って比例的にリソースを割り当てます。

こちらも参照

• リソースグループの作成
• リソースグループの変更
• リソースグループを削除
• リソースグループ RFC