📣
TiDB Cloud Essential はパブリックプレビュー中です。このページは自動翻訳されたものです。原文はこちらからご覧ください。
TiDB Cloud
TiDB Self-Managed
Learning Center
お問い合わせ

リソース制御を使用してリソースグループの制限とフロー制御を実現する

注記：

この機能は、クラスターTiDB CloudスターターおよびTiDB Cloudエッセンシャルでは利用できません。

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

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

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

  • TiKVスケジューリング：必要に応じて絶対優先度（ PRIORITY ）設定できます。3 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 倍になります。

バックグラウンド タスクを管理し、リソースを大量に消費するクエリ (ランナウェイ クエリ) を処理する方法については、次のドキュメントを参照してください。

リソース管理のシナリオ

リソース制御機能の導入は、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: 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.enabledtidb_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使用してリソース グループを削除できます。

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

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

  1. リソース グループrg1を作成します。リソース制限は 1 秒あたり 500 RU で、このリソース グループ内のアプリケーションはリソースをオーバーランできます。

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

  2. リソース グループrg2を作成します。RU バックフィル レートは 1 秒あたり 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 つのレベルのリソース グループ設定をサポートしています。

  • ユーザーレベル。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;

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

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

    SET GLOBAL tidb_enable_resource_control = 'OFF';

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

  3. 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ステートメントの情報を記録します。

例：

  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 を待機するのに費やされた時間が含まれます。

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

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

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

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

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

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

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

参照

このページは役に立ちましたか？