TiDB Cloud
TiDB Self-Managed
Learning Center
お問い合わせ

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

注記：

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

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

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

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

  • TiKV スケジューリング: 必要に応じて絶対優先度（ PRIORITY ）を設定できます。3 PRIORITY設定に応じて、さまざまなリソースがスケジュールされます。5 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 にとって画期的な出来事です。この機能により、分散データベース クラスターを複数の論理ユニットに分割できます。個々のユニットがリソースを過剰に使用しても、他のユニットに必要なリソースが圧迫されることはありません。

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

  • 異なるシステムの複数の中小規模のアプリケーションを 1 つの 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の読み取り要求ペイロードは1RUを消費します
書く1 回のstorage書き込みバッチで 1 RU が消費される
1 回のstorage書き込み要求で 1 RU が消費される
1 KiBの書き込み要求ペイロードは1 RUを消費します
CPU 3 ミリ秒で 1 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リソース制御を有効にするかどうかを制御できます。

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リソース制御機能を制御します。TiFlash リソース制御は、 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のリソース消費率はクォータを超えないように厳密に制御されます。7 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のパラメータは次のとおりです。

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

例

  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リソース グループのランナウェイ クエリ監視リストに一致する機能を追加します。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を参照してください。

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

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

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

BACKGROUNDパラメータ

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

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

  • lightning : TiDB Lightningを使用してインポート タスクを実行します。TiDB TiDB Lightningの物理インポート モードと論理インポート モードの両方がサポートされています。
  • br : BRを使用してバックアップおよび復元タスクを実行します。PITR はサポートされていません。
  • ddl : 再編成 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リソース制御を無効にするには、 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別にビュー_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。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 ) に従ってリソースを比例的に割り当てます。

参照

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