From e28907ffd275396c604b22554c88bb03d9dd74eb Mon Sep 17 00:00:00 2001 From: Aolin Date: Wed, 19 Oct 2022 16:47:52 +0800 Subject: [PATCH 1/3] pd: add rank-formula-version config for hot scheduler --- experimental-features.md | 3 ++- pd-control.md | 19 +++++++++++++++++-- 2 files changed, 19 insertions(+), 3 deletions(-) diff --git a/experimental-features.md b/experimental-features.md index a2cab24e4b2fe..9ffa948c03732 100644 --- a/experimental-features.md +++ b/experimental-features.md @@ -24,7 +24,8 @@ This document introduces the experimental features of TiDB in different versions ## Scheduling -Elastic scheduling feature. It enables the TiDB cluster to dynamically scale out and in on Kubernetes based on real-time workloads, which effectively reduces the stress during your application's peak hours and saves overheads. See [Enable TidbCluster Auto-scaling](https://docs.pingcap.com/tidb-in-kubernetes/stable/enable-tidb-cluster-auto-scaling) for details. (Introduced in v4.0) ++ Elastic scheduling feature. It enables the TiDB cluster to dynamically scale out and in on Kubernetes based on real-time workloads, which effectively reduces the stress during your application's peak hours and saves overheads. See [Enable TidbCluster Auto-scaling](https://docs.pingcap.com/tidb-in-kubernetes/stable/enable-tidb-cluster-auto-scaling) for details. (Introduced in v4.0) ++ Modify the hotspot balance scheduler algorithm in PD to use the v1 or v2 algorithm. See [`scheduler config balance-hot-region-scheduler`](/pd-control.md#scheduler-config-balance-hot-region-scheduler) for details. (Introduced in v6.3) ## SQL diff --git a/pd-control.md b/pd-control.md index 9cc88f31443f9..1e90b4b58f021 100644 --- a/pd-control.md +++ b/pd-control.md @@ -834,7 +834,8 @@ Usage: "key" ], "strict-picking-store": "true", - "enable-for-tiflash": "true" + "enable-for-tiflash": "true", + "rank-formula-version": "v1" } ``` @@ -893,12 +894,26 @@ Usage: scheduler config balance-hot-region-scheduler set read-priorities query,byte ``` -- `strict-picking-store` controls the search space of hot Region scheduling. Usually, it is enabled. When it is enabled, hot Region scheduling ensures hotspot balance on the two configured dimensions. When it is disabled, hot Region scheduling only ensures the balance on the dimension with the first priority, which might reduce balance on other dimensions. Usually, you do not need to modify this configuration. +- `strict-picking-store` controls the search space of hot Region scheduling. Usually, it is enabled. This configuration item only affects the behavior when `rank-formula-version` is `v1`. When it is enabled, hot Region scheduling ensures hotspot balance on the two configured dimensions. When it is disabled, hot Region scheduling only ensures the balance on the dimension with the first priority, which might reduce balance on other dimensions. Usually, you do not need to modify this configuration. ```bash scheduler config balance-hot-region-scheduler set strict-picking-store true ``` +- `rank-formula-version` controls which scheduler algorithm version is used in hotspot scheduling. Value options are `v1` and `v2`. The default value is `v1`. + + - The `v1` algorithm is the scheduler strategy used in TiDB v6.3.0 and earlier versions. This algorithm mainly focuses on whether scheduling reduces the load difference between different stores and whether it introduces side effects in another dimension. + - The `v2` algorithm is the scheduler strategy introduced in TiDB v6.3.0. This algorithm mainly focuses on the improvement rate of the equitability between different stores and reduces the attention to side effects. Compared with the `v1` algorithm with `strict-picking-store` being `true`, the `v2` algorithm pays more attention to the priority equalization of the first dimension. Compared with the `v1` algorithm with `strict-picking-store` being `false`, the `v2` algorithm considers the balance of the second dimension. + - The `v1` algorithm with `strict-picking-store` being `true` is conservative and scheduling can only be generated when there is a store with a high load in both dimensions. In certain scenarios, it might be impossible to continue balancing due to dimensional conflicts. To achieve better balancing in the first dimension, it is necessary to modify the `strict-picking-store` to `false`. The `v2` algorithm can achieve better balancing in both dimensions and reduce invalid scheduling. + + > **Warning:** + > + > Setting `rank-formula-version` to `v2` is an experimental feature. It is not recommended that you use it for production environments. + + ```bash + scheduler config balance-hot-region-scheduler set rank-formula-version v2 + ``` + - `enable-for-tiflash` controls whether hot Region scheduling takes effect for TiFlash instances. Usually, it is enabled. When it is disabled, the hot Region scheduling between TiFlash instances is not performed. ```bash From 092fa940b9c70004cafa6f633b2ba97ddb43d68d Mon Sep 17 00:00:00 2001 From: Aolin Date: Fri, 21 Oct 2022 14:42:04 +0800 Subject: [PATCH 2/3] apply suggestions from code review --- experimental-features.md | 2 +- pd-control.md | 10 +++++----- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/experimental-features.md b/experimental-features.md index 9ffa948c03732..f2cfe8f8f1528 100644 --- a/experimental-features.md +++ b/experimental-features.md @@ -25,7 +25,7 @@ This document introduces the experimental features of TiDB in different versions ## Scheduling + Elastic scheduling feature. It enables the TiDB cluster to dynamically scale out and in on Kubernetes based on real-time workloads, which effectively reduces the stress during your application's peak hours and saves overheads. See [Enable TidbCluster Auto-scaling](https://docs.pingcap.com/tidb-in-kubernetes/stable/enable-tidb-cluster-auto-scaling) for details. (Introduced in v4.0) -+ Modify the hotspot balance scheduler algorithm in PD to use the v1 or v2 algorithm. See [`scheduler config balance-hot-region-scheduler`](/pd-control.md#scheduler-config-balance-hot-region-scheduler) for details. (Introduced in v6.3) ++ Balance hot Region scheduling by using the v2 algorithm in PD. See [`scheduler config balance-hot-region-scheduler`](/pd-control.md#scheduler-config-balance-hot-region-scheduler) for details. (Introduced in v6.3) ## SQL diff --git a/pd-control.md b/pd-control.md index 1e90b4b58f021..c9fbe54ed72da 100644 --- a/pd-control.md +++ b/pd-control.md @@ -894,17 +894,17 @@ Usage: scheduler config balance-hot-region-scheduler set read-priorities query,byte ``` -- `strict-picking-store` controls the search space of hot Region scheduling. Usually, it is enabled. This configuration item only affects the behavior when `rank-formula-version` is `v1`. When it is enabled, hot Region scheduling ensures hotspot balance on the two configured dimensions. When it is disabled, hot Region scheduling only ensures the balance on the dimension with the first priority, which might reduce balance on other dimensions. Usually, you do not need to modify this configuration. +- `strict-picking-store` controls the search space of hot Region scheduling. Usually, it is enabled. This configuration item only affects the behavior when `rank-formula-version` is `v1`. When it is enabled, hot Region scheduling ensures hot Region balance on the two configured dimensions. When it is disabled, hot Region scheduling only ensures the balance on the dimension with the first priority, which might reduce balance on other dimensions. Usually, you do not need to modify this configuration. ```bash scheduler config balance-hot-region-scheduler set strict-picking-store true ``` -- `rank-formula-version` controls which scheduler algorithm version is used in hotspot scheduling. Value options are `v1` and `v2`. The default value is `v1`. +- `rank-formula-version` controls which scheduler algorithm version is used in hot Region scheduling. Value options are `v1` and `v2`. The default value is `v1`. - - The `v1` algorithm is the scheduler strategy used in TiDB v6.3.0 and earlier versions. This algorithm mainly focuses on whether scheduling reduces the load difference between different stores and whether it introduces side effects in another dimension. - - The `v2` algorithm is the scheduler strategy introduced in TiDB v6.3.0. This algorithm mainly focuses on the improvement rate of the equitability between different stores and reduces the attention to side effects. Compared with the `v1` algorithm with `strict-picking-store` being `true`, the `v2` algorithm pays more attention to the priority equalization of the first dimension. Compared with the `v1` algorithm with `strict-picking-store` being `false`, the `v2` algorithm considers the balance of the second dimension. - - The `v1` algorithm with `strict-picking-store` being `true` is conservative and scheduling can only be generated when there is a store with a high load in both dimensions. In certain scenarios, it might be impossible to continue balancing due to dimensional conflicts. To achieve better balancing in the first dimension, it is necessary to modify the `strict-picking-store` to `false`. The `v2` algorithm can achieve better balancing in both dimensions and reduce invalid scheduling. + - The `v1` algorithm is the scheduler strategy used in TiDB v6.3.0 and earlier versions. This algorithm mainly focuses on reducing load difference between stores and avoids introducing side effects in another dimension. + - The `v2` algorithm is an experimental scheduler strategy introduced in TiDB v6.3.0. This algorithm mainly focuses on improving the rate of the equitability between stores and factors in few side effects. Compared with the `v1` algorithm with `strict-picking-store` being `true`, the `v2` algorithm pays more attention to the priority equalization of the first dimension. Compared with the `v1` algorithm with `strict-picking-store` being `false`, the `v2` algorithm considers the balance of the second dimension. + - The `v1` algorithm with `strict-picking-store` being `true` is conservative and scheduling can only be generated when there is a store with a high load in both dimensions. In certain scenarios, it might be impossible to continue balancing due to dimensional conflicts. To achieve better balancing in the first dimension, it is necessary to set the `strict-picking-store` to `false`. The `v2` algorithm can achieve better balancing in both dimensions and reduce invalid scheduling. > **Warning:** > From 46e16ca0679c269e0a0972f55dcff10dcea936fe Mon Sep 17 00:00:00 2001 From: Aolin Date: Tue, 25 Oct 2022 13:56:55 +0800 Subject: [PATCH 3/3] Apply suggestions from code review Co-authored-by: shichun-0415 <89768198+shichun-0415@users.noreply.github.com> --- pd-control.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pd-control.md b/pd-control.md index c9fbe54ed72da..b32c2f7c02e5f 100644 --- a/pd-control.md +++ b/pd-control.md @@ -902,7 +902,7 @@ Usage: - `rank-formula-version` controls which scheduler algorithm version is used in hot Region scheduling. Value options are `v1` and `v2`. The default value is `v1`. - - The `v1` algorithm is the scheduler strategy used in TiDB v6.3.0 and earlier versions. This algorithm mainly focuses on reducing load difference between stores and avoids introducing side effects in another dimension. + - The `v1` algorithm is the scheduler strategy used in TiDB v6.3.0 and earlier versions. This algorithm mainly focuses on reducing load difference between stores and avoids introducing side effects in the other dimension. - The `v2` algorithm is an experimental scheduler strategy introduced in TiDB v6.3.0. This algorithm mainly focuses on improving the rate of the equitability between stores and factors in few side effects. Compared with the `v1` algorithm with `strict-picking-store` being `true`, the `v2` algorithm pays more attention to the priority equalization of the first dimension. Compared with the `v1` algorithm with `strict-picking-store` being `false`, the `v2` algorithm considers the balance of the second dimension. - The `v1` algorithm with `strict-picking-store` being `true` is conservative and scheduling can only be generated when there is a store with a high load in both dimensions. In certain scenarios, it might be impossible to continue balancing due to dimensional conflicts. To achieve better balancing in the first dimension, it is necessary to set the `strict-picking-store` to `false`. The `v2` algorithm can achieve better balancing in both dimensions and reduce invalid scheduling.