リソース制御を使用してリソースの分離を実現する
注記:
この機能はTiDB Cloud Serverlessクラスターでは利用できません。
クラスター管理者は、リソース制御機能を使用して、リソース グループを作成したり、リソース グループのクォータを設定したり、ユーザーをそれらのグループにバインドしたりできます。
TiDBリソース制御機能は、TiDBレイヤーのフロー制御機能とTiKVレイヤーの優先度スケジューリング機能という2層のリソース管理機能を提供します。これらの2つの機能は、個別に、または同時に有効化できます。詳細はリソース制御のパラメータご覧ください。これにより、TiDBレイヤーはリソースグループに設定されたクォータに基づいてユーザーの読み取りおよび書き込み要求のフローを制御し、TiKVレイヤーは読み取りおよび書き込みクォータにマッピングされた優先度に基づいて要求をスケジュールすることができます。これにより、アプリケーションのリソース分離を確保し、サービス品質(QoS)要件を満たすことができます。
TiDBフロー制御:TiDBフロー制御はトークンバケットアルゴリズム使用します。バケット内に十分なトークンがなく、リソースグループで
BURSTABLE
オプションが指定されていない場合、リソースグループへのリクエストはトークンバケットがトークンをバックフィルするまで待機し、再試行されます。再試行はタイムアウトにより失敗する可能性があります。TiKVスケジューリング:必要に応じて絶対優先度(
PRIORITY
)設定できます。3PRIORITY
設定に応じて、異なるリソースがスケジュールされます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 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
ランナウェイクエリ監視リストに一致する機能を追加します。3ACTION
指定されていない場合は、リソースグループ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
参照してください。
バックグラウンドタスクを管理する
データのバックアップや自動統計収集などのバックグラウンドタスクは、優先度が低いにもかかわらず、多くのリソースを消費します。これらのタスクは通常、定期的または不定期に実行されます。実行中は多くのリソースを消費するため、オンラインの高優先度タスクのパフォーマンスに影響を与えます。
バージョン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
)に従ってリソースを比例配分します。