Add new resource control action SWITCH_GROUP

Signed-off-by: JmPotato <[email protected]>

sql-statements/sql-statement-alter-resource-group.md

@@ -64,6 +64,7 @@ ResourceGroupRunawayActionOption ::=
     DRYRUN
 |   COOLDOWN
 |   KILL
+| "SWITCH_GROUP" '(' ResourceGroupName ')'
 
 BackgroundOptionList ::=
     DirectBackgroundOption

sql-statements/sql-statement-create-resource-group.md

@@ -68,6 +68,7 @@ ResourceGroupRunawayActionOption ::=
     DRYRUN
 |   COOLDOWN
 |   KILL
+| "SWITCH_GROUP" '(' ResourceGroupName ')'
 ```
 
 The resource group name parameter (`ResourceGroupName`) must be globally unique.

sql-statements/sql-statement-query-watch.md

@@ -28,6 +28,11 @@ QueryWatchOption ::=
 ResourceGroupName ::=
     Identifier
 |   "DEFAULT"
+ResourceGroupRunawayActionOption ::=
+    DRYRUN
+|   COOLDOWN
+|   KILL
+|   "SWITCH_GROUP" '(' ResourceGroupName ')'
 QueryWatchTextOption ::=
     "SQL" "DIGEST" SimpleExpr
 |   "PLAN" "DIGEST" SimpleExpr

tidb-resource-control.md

@@ -278,6 +278,7 @@ Supported operations (`ACTION`):
 - `DRYRUN`: no action is taken. The records are appended for the runaway queries. This is mainly used to observe whether the condition setting is reasonable.
 - `COOLDOWN`: the execution priority of the query is lowered to the lowest level. The query continues to execute with the lowest priority and does not occupy resources of other operations.
 - `KILL`: the identified query is automatically terminated and reports an error `Query execution was interrupted, identified as runaway query`.
+- `SWITCH_GROUP`: Introduced since v8.4.0, switches the identified query to the specified resource group for continued execution.
 
 To avoid too many concurrent runaway queries that exhaust system resources, the resource control feature introduces a quick identification mechanism, which can quickly identify and isolate runaway queries. You can use this feature through the `WATCH` clause. When a query is identified as a runaway query, this mechanism extracts the matching feature (defined by the parameter after `WATCH`) of the query. In the next period of time (defined by `DURATION`), the matching feature of the runaway query is added to the watch list, and the TiDB instance matches queries with the watch list. The matching queries are directly marked as runaway queries and isolated according to the corresponding action, instead of waiting for them to be identified by conditions. The `KILL` operation terminates the query and reports an error `Quarantined and interrupted because of being in runaway watch list`.
 
@@ -296,24 +297,34 @@ The parameters of `QUERY_LIMIT` are as follows:
 | Parameter          | Description            | Note                                  |
 |---------------|--------------|--------------------------------------|
 | `EXEC_ELAPSED`  | When the query execution time exceeds this value, it is identified as a runaway query | EXEC_ELAPSED =`60s` means the query is identified as a runaway query if it takes more than 60 seconds to execute. |
-| `ACTION`    | Action taken when a runaway query is identified | The optional values are `DRYRUN`, `COOLDOWN`, and `KILL`. |
+| `ACTION`    | Action taken when a runaway query is identified | The optional values are `DRYRUN`, `COOLDOWN`, `KILL`, and `SWITCH_GROUP`. |
 | `WATCH`   | Quickly match the identified runaway query. If the same or similar query is encountered again within a certain period of time, the corresponding action is performed immediately. | Optional. For example, `WATCH=SIMILAR DURATION '60s'`, `WATCH=EXACT DURATION '1m'`, and `WATCH=PLAN`. |
 
+> **Note:**
+>
+> It is recommended to use the `SWITCH_GROUP` statement together with the [`QUERY WATCH`](/tidb-resource-control.md#query-watch-parameters) statement. Since `QUERY_LIMIT` will only trigger the corresponding `ACTION` operation when the query execution time exceeds the configured `EXEC_ELAPSED`, `SWITCH_GROUP` may not be able to switch the query to the target resource group in a timely manner in such scenarios.
+
 #### Examples
 
-1. Create a resource group `rg1` with a quota of 500 RUs per second, and define a runaway query as one that exceeds 60 seconds, and lower the priority of the runaway query.
+- Create a resource group `rg1` with a quota of 500 RUs per second, and define a runaway query as one that exceeds 60 seconds, and lower the priority of the runaway query.
 
     ```sql
     CREATE RESOURCE GROUP IF NOT EXISTS rg1 RU_PER_SEC = 500 QUERY_LIMIT=(EXEC_ELAPSED='60s', ACTION=COOLDOWN);
     ```
 
-2. Change the `rg1` resource group to terminate the runaway queries, and mark the queries with the same pattern as runaway queries immediately in the next 10 minutes.
+- Change the `rg1` resource group to switch the runaway queries' resource group, mark the queries with the same pattern as runaway queries immediately in the next 10 minutes.
+
+    ```sql
+    QUERY WATCH ADD RESOURCE GROUP rg1 ACTION SWITCH_GROUP(rg2) SQL TEXT SIMILAR TO 'select * from test.t2';
+    ```
+
+- Change the `rg1` resource group to terminate the runaway queries, and mark the queries with the same pattern as runaway queries immediately in the next 10 minutes`.
 
     ```sql
     ALTER RESOURCE GROUP rg1 QUERY_LIMIT=(EXEC_ELAPSED='60s', ACTION=KILL, WATCH=SIMILAR DURATION='10m');
     ```
 
-3. Change the `rg1` resource group to cancel the runaway query check.
+- Change the `rg1` resource group to cancel the runaway query check.
 
     ```sql
     ALTER RESOURCE GROUP rg1 QUERY_LIMIT=NULL;