From 30fefbdf5116c4dc2a9825c3473a47c34d046e8d Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Fri, 8 Mar 2024 12:49:10 +0800 Subject: [PATCH 1/7] Add temp.md --- temp.md | 1 + 1 file changed, 1 insertion(+) create mode 100644 temp.md diff --git a/temp.md b/temp.md new file mode 100644 index 0000000000000..af27ff4986a7b --- /dev/null +++ b/temp.md @@ -0,0 +1 @@ +This is a test file. \ No newline at end of file From a4d46428163a19d05c4efd4137945b0dc18f032d Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Fri, 8 Mar 2024 12:49:14 +0800 Subject: [PATCH 2/7] Delete temp.md --- temp.md | 1 - 1 file changed, 1 deletion(-) delete mode 100644 temp.md diff --git a/temp.md b/temp.md deleted file mode 100644 index af27ff4986a7b..0000000000000 --- a/temp.md +++ /dev/null @@ -1 +0,0 @@ -This is a test file. \ No newline at end of file From bebd4b918a679938ea595be7b9db92a949d25e87 Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Fri, 8 Mar 2024 14:00:38 +0800 Subject: [PATCH 3/7] Update upgrade-tidb-using-tiup.md --- upgrade-tidb-using-tiup.md | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/upgrade-tidb-using-tiup.md b/upgrade-tidb-using-tiup.md index 98b388db93ca4..5b8f1dc89acb1 100644 --- a/upgrade-tidb-using-tiup.md +++ b/upgrade-tidb-using-tiup.md @@ -25,6 +25,31 @@ This document is targeted for the following upgrade paths: > - If your cluster to be upgraded is v3.1 or an earlier version (v3.0 or v2.1), the direct upgrade to v7.1.0 or a later v7.1.x version is not supported. You need to upgrade your cluster first to v4.0 and then to the target TiDB version. > - If your cluster to be upgraded is earlier than v6.2, the upgrade might get stuck when you upgrade the cluster to v6.2 or later versions in some scenarios. You can refer to [How to fix the issue](#how-to-fix-the-issue-that-the-upgrade-gets-stuck-when-upgrading-to-v620-or-later-versions). > - TiDB nodes use the value of the [`server-version`](/tidb-configuration-file.md#server-version) configuration item to verify the current TiDB version. Therefore, to avoid unexpected behaviors, before upgrading the TiDB cluster, you need to set the value of `server-version` to empty or the real version of the current TiDB cluster. +> - Setting the [`performance.force-init-stats`](/tidb-configuration-file.md#force-init-stats-introduced-in-v657-and-v710) configuration item to `ON` prolongs the TiDB startup time, which might cause startup timeouts and upgrade failures. To avoid this issue, it is recommended to set a longer waiting timeout for TiUP. +> - Scenarios that might be affected: +> - The original cluster version is earlier than v6.5.7 and v7.1.0 (which does not support `performance.force-init-stats` yet), and the target version is v7.2.0 or later. +> - The original cluster version is equal to or later than v6.5.7 and v7.1.0, and the `performance.force-init-stats` configuration item is set to `ON`. +> +> - Check the value of the `performance.force-init-stats` configuration item: +> +> ``` +> SHOW CONFIG WHERE type = 'tidb' AND name = 'performance.force-init-stats'; +> ``` +> +> - You can increase the TiUP waiting timeout by adding the command-line option [`--wait-timeout`](/tiup/tiup-component-cluster.md##--wait-timeout). For example, executing the following command sets the waiting timeout to 1200 seconds (20 minutes). +> +> ```shell +> tiup update cluster --wait-timeout 1200 [other options] +> ``` +> +> Generally, a 20-minute waiting timeout is sufficient for most scenarios. For a more precise estimate, search for `init stats info time` in the TiDB log to get the statistics loading time during the previous startup as a reference. For example: +> +> ``` +> [domain.go:2271] ["init stats info time"] [lite=true] ["take time"=2.151333ms] +> ``` +> +> If the original cluster is v7.1.0 or earlier, when upgrading to v7.2.0 or later, because of the introduction of [`performance.lite-init-stats`](/tidb-configuration-file.md#lite-init-stats-introduced-in-v710), the statistics loading time is greatly reduced. In this case, the `init stats info time` before the upgrade is longer than the loading time after the upgrade. +> - If you want to shorten the rolling upgrade duration of TiDB and the potential performance impact of missing initial statistical information during the upgrade is acceptable for your cluster, you can set `performance.force-init-stats` to `OFF` before the upgrade by [modifying the configuration of the target instance with TiUP](/maintain-tidb-using-tiup.md#modify-the-configuration). After the upgrade is completed, you can reassess and revert this setting if necessary. ## Upgrade caveat From b038b67163ba2f717f42879cbab95b7254bf5936 Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Fri, 8 Mar 2024 14:03:40 +0800 Subject: [PATCH 4/7] Update upgrade-tidb-using-tiup.md --- upgrade-tidb-using-tiup.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/upgrade-tidb-using-tiup.md b/upgrade-tidb-using-tiup.md index 5b8f1dc89acb1..eda2c01b60b31 100644 --- a/upgrade-tidb-using-tiup.md +++ b/upgrade-tidb-using-tiup.md @@ -25,7 +25,7 @@ This document is targeted for the following upgrade paths: > - If your cluster to be upgraded is v3.1 or an earlier version (v3.0 or v2.1), the direct upgrade to v7.1.0 or a later v7.1.x version is not supported. You need to upgrade your cluster first to v4.0 and then to the target TiDB version. > - If your cluster to be upgraded is earlier than v6.2, the upgrade might get stuck when you upgrade the cluster to v6.2 or later versions in some scenarios. You can refer to [How to fix the issue](#how-to-fix-the-issue-that-the-upgrade-gets-stuck-when-upgrading-to-v620-or-later-versions). > - TiDB nodes use the value of the [`server-version`](/tidb-configuration-file.md#server-version) configuration item to verify the current TiDB version. Therefore, to avoid unexpected behaviors, before upgrading the TiDB cluster, you need to set the value of `server-version` to empty or the real version of the current TiDB cluster. -> - Setting the [`performance.force-init-stats`](/tidb-configuration-file.md#force-init-stats-introduced-in-v657-and-v710) configuration item to `ON` prolongs the TiDB startup time, which might cause startup timeouts and upgrade failures. To avoid this issue, it is recommended to set a longer waiting timeout for TiUP. +> - Setting the [`performance.force-init-stats`](/tidb-configuration-file.md#force-init-stats-new-in-v657-and-v710) configuration item to `ON` prolongs the TiDB startup time, which might cause startup timeouts and upgrade failures. To avoid this issue, it is recommended to set a longer waiting timeout for TiUP. > - Scenarios that might be affected: > - The original cluster version is earlier than v6.5.7 and v7.1.0 (which does not support `performance.force-init-stats` yet), and the target version is v7.2.0 or later. > - The original cluster version is equal to or later than v6.5.7 and v7.1.0, and the `performance.force-init-stats` configuration item is set to `ON`. From 847d33d1a87b6341e2461430c6b82924795a163d Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Fri, 8 Mar 2024 14:30:00 +0800 Subject: [PATCH 5/7] fix broken links --- upgrade-tidb-using-tiup.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/upgrade-tidb-using-tiup.md b/upgrade-tidb-using-tiup.md index eda2c01b60b31..188f2b11d0a1a 100644 --- a/upgrade-tidb-using-tiup.md +++ b/upgrade-tidb-using-tiup.md @@ -36,7 +36,7 @@ This document is targeted for the following upgrade paths: > SHOW CONFIG WHERE type = 'tidb' AND name = 'performance.force-init-stats'; > ``` > -> - You can increase the TiUP waiting timeout by adding the command-line option [`--wait-timeout`](/tiup/tiup-component-cluster.md##--wait-timeout). For example, executing the following command sets the waiting timeout to 1200 seconds (20 minutes). +> - You can increase the TiUP waiting timeout by adding the command-line option [`--wait-timeout`](/tiup/tiup-component-cluster.md#--wait-timeout). For example, executing the following command sets the waiting timeout to 1200 seconds (20 minutes). > > ```shell > tiup update cluster --wait-timeout 1200 [other options] @@ -48,7 +48,7 @@ This document is targeted for the following upgrade paths: > [domain.go:2271] ["init stats info time"] [lite=true] ["take time"=2.151333ms] > ``` > -> If the original cluster is v7.1.0 or earlier, when upgrading to v7.2.0 or later, because of the introduction of [`performance.lite-init-stats`](/tidb-configuration-file.md#lite-init-stats-introduced-in-v710), the statistics loading time is greatly reduced. In this case, the `init stats info time` before the upgrade is longer than the loading time after the upgrade. +> If the original cluster is v7.1.0 or earlier, when upgrading to v7.2.0 or later, because of the introduction of [`performance.lite-init-stats`](/tidb-configuration-file.md#lite-init-stats-new-in-v710), the statistics loading time is greatly reduced. In this case, the `init stats info time` before the upgrade is longer than the loading time after the upgrade. > - If you want to shorten the rolling upgrade duration of TiDB and the potential performance impact of missing initial statistical information during the upgrade is acceptable for your cluster, you can set `performance.force-init-stats` to `OFF` before the upgrade by [modifying the configuration of the target instance with TiUP](/maintain-tidb-using-tiup.md#modify-the-configuration). After the upgrade is completed, you can reassess and revert this setting if necessary. ## Upgrade caveat From 3018071abe65e638a7aee7e0573e84e70b95122b Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Sat, 9 Mar 2024 10:30:30 +0800 Subject: [PATCH 6/7] Update upgrade-tidb-using-tiup.md Co-authored-by: xixirangrang --- upgrade-tidb-using-tiup.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/upgrade-tidb-using-tiup.md b/upgrade-tidb-using-tiup.md index 188f2b11d0a1a..a2c28893ccb76 100644 --- a/upgrade-tidb-using-tiup.md +++ b/upgrade-tidb-using-tiup.md @@ -36,7 +36,7 @@ This document is targeted for the following upgrade paths: > SHOW CONFIG WHERE type = 'tidb' AND name = 'performance.force-init-stats'; > ``` > -> - You can increase the TiUP waiting timeout by adding the command-line option [`--wait-timeout`](/tiup/tiup-component-cluster.md#--wait-timeout). For example, executing the following command sets the waiting timeout to 1200 seconds (20 minutes). +> - You can increase the TiUP waiting timeout by adding the command-line option [`--wait-timeout`](/tiup/tiup-component-cluster.md#--wait-timeout). For example, execute the following command to set the waiting timeout to 1200 seconds (20 minutes). > > ```shell > tiup update cluster --wait-timeout 1200 [other options] From 7e9aaba862cf248a49164d95b153a2ef5b84cef6 Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Mon, 11 Mar 2024 11:15:26 +0800 Subject: [PATCH 7/7] Update upgrade-tidb-using-tiup.md --- upgrade-tidb-using-tiup.md | 1 - 1 file changed, 1 deletion(-) diff --git a/upgrade-tidb-using-tiup.md b/upgrade-tidb-using-tiup.md index a2c28893ccb76..37c5947741b1e 100644 --- a/upgrade-tidb-using-tiup.md +++ b/upgrade-tidb-using-tiup.md @@ -48,7 +48,6 @@ This document is targeted for the following upgrade paths: > [domain.go:2271] ["init stats info time"] [lite=true] ["take time"=2.151333ms] > ``` > -> If the original cluster is v7.1.0 or earlier, when upgrading to v7.2.0 or later, because of the introduction of [`performance.lite-init-stats`](/tidb-configuration-file.md#lite-init-stats-new-in-v710), the statistics loading time is greatly reduced. In this case, the `init stats info time` before the upgrade is longer than the loading time after the upgrade. > - If you want to shorten the rolling upgrade duration of TiDB and the potential performance impact of missing initial statistical information during the upgrade is acceptable for your cluster, you can set `performance.force-init-stats` to `OFF` before the upgrade by [modifying the configuration of the target instance with TiUP](/maintain-tidb-using-tiup.md#modify-the-configuration). After the upgrade is completed, you can reassess and revert this setting if necessary. ## Upgrade caveat