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

注記：
この機能はTiDB Cloudサーバーレスクラスターでは利用できません。

クラスター管理者は、リソース制御機能を使用して、リソースグループを作成したり、リソースグループのクォータを設定したり、ユーザーをそれらのグループにバインドしたりできます。

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

TiDBフロー制御：TiDBフロー制御はトークンバケットアルゴリズム使用します。バケット内に十分なトークンがなく、リソースグループでBURSTABLEオプションが指定されていない場合、リソースグループへのリクエストはトークンバケットがトークンをバックフィルするまで待機し、再試行されます。再試行はタイムアウトにより失敗する可能性があります。
TiKVスケジューリング：必要に応じて絶対優先度（ PRIORITY ）設定できます。3 PRIORITY設定に応じて、異なるリソースがスケジュールされますPRIORITYの高いタスクが最初にスケジュールされます。絶対優先度を設定しない場合、TiKVは各リソースグループのRU_PER_SECの値を使用して、各リソースグループの読み取りおよび書き込み要求の優先度を決定します。storageレイヤーは、この優先度に基づいて、優先キューを使用して要求をスケジュールおよび処理します。

バージョン7.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 倍になります。

リソース管理のシナリオ

リソース制御機能の導入は、TiDBにとって画期的な出来事です。この機能により、分散データベースクラスタを複数の論理ユニットに分割できます。個々のユニットがリソースを過剰に使用しても、他のユニットに必要なリソースが圧迫されることはありません。

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

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

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

注記：
リソース管理の有効性を評価するには、独立したコンピューティングノードとstorageノードにクラスタを展開することをお勧めしますtiup playgroundで作成されたデプロイメントでは、リソースがインスタンス間で共有されるため、スケジューリングなどのクラスタリソースに依存する機能は正常に動作しにくいです。

制限事項

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

リクエストユニット（RU）とは

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

リソースタイプ	RU消費量
読む	2 つのstorage読み取りバッチは 1 RU を消費します
	8 回のstorage読み取り要求で 1 RU が消費される
	64 KiBの読み取り要求ペイロードは1 RUを消費します
書く	1 回のstorage書き込みバッチで 1 RU が消費されます
	1 回のstorage書き込み要求で 1 RU が消費される
	1 KiBの書き込み要求ペイロードは1 RUを消費します
CPU	3 ミリ秒で 1 RU を消費します

注記：
各書き込み操作は最終的にすべてのレプリカに複製されます（デフォルトでは、TiKV には 3 つのレプリカがあります）。各レプリケーション操作はそれぞれ異なる書き込み操作とみなされます。
上記の表は、TiDBセルフマネージドクラスターのRU計算に関係するリソースのみを示しており、ネットワークとstorageの消費量は含まれていません。TiDB TiDB Cloud ServerlessのRUについては、 TiDB Cloud Serverless の価格詳細参照してください。
現在、 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リソース制御を有効にするかどうかを制御できます。

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

`resource-control.enabled`	`tidb_enable_resource_control` = オン	`tidb_enable_resource_control` = オフ
`resource-control.enabled` = 真	フロー制御とスケジューリング（推奨）	無効な組み合わせ
`resource-control.enabled` = 偽	フロー制御のみ（非推奨）	この機能は無効になっています。

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

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

リソース制御の使い方

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

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

リソースプランニングを行う前に、クラスタ全体のキャパシティを把握しておく必要があります。TiDBは、クラスタキャパシティを見積もるためのステートメントCALIBRATE RESOURCEを提供しています。以下のいずれかの方法を使用できます。

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

リソースグループを管理する

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

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

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

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

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

以下は、リソースグループを作成する方法の例です。

リソースグループrg1を作成します。リソース制限は 1 秒あたり 500 RU で、このリソースグループ内のアプリケーションがリソースをオーバーランすることを許可します。
```
CREATE RESOURCE GROUP IF NOT EXISTS rg1 RU_PER_SEC = 500 BURSTABLE;
```
リソースグループrg2を作成します。RU バックフィルレートは 1 秒あたり 600 RU であり、このリソースグループ内のアプリケーションがリソースをオーバーランすることは許可されません。
```
CREATE RESOURCE GROUP IF NOT EXISTS rg2 RU_PER_SEC = 600;
```
絶対優先度をHIGHに設定したリソースグループrg3を作成します。現在、絶対優先度はLOW|MEDIUM|HIGHサポートされています。デフォルト値はMEDIUMです。
```
CREATE RESOURCE GROUP IF NOT EXISTS rg3 RU_PER_SEC = 100 PRIORITY = HIGH;
```

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

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

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

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

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

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

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

ALTER USER usr2 RESOURCE GROUP rg2;

