Merge remote-tracking branch 'upstream/master'

qiancai · Aug 22, 2024 · d622d75 · d622d75
2 parents 8af7582 + d4be1bd
commit d622d75
Show file tree

Hide file tree

Showing 52 changed files with 776 additions and 307 deletions.
diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md
@@ -24,6 +24,7 @@ By default, **CHOOSE MASTER ONLY** so your changes will be applied to the next T
 For details, see [tips for choosing the affected versions](https://github.com/pingcap/docs/blob/master/CONTRIBUTING.md#guideline-for-choosing-the-affected-versions).
 
 - [ ] master (the latest development version)
+- [ ] v8.4 (TiDB 8.4 versions)
 - [ ] v8.3 (TiDB 8.3 versions)
 - [ ] v8.2 (TiDB 8.2 versions)
 - [ ] v8.1 (TiDB 8.1 versions)

diff --git a/TOC.md b/TOC.md
@@ -4,7 +4,7 @@
 - [Docs Home](https://docs.pingcap.com/)
 - About TiDB
   - [TiDB Introduction](/overview.md)
-  - [TiDB 8.2 Release Notes](/releases/release-8.2.0.md)
+  - [TiDB 8.3 Release Notes](/releases/release-8.3.0.md)
   - [Features](/basic-features.md)
   - [MySQL Compatibility](/mysql-compatibility.md)
   - [TiDB Limitations](/tidb-limitations.md)

diff --git a/basic-features.md b/basic-features.md
diff --git a/br/backup-and-restore-use-cases.md b/br/backup-and-restore-use-cases.md
@@ -17,7 +17,7 @@ With PITR, you can satisfy the preceding requirements.
 
 ## Deploy the TiDB cluster and BR
 
-To use PITR, you need to deploy a TiDB cluster >= v6.2.0 and update BR to the same version as the TiDB cluster. This document uses v8.2.0 as an example.
+To use PITR, you need to deploy a TiDB cluster >= v6.2.0 and update BR to the same version as the TiDB cluster. This document uses v8.3.0 as an example.
 
 The following table shows the recommended hardware resources for using PITR in a TiDB cluster.
 
@@ -44,13 +44,13 @@ Install or upgrade BR using TiUP:
 - Install:
 
     ```shell
-    tiup install br:v8.2.0
+    tiup install br:v8.3.0
     ```
 
 - Upgrade:
 
     ```shell
-    tiup update br:v8.2.0
+    tiup update br:v8.3.0
     ```
 
 ## Configure backup storage (Amazon S3)

diff --git a/br/br-snapshot-guide.md b/br/br-snapshot-guide.md
@@ -68,6 +68,7 @@ The output is as follows, corresponding to the physical time `2022-09-08 13:30:0
 > - Starting from BR v7.6.0, to address potential restore bottlenecks in scenarios with large-scale Regions, BR supports accelerating restore through the coarse-grained Region scattering algorithm (experimental). You can enable this feature by specifying the command-line parameter `--granularity="coarse-grained"`.
 > - Starting from BR v8.0.0, the snapshot restore through the coarse-grained Region scattering algorithm is generally available (GA) and enabled by default. BR improves the snapshot restore speed significantly by implementing various optimizations such as adopting the coarse-grained Region scattering algorithm, creating databases and tables in batches, reducing the mutual impact between SST file downloads and ingest operations, and accelerating the restore of table statistics. According to test results from real-world cases, the SST file download speed for snapshot restore is improved by approximately up to 10 times, the data restore speed per TiKV node stabilizes at 1.2 GiB/s, the end-to-end restore speed is improved by approximately 1.5 to 3 times, and 100 TiB of data can be restored within one hour.
 > - Starting from BR v8.2.0, the command line parameter `--granularity` is deprecated, and the coarse-grained Region scattering algorithm is enabled by default.
+> - Starting from BR v8.3.0, the snapshot restore task introduces available disk space checks for TiKV and TiFlash: at the beginning of the task, BR verifies whether TiKV and TiFlash have sufficient disk space based on the size of SST files to be restored; for TiKV v8.3.0 or later version, TiKV verifies whether it has sufficient disk space before downloading each SST file. If the space is insufficient according to any of these checks, the restore task fails with an error. You can skip the check at the beginning of the restore task by setting `--check-requirements=false`, but the disk space check before TiKV downloads each SST file cannot be skipped.
 
 You can restore a snapshot backup by running the `tiup br restore full` command. Run `tiup br restore full --help` to see the help information:
 

diff --git a/command-line-flags-for-pd-configuration.md b/command-line-flags-for-pd-configuration.md
@@ -83,7 +83,7 @@ PD is configurable using command-line flags and environment variables.
 ## `--name`
 
 - The human-readable unique name for this PD member
-- Default: `"pd"`
+- Default: `"pd-${hostname}"`
 - If you want to start multiply PDs, you must use different name for each one.
 
 ## `--cacert`

diff --git a/command-line-flags-for-scheduling-configuration.md b/command-line-flags-for-scheduling-configuration.md
@@ -57,6 +57,12 @@ The Scheduling node is used for providing the `scheduling` microservice for PD.
 - Default: `""`
 - If this flag is not set, logs are output to "stderr". If this flag is set, logs are output to the corresponding file.
 
+## `--name` <span class="version-mark">New in v8.3.0</span>
+
++ The name of the current Scheduling node.
++ Default: `"scheduling-${hostname}"`
++ If you need to start multiple Scheduling nodes, it is recommended to configure different names for different nodes for easier identification.
+
 ## `-L`
 
 - The log level.

diff --git a/command-line-flags-for-tso-configuration.md b/command-line-flags-for-tso-configuration.md
@@ -57,6 +57,12 @@ The TSO node is used for providing the `tso` microservice for PD. You can config
 - Default: `""`
 - If this flag is not set, logs are output to "stderr". If this flag is set, logs are output to the corresponding file.
 
+## `--name` <span class="version-mark">New in v8.3.0</span>
+
++ The name of the current TSO node.
++ Default: `"tso-${hostname}"`
++ If you need to start multiple TSO nodes, it is recommended to configure different names for different nodes for easier identification.
+
 ## `-L`
 
 - The log level.

diff --git a/develop/dev-guide-sample-application-nodejs-mysql2.md b/develop/dev-guide-sample-application-nodejs-mysql2.md
@@ -189,7 +189,7 @@ npm start
 If the connection is successful, the console will output the version of the TiDB cluster as follows:
 
 ```
-🔌 Connected to TiDB cluster! (TiDB version: 8.0.11-TiDB-v8.2.0)
+🔌 Connected to TiDB cluster! (TiDB version: 8.0.11-TiDB-v8.3.0)
 ⏳ Loading sample game data...
 ✅ Loaded sample game data.
 

diff --git a/develop/dev-guide-sample-application-nodejs-mysqljs.md b/develop/dev-guide-sample-application-nodejs-mysqljs.md
@@ -189,7 +189,7 @@ npm start
 If the connection is successful, the console will output the version of the TiDB cluster as follows:
 
 ```
-🔌 Connected to TiDB cluster! (TiDB version: 8.0.11-TiDB-v8.2.0)
+🔌 Connected to TiDB cluster! (TiDB version: 8.0.11-TiDB-v8.3.0)
 ⏳ Loading sample game data...
 ✅ Loaded sample game data.
 

diff --git a/develop/dev-guide-sample-application-nodejs-prisma.md b/develop/dev-guide-sample-application-nodejs-prisma.md
@@ -268,7 +268,7 @@ void main();
 If the connection is successful, the terminal will output the version of the TiDB cluster as follows:
 
 ```
-🔌 Connected to TiDB cluster! (TiDB version: 8.0.11-TiDB-v8.2.0)
+🔌 Connected to TiDB cluster! (TiDB version: 8.0.11-TiDB-v8.3.0)
 🆕 Created a new player with ID 1.
 ℹ️ Got Player 1: Player { id: 1, coins: 100, goods: 100 }
 🔢 Added 50 coins and 50 goods to player 1, now player 1 has 150 coins and 150 goods.

diff --git a/develop/dev-guide-sample-application-nodejs-typeorm.md b/develop/dev-guide-sample-application-nodejs-typeorm.md
@@ -231,7 +231,7 @@ npm start
 If the connection is successful, the terminal will output the version of the TiDB cluster as follows:
 
 ```
-🔌 Connected to TiDB cluster! (TiDB version: 8.0.11-TiDB-v8.2.0)
+🔌 Connected to TiDB cluster! (TiDB version: 8.0.11-TiDB-v8.3.0)
 🆕 Created a new player with ID 2.
 ℹ️ Got Player 2: Player { id: 2, coins: 100, goods: 100 }
 🔢 Added 50 coins and 50 goods to player 2, now player 2 has 100 coins and 150 goods.

diff --git a/develop/dev-guide-sample-application-ruby-mysql2.md b/develop/dev-guide-sample-application-ruby-mysql2.md
@@ -190,7 +190,7 @@ ruby app.rb
 If the connection is successful, the console will output the version of the TiDB cluster as follows:
 
 ```
-🔌 Connected to TiDB cluster! (TiDB version: 8.0.11-TiDB-v8.2.0)
+🔌 Connected to TiDB cluster! (TiDB version: 8.0.11-TiDB-v8.3.0)
 ⏳ Loading sample game data...
 ✅ Loaded sample game data.
 

diff --git a/develop/dev-guide-sample-application-ruby-rails.md b/develop/dev-guide-sample-application-ruby-rails.md
@@ -183,7 +183,7 @@ Connect to your TiDB cluster depending on the TiDB deployment option you've sele
 If the connection is successful, the console will output the version of the TiDB cluster as follows:
 
 ```
-🔌 Connected to TiDB cluster! (TiDB version: 8.0.11-TiDB-v8.2.0)
+🔌 Connected to TiDB cluster! (TiDB version: 8.0.11-TiDB-v8.3.0)
 ⏳ Loading sample game data...
 ✅ Loaded sample game data.
 

diff --git a/dm/maintain-dm-using-tiup.md b/dm/maintain-dm-using-tiup.md
@@ -394,7 +394,7 @@ All operations above performed on the cluster machine use the SSH client embedde
 
 Then you can use the `--native-ssh` command-line flag to enable the system-native command-line tool:
 
-- Deploy a cluster: `tiup dm deploy <cluster-name> <version> <topo> --native-ssh`. Fill in the name of your cluster for `<cluster-name>`,  the DM version to be deployed (such as `v8.2.0`) for `<version>` , and the topology file name for `<topo>`.
+- Deploy a cluster: `tiup dm deploy <cluster-name> <version> <topo> --native-ssh`. Fill in the name of your cluster for `<cluster-name>`,  the DM version to be deployed (such as `v8.3.0`) for `<version>` , and the topology file name for `<topo>`.
 - Start a cluster: `tiup dm start <cluster-name> --native-ssh`.
 - Upgrade a cluster: `tiup dm upgrade ... --native-ssh`
 

diff --git a/dm/quick-start-create-task.md b/dm/quick-start-create-task.md
@@ -74,7 +74,7 @@ To run a TiDB server, use the following command:
 {{< copyable "shell-regular" >}}
 
 ```bash
-wget https://download.pingcap.org/tidb-community-server-v8.2.0-linux-amd64.tar.gz
+wget https://download.pingcap.org/tidb-community-server-v8.3.0-linux-amd64.tar.gz
 tar -xzvf tidb-latest-linux-amd64.tar.gz
 mv tidb-latest-linux-amd64/bin/tidb-server ./
 ./tidb-server

diff --git a/download-ecosystem-tools.md b/download-ecosystem-tools.md
@@ -28,7 +28,7 @@ You can download TiDB Toolkit from the following link:
 https://download.pingcap.org/tidb-community-toolkit-{version}-linux-{arch}.tar.gz
 ```
 
-`{version}` in the link indicates the version number of TiDB and `{arch}` indicates the architecture of the system, which can be `amd64` or `arm64`. For example, the download link for `v8.2.0` in the `amd64` architecture is `https://download.pingcap.org/tidb-community-toolkit-v8.2.0-linux-amd64.tar.gz`.
+`{version}` in the link indicates the version number of TiDB and `{arch}` indicates the architecture of the system, which can be `amd64` or `arm64`. For example, the download link for `v8.3.0` in the `amd64` architecture is `https://download.pingcap.org/tidb-community-toolkit-v8.3.0-linux-amd64.tar.gz`.
 
 > **Note:**
 >

diff --git a/functions-and-operators/tidb-functions.md b/functions-and-operators/tidb-functions.md
@@ -544,7 +544,7 @@ SELECT TIDB_VERSION()\G
 
 ```sql
 *************************** 1. row ***************************
-TIDB_VERSION(): Release Version: v8.2.0
+TIDB_VERSION(): Release Version: v8.3.0
 Edition: Community
 Git Commit Hash: 821e491a20fbab36604b36b647b5bae26a2c1418
 Git Branch: HEAD

diff --git a/information-schema/information-schema-tidb-servers-info.md b/information-schema/information-schema-tidb-servers-info.md
@@ -50,7 +50,7 @@ The output is as follows:
          PORT: 4000
   STATUS_PORT: 10080
         LEASE: 45s
-      VERSION: 8.0.11-TiDB-v8.2.0
+      VERSION: 8.0.11-TiDB-v8.3.0
      GIT_HASH: 827d8ff2d22ac4c93ae1b841b79d468211e1d393
 BINLOG_STATUS: Off
        LABELS:

diff --git a/pd-control.md b/pd-control.md
@@ -29,7 +29,7 @@ To obtain `pd-ctl` of the latest version, download the TiDB server installation
 
 > **Note:**
 >
-> `{version}` in the link indicates the version number of TiDB. For example, the download link for `v8.2.0` in the `amd64` architecture is `https://download.pingcap.org/tidb-community-server-v8.2.0-linux-amd64.tar.gz`.
+> `{version}` in the link indicates the version number of TiDB. For example, the download link for `v8.3.0` in the `amd64` architecture is `https://download.pingcap.org/tidb-community-server-v8.3.0-linux-amd64.tar.gz`.
 
 ### Compile from source code
 
@@ -979,6 +979,12 @@ Use this command to view and manage the configuration of the `evict-leader-sched
 
     If all store configurations of an `evict-leader-scheduler` are removed, the scheduler itself is automatically removed.
 
+- When an `evict-leader-scheduler` already exists, use the `set batch` subcommand to modify the `batch` value. `batch` controls the number of Operators generated during a single scheduling process. The default value is `3`, and the range is `[1, 10]`. The larger the `batch` value, the faster the scheduling speed.
+
+    ```bash
+    scheduler config evict-leader-scheduler set batch 10 // Set the batch value to 10
+    ```
+
 ### `service-gc-safepoint`
 
 Use this command to query the current GC safepoint and service GC safepoint. The output is as follows:

diff --git a/performance-schema/performance-schema-session-connect-attrs.md b/performance-schema/performance-schema-session-connect-attrs.md
@@ -52,7 +52,7 @@ TABLE SESSION_CONNECT_ATTRS;
 | PROCESSLIST_ID | ATTR_NAME       | ATTR_VALUE | ORDINAL_POSITION |
 +----------------+-----------------+------------+------------------+
 |        2097154 | _client_name    | libmysql   |                0 |
-|        2097154 | _client_version | 8.2.0      |                1 |
+|        2097154 | _client_version | 8.3.0      |                1 |
 |        2097154 | _os             | Linux      |                2 |
 |        2097154 | _pid            | 1299203    |                3 |
 |        2097154 | _platform       | x86_64     |                4 |

diff --git a/performance-tuning-practices.md b/performance-tuning-practices.md
@@ -427,7 +427,7 @@ By comparing the performance of each scenario, we can draw the following conclus
 - TiDB is compatible with different commands of the MySQL protocol. When using the Prepared Statement interface and setting the following JDBC connection parameters, the application can achieve its best performance:
 
     ```
-    useServerPrepStmts=true&cachePrepStmts=true&prepStmtCacheSize=1000&prepStmtCacheSqlLimit=20480&useConfigs= maxPerformance
+    useServerPrepStmts=true&cachePrepStmts=true&prepStmtCacheSize=1000&prepStmtCacheSqlLimit=20480&useConfigs=maxPerformance
     ```
 
 - It is recommended that you use TiDB Dashboard (for example, the Top SQL feature and Continuous Profiling feature) and Performance Overview dashboard for performance analysis and tuning.

diff --git a/post-installation-check.md b/post-installation-check.md
@@ -63,7 +63,7 @@ The following information indicates successful login:
 ```sql
 Welcome to the MySQL monitor.  Commands end with ; or \g.
 Your MySQL connection id is 3
-Server version: 8.0.11-TiDB-v8.2.0 TiDB Server (Apache License 2.0) Community Edition, MySQL 8.0 compatible
+Server version: 8.0.11-TiDB-v8.3.0 TiDB Server (Apache License 2.0) Community Edition, MySQL 8.0 compatible
 Copyright (c) 2000, 2023, Oracle and/or its affiliates. All rights reserved.
 Oracle is a registered trademark of Oracle Corporation and/or its
 affiliates. Other names may be trademarks of their respective

diff --git a/production-deployment-using-tiup.md b/production-deployment-using-tiup.md
@@ -95,7 +95,7 @@ https://download.pingcap.org/tidb-community-toolkit-{version}-linux-{arch}.tar.g
 
 > **Tip:**
 >
-> `{version}` in the link indicates the version number of TiDB and `{arch}` indicates the architecture of the system, which can be `amd64` or `arm64`. For example, the download link for `v8.2.0` in the `amd64` architecture is `https://download.pingcap.org/tidb-community-toolkit-v8.2.0-linux-amd64.tar.gz`.
+> `{version}` in the link indicates the version number of TiDB and `{arch}` indicates the architecture of the system, which can be `amd64` or `arm64`. For example, the download link for `v8.3.0` in the `amd64` architecture is `https://download.pingcap.org/tidb-community-toolkit-v8.3.0-linux-amd64.tar.gz`.
 
 **Method 2**: Manually pack an offline component package using `tiup mirror clone`. The detailed steps are as follows:
 
@@ -346,13 +346,13 @@ Before you run the `deploy` command, use the `check` and `check --apply` command
     {{< copyable "shell-regular" >}}
 
     ```shell
-    tiup cluster deploy tidb-test v8.2.0 ./topology.yaml --user root [-p] [-i /home/root/.ssh/gcp_rsa]
+    tiup cluster deploy tidb-test v8.3.0 ./topology.yaml --user root [-p] [-i /home/root/.ssh/gcp_rsa]
     ```
 
 In the `tiup cluster deploy` command above:
 
 - `tidb-test` is the name of the TiDB cluster to be deployed.
-- `v8.2.0` is the version of the TiDB cluster to be deployed. You can see the latest supported versions by running `tiup list tidb`.
+- `v8.3.0` is the version of the TiDB cluster to be deployed. You can see the latest supported versions by running `tiup list tidb`.
 - `topology.yaml` is the initialization configuration file.
 - `--user root` indicates logging into the target machine as the `root` user to complete the cluster deployment. The `root` user is expected to have `ssh` and `sudo` privileges to the target machine. Alternatively, you can use other users with `ssh` and `sudo` privileges to complete the deployment.
 - `[-i]` and `[-p]` are optional. If you have configured login to the target machine without password, these parameters are not required. If not, choose one of the two parameters. `[-i]` is the private key of the root user (or other users specified by `--user`) that has access to the target machine. `[-p]` is used to input the user password interactively.

diff --git a/quick-start-with-tidb.md b/quick-start-with-tidb.md
@@ -81,10 +81,10 @@ As a distributed system, a basic TiDB test cluster usually consists of 2 TiDB in
         {{< copyable "shell-regular" >}}
 
         ```shell
-        tiup playground v8.2.0 --db 2 --pd 3 --kv 3
+        tiup playground v8.3.0 --db 2 --pd 3 --kv 3
         ```
 
-        The command downloads a version cluster to the local machine and starts it, such as v8.2.0. To view the latest version, run `tiup list tidb`.
+        The command downloads a version cluster to the local machine and starts it, such as v8.3.0. To view the latest version, run `tiup list tidb`.
 
         This command returns the access methods of the cluster:
 
@@ -202,10 +202,10 @@ As a distributed system, a basic TiDB test cluster usually consists of 2 TiDB in
         {{< copyable "shell-regular" >}}
 
         ```shell
-        tiup playground v8.2.0 --db 2 --pd 3 --kv 3
+        tiup playground v8.3.0 --db 2 --pd 3 --kv 3
         ```
 
-        The command downloads a version cluster to the local machine and starts it, such as v8.2.0. To view the latest version, run `tiup list tidb`.
+        The command downloads a version cluster to the local machine and starts it, such as v8.3.0. To view the latest version, run `tiup list tidb`.
 
         This command returns the access methods of the cluster:
 
@@ -437,7 +437,7 @@ Other requirements for the target machine include:
     ```
 
     - `<cluster-name>`: Set the cluster name
-    - `<version>`: Set the TiDB cluster version, such as `v8.2.0`. You can see all the supported TiDB versions by running the `tiup list tidb` command
+    - `<version>`: Set the TiDB cluster version, such as `v8.3.0`. You can see all the supported TiDB versions by running the `tiup list tidb` command
     - `-p`: Specify the password used to connect to the target machine.
 
         > **Note:**