リソース制御を使用してリソースグループの制限とフロー制御を実現する
注記:
この機能は、クラスターTiDB CloudスターターおよびTiDB Cloudエッセンシャルでは利用できません。
クラスター管理者は、リソース制御機能を使用して、リソース グループを作成したり、リソース グループのクォータを設定したり、ユーザーをそれらのグループにバインドしたりできます。
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 TiDB Cloud Starter RUについては、 TiDB Cloud Starter の価格詳細参照してください。
- 現在、 TiFlashリソース制御では、クエリのパイプライン タスクの実行によって消費される CPU 時間である SQL CPU と、読み取り要求ペイロードのみが考慮されます。
リソース制御のパラメータ
リソース制御機能では、次のシステム変数またはパラメータが導入されています。
- TiDB:
tidb_enable_resource_control
システム変数を使用して、リソース グループのフロー制御を有効にするかどうかを制御できます。
- TiKV: TiDB Self-Managed の場合、パラメータ
resource-control.enabled
使用して、リソースグループのクォータに基づくリクエストスケジューリングを使用するかどうかを制御できます。TiDB TiDB Cloudの場合、パラメータresource-control.enabled
の値はデフォルトでtrue
設定されており、動的な変更はサポートされていません。 - TiFlash: TiDB Self-Managed の場合、
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 Self-Managed の場合、 CALIBRATE RESOURCE
ステートメントを使用してクラスターの容量を見積もることができます。
TiDB Cloudの場合、 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
参照。
現在のセッションをリソースグループにバインドする
SET RESOURCE GROUP
ステートメントを使用すると、現在のセッションにバインドされているリソースグループを変更できます。セッションをリソースグループにバインドすると、対応するセッションのリソース使用量は指定された使用量(RU)に制限されます。
システム変数tidb_resource_control_strict_mode
ON
に設定されている場合、このステートメントを実行するにはSUPER
、 RESOURCE_GROUP_ADMIN
、またはRESOURCE_GROUP_USER
権限が必要です。
次の例では、現在のセッションをリソース グループrg1
にバインドします。
SET RESOURCE GROUP rg1;
現在のステートメントをリソース グループにバインドする
SQL文にRESOURCE_GROUP(resource_group_name)
ヒントを追加することで、文がバインドされるリソースグループを指定できます。このヒントは、 SELECT
、 INSERT
、 UPDATE
、およびDELETE
文をサポートします。
システム変数tidb_resource_control_strict_mode
ON
に設定されている場合、このヒントを使用するにはSUPER
、 RESOURCE_GROUP_ADMIN
、またはRESOURCE_GROUP_USER
権限が必要です。
次の例では、現在のステートメントをリソース グループrg1
にバインドします。
SELECT /*+ RESOURCE_GROUP(rg1) */ * FROM t limit 10;
リソース制御を無効にする
リソース制御機能を無効にするには、次のステートメントを実行します。
SET GLOBAL tidb_enable_resource_control = 'OFF';TiDB Self-Managed の場合、パラメータ
resource-control.enabled
使用して、リソースグループのクォータに基づくリクエストスケジューリングを使用するかどうかを制御できます。TiDB TiDB Cloudの場合、パラメータresource-control.enabled
の値はデフォルトでtrue
設定されており、動的な変更はサポートされていません。TiDB TiDB Cloud Dedicated クラスターでこのパラメータを無効にする必要がある場合は、 TiDB Cloudサポートお問い合わせください。TiDB Self-Managed の場合、設定項目
enable_resource_control
使用して、 TiFlashリソース制御を有効にするかどうかを制御できます。TiDB TiDB Cloudの場合、パラメータenable_resource_control
の値はデフォルトでtrue
設定されており、動的な変更はサポートされていません。TiDB TiDB Cloud Dedicated クラスターで無効にする必要がある場合は、 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文の情報を記録します。
例:
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の値は各実行の正確な値を表すものではありませんが、概算の参考として使用できます。
遅いクエリとそれに対応するシステムテーブル
リソース制御を有効にすると、システム テーブル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セルフマネージドにのみ適用されます。現在、 TiDB Cloudはリソース制御メトリックを提供していません。
TiDB は、リソース制御に関する実行時情報を定期的に収集し、Grafana のTiDB >リソース制御ダッシュボードにメトリックの視覚的なグラフを提供します。
TiKV は、Grafana のTiKVダッシュボード内のさまざまなリソース グループからの要求 QPS も記録します。
ツールの互換性
リソース制御機能は、データのインポート、エクスポート、およびその他のレプリケーション ツールの通常の使用には影響しませんBR、 TiDB Lightning、および TiCDC は現在、リソース制御に関連する DDL 操作の処理をサポートしておらず、それらのリソース消費はリソース制御によって制限されません。
FAQ
リソース グループを使用しない場合は、リソース制御を無効にする必要がありますか?
いいえ。リソースグループを指定しないユーザーは、リソースが無制限のリソースグループ
default
にバインドされます。すべてのユーザーがリソースグループdefault
に所属している場合、リソースの割り当て方法はリソース制御が無効の場合と同じです。データベース ユーザーを複数のリソース グループにバインドできますか?
いいえ。データベースユーザーは1つのリソースグループにのみバインドできます。ただし、セッション実行時には、
SET RESOURCE GROUP
使用して現在のセッションで使用されるリソースグループを設定できます。また、オプティマイザヒントRESOURCE_GROUP()
使用して、実行中のステートメントのリソースグループを設定することもできます。すべてのリソースグループの合計リソース割り当て(
RU_PER_SEC
)がシステム容量を超えるとどうなりますか?TiDBは、リソースグループ作成時にキャパシティを検証しません。システムに十分なリソースがある限り、TiDBは各リソースグループのリソース要件を満たすことができます。システムリソースが制限を超えた場合、TiDBは優先度の高いリソースグループからの要求を優先的に満たします。同じ優先度の要求をすべて満たせない場合は、TiDBはリソース割り当て(
RU_PER_SEC
)に従ってリソースを比例配分します。