ユーザーをバインドすると、新規に作成されたセッションのリソース消費量は、指定されたクォータ（リクエストユニット、RU）によって制御されます。システムのワークロードが比較的高く、余裕のある容量がない場合、リソース消費率usr2クォータを超えないように厳密に制御されます。3 usr1 rg1にバインドされ、 BURSTABLEが設定されているため、消費率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文のみ）のことです。以下では、ランナウェイクエリを管理する機能を説明するために「ランナウェイクエリ」という用語を使用します。

バージョン7.2.0以降、リソース制御機能にランナウェイクエリの管理機能が導入されました。リソースグループに対してランナウェイクエリを特定するための条件を設定し、ランナウェイクエリによるリソースの枯渇や他のクエリへの影響を防ぐためのアクションを自動的に実行できます。3 またはALTER RESOURCE GROUP CREATE RESOURCE GROUP QUERY_LIMITフィールドを含めることで、リソースグループのランナウェイクエリを管理できます。
バージョン7.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 ステートメントが SQL ダイジェストに一致し、リテラル値が無視されることを示します。
PLAN 、同じパターンを持つすべての SQL ステートメントがプランダイジェストに一致することを示します。

WATCHのDURATIONオプションは識別項目の有効期間を示し、デフォルトでは無期限です。

監視項目を追加した後、 QUERY_LIMIT設定が変更または削除されても、対応する機能とACTION変更または削除されません。監視項目を削除するにはQUERY WATCH REMOVE使用します。

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

パラメータ	説明	注記
`EXEC_ELAPSED`	クエリ実行時間がこの値を超えると、暴走クエリとして識別されます。	EXEC_ELAPSED = `60s` 、クエリの実行に 60 秒以上かかる場合、クエリがランナウェイクエリとして識別されることを意味します。
`ACTION`	暴走クエリが特定された場合に実行されるアクション	オプションの値は`DRYRUN` 、 `COOLDOWN` 、 `KILL`です。
`WATCH`	特定されたランナウェイクエリを迅速に照合します。一定時間内に同一または類似のクエリが再度検出された場合、対応するアクションが直ちに実行されます。	オプション。たとえば、 `WATCH=SIMILAR DURATION '60s'` 、 `WATCH=EXACT DURATION '1m'` 、 `WATCH=PLAN`などです。

例

1 秒あたり 500 RU のクォータを持つリソースグループrg1を作成し、60 秒を超えるクエリをランナウェイクエリとして定義し、ランナウェイクエリの優先順位を下げます。
```
CREATE RESOURCE GROUP IF NOT EXISTS rg1 RU_PER_SEC = 500 QUERY_LIMIT=(EXEC_ELAPSED='60s', ACTION=COOLDOWN);
```
rg1リソースグループを変更してランナウェイクエリを終了し、次の 10 分以内に同じパターンのクエリをランナウェイクエリとして直ちにマークします。
```
ALTER RESOURCE GROUP rg1 QUERY_LIMIT=(EXEC_ELAPSED='60s', ACTION=KILL, WATCH=SIMILAR DURATION='10m');
```
ランナウェイクエリチェックをキャンセルするには、 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と同じです。以下のパラメータは、文字列、ユーザー定義変数、または文字列を返すその他の式を受け入れます。文字列の長さは、TiDBのダイジェスト定義と同じ64文字である必要があります。
- 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ランナウェイクエリ監視リストに一致する機能を追加します。3 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参照してください。

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

警告

この機能は実験的です。本番環境での使用は推奨されません。この機能は予告なく変更または削除される可能性があります。バグを発見した場合は、GitHubで問題報告を行ってください。

リソース制御におけるバックグラウンドタスク管理は、TiKVによるCPU/IO使用率のリソースクォータの動的調整に基づいています。そのため、各インスタンスの利用可能なリソースクォータに依存します。複数のコンポーネントまたはインスタンスを単一のサーバーにデプロイする場合、 cgroupを通して各インスタンスに適切なリソースクォータを設定する必要があります。TiUP Playgroundのような共有リソースを持つデプロイメントでは、期待される効果を得ることが困難です。

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

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

`BACKGROUND`パラメータ

TASK_TYPES : バックグラウンドタスクとして管理する必要があるタスクの種類を指定します。複数のタスクの種類を指定する場合は、カンマ ( , ) で区切ります。

TiDB は次の種類のバックグラウンドタスクをサポートしています。

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

デフォルトでは、バックグラウンドタスクとしてマークされているタスクタイプは""で、バックグラウンドタスクの管理は無効になっています。バックグラウンドタスクの管理を有効にするには、リソースグループdefaultのバックグラウンドタスクタイプを手動で変更する必要があります。バックグラウンドタスクが識別され、マッチングされると、リソース制御が自動的に実行されます。つまり、システムリソースが不足している場合、バックグラウンドタスクの優先度は自動的に最低に下げられ、フォアグラウンドタスクの実行が確保されます。

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

例

defaultリソースグループを変更し、 brとddlバックグラウンドタスクとしてマークします。
```
ALTER RESOURCE GROUP `default` BACKGROUND=(TASK_TYPES='br,ddl');
```
defaultリソースグループを変更して、バックグラウンドタスクの種類を既定値に戻します。
```
ALTER RESOURCE GROUP `default` BACKGROUND=NULL;
```
defaultリソースグループを変更して、バックグラウンドタスクの種類を空に設定します。この場合、このリソースグループのすべてのタスクはバックグラウンドタスクとして扱われません。
```
ALTER RESOURCE GROUP `default` BACKGROUND=(TASK_TYPES="");
```

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' |
+---------+------------+----------+-----------+-------------+---------------------+

現在のセッションのタスクを明示的にバックグラウンドタイプとしてマークするには、 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"

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

リソース制御機能を無効にするには、次のステートメントを実行します。
```
SET GLOBAL tidb_enable_resource_control = 'OFF';
```
リソースグループの RU に基づくスケジュールを無効にするには、TiKV パラメータをresource-control.enabledからfalse設定します。
TiFlashリソース制御を無効にするには、 TiFlash構成項目enable_resource_controlをfalseに設定します。

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文の情報を記録します。

例：

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

最後に実行されたステートメントの情報を表示するには、システム変数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)

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

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

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

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

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

RU統計を`statements_summary`別にビュー

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

リソースグループの RU 消費量をビュー

v7.6.0 以降、TiDB は各リソースグループの RU 消費量の履歴レコードを保存するためのシステムテーブルmysql.request_unit_by_groupを提供します。

例：

SELECT * FROM request_unit_by_group LIMIT 5;

+----------------------------+----------------------------+----------------+----------+
| start_time                 | end_time                   | resource_group | total_ru |
+----------------------------+----------------------------+----------------+----------+
| 2024-01-01 00:00:00.000000 | 2024-01-02 00:00:00.000000 | default        |   334147 |
| 2024-01-01 00:00:00.000000 | 2024-01-02 00:00:00.000000 | rg1            |     4172 |
| 2024-01-01 00:00:00.000000 | 2024-01-02 00:00:00.000000 | rg2            |    34028 |
| 2024-01-02 00:00:00.000000 | 2024-01-03 00:00:00.000000 | default        |   334088 |
| 2024-01-02 00:00:00.000000 | 2024-01-03 00:00:00.000000 | rg1            |     3850 |
+----------------------------+----------------------------+----------------+----------+
5 rows in set (0.01 sec)

注記：
mysql.request_unit_by_groupのデータは、TiDBのスケジュールタスクによって毎日の終わりに自動的にインポートされます。特定の日にリソースグループのRU消費量が0の場合、レコードは生成されません。デフォルトでは、このテーブルには過去3か月間（最大92日間）のデータが保存されます。この期間を超えるデータは自動的にクリアされます。

メトリックとグラフの監視

TiDBはリソース制御に関する実行時情報を定期的に収集し、Grafanaの「TiDB >リソース制御」ダッシュボードにメトリクスの視覚的なチャートを提供します。メトリクスの詳細については、 TiDB の重要な監視メトリックの「リソース制御」セクションをご覧ください。

TiKVは、異なるリソースグループからのリクエストQPSも記録します。詳細については、 TiKV 監視メトリクスの詳細参照してください。

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

ツールの互換性

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

FAQ

リソースグループを使用しない場合は、リソース制御を無効にする必要がありますか?
いいえ。リソースグループを指定しないユーザーは、リソースが無制限のリソースグループdefaultにバインドされます。すべてのユーザーがリソースグループdefaultに所属している場合、リソースの割り当て方法はリソース制御が無効の場合と同じです。
データベースユーザーを複数のリソースグループにバインドできますか?
いいえ。データベースユーザーは1つのリソースグループにのみバインドできます。ただし、セッション実行時には、 SET RESOURCE GROUP使用して現在のセッションで使用されるリソースグループを設定できます。また、オプティマイザヒントRESOURCE_GROUP()使用して、実行中のステートメントのリソースグループを設定することもできます。
すべてのリソースグループの合計リソース割り当て（ RU_PER_SEC ）がシステム容量を超えるとどうなりますか？
TiDBは、リソースグループ作成時にキャパシティを検証しません。システムに十分なリソースがある限り、TiDBは各リソースグループのリソース要件を満たすことができます。システムリソースが制限を超えた場合、TiDBは優先度の高いリソースグループからの要求を優先的に満たします。同じ優先度の要求をすべて満たせない場合は、TiDBはリソース割り当て（ RU_PER_SEC ）に従ってリソースを比例配分します。