diff --git a/dev/reference/configuration/tidb-server/tidb-specific-variables.md b/dev/reference/configuration/tidb-server/tidb-specific-variables.md index 760e85e98b1f6..a2dc449cfafc5 100644 --- a/dev/reference/configuration/tidb-server/tidb-specific-variables.md +++ b/dev/reference/configuration/tidb-server/tidb-specific-variables.md @@ -515,3 +515,9 @@ set tidb_query_log_max_len = 20 - Scope: GLOBAL - Default value: 0 - By default, Regions are split for a new table when it is being created in TiDB. After this variable is enabled, the newly split Regions are scattered immediately during the execution of the `CREATE TABLE` statement. This applies to the scenario where data need to be written in batches right after the tables are created in batches, because the newly split Regions can be scattered in TiKV beforehand and do not have to wait to be scheduled by PD. To ensure the continuous stability of writing data in batches, the `CREATE TABLE` statement returns success only after the Regions are successfully scattered. This makes the statement's execution time multiple times longer than that when you disable this variable. + +### tidb_allow_remove_auto_inc New in v2.1.8 and v3.0.4 + +- Scope: SESSION +- Default value: 0 +- This variable is used to set whether the `auto_increment` property of a column is allowed to be removed by executing `ALTER TABLE MODIFY` or `ALTER TABLE CHANGE` statements. It is not allowed by default. \ No newline at end of file diff --git a/dev/reference/mysql-compatibility.md b/dev/reference/mysql-compatibility.md index 229c71c96bcca..659dfb59ee800 100644 --- a/dev/reference/mysql-compatibility.md +++ b/dev/reference/mysql-compatibility.md @@ -67,6 +67,8 @@ The operations are executed as follows: 1. The client issues the `insert into t values (1, 1)` statement to Instance B which sets the `id` to 1 and the statement is executed successfully. 2. The client issues the `insert into t (c) (1)` statement to Instance A. This statement does not specify the value of `id`, so Instance A allocates the value. Currently, Instances A caches the auto-increment ID of [1, 30000], so it allocates the `id` value to 1 and adds 1 to the local counter. However, at this time the data with the `id` of 1 already exists in the cluster, therefore it reports `Duplicated Error`. +Also, starting from TiDB 2.1.18 and 3.0.4, TiDB supports using the system variable `tidb_allow_remove_auto_inc` to control whether the `auto_increment` property of a column is allowed to be removed by executing `ALTER TABLE MODIFY` or `ALTER TABLE CHANGE` statements. It is not allowed by default. + ### Performance schema Performance schema tables return empty results in TiDB. TiDB uses a combination of [Prometheus and Grafana](/dev/how-to/monitor/monitor-a-cluster.md) for performance metrics instead. diff --git a/v2.1/reference/configuration/tidb-server/tidb-specific-variables.md b/v2.1/reference/configuration/tidb-server/tidb-specific-variables.md index b8024ef32bea1..c11903388014e 100644 --- a/v2.1/reference/configuration/tidb-server/tidb-specific-variables.md +++ b/v2.1/reference/configuration/tidb-server/tidb-specific-variables.md @@ -356,4 +356,10 @@ set tidb_query_log_max_len = 20 - Scope: GLOBAL - Default value: 0 -- By default, Regions are split for a new table when it is being created in TiDB. After this variable is enabled, the newly split Regions are scattered immediately during the execution of the `CREATE TABLE` statement. This applies to the scenario where data need to be written in batches right after the tables are created in batches, because the newly split Regions can be scattered in TiKV beforehand and do not have to wait to be scheduled by PD. To ensure the continuous stability of writing data in batches, the `CREATE TABLE` statement returns success only after the Regions are successfully scattered. This makes the statement's execution time multiple times longer than that when you disable this variable. \ No newline at end of file +- By default, Regions are split for a new table when it is being created in TiDB. After this variable is enabled, the newly split Regions are scattered immediately during the execution of the `CREATE TABLE` statement. This applies to the scenario where data need to be written in batches right after the tables are created in batches, because the newly split Regions can be scattered in TiKV beforehand and do not have to wait to be scheduled by PD. To ensure the continuous stability of writing data in batches, the `CREATE TABLE` statement returns success only after the Regions are successfully scattered. This makes the statement's execution time multiple times longer than that when you disable this variable. + +### tidb_allow_remove_auto_inc New in v2.1.8 + +- Scope: SESSION +- Default value: 0 +- This variable is used to set whether the `auto_increment` property of a column is allowed to be removed by executing `ALTER TABLE MODIFY` or `ALTER TABLE CHANGE` statements. It is not allowed by default. \ No newline at end of file diff --git a/v2.1/reference/mysql-compatibility.md b/v2.1/reference/mysql-compatibility.md index e38475b06a170..7b33b455b8745 100644 --- a/v2.1/reference/mysql-compatibility.md +++ b/v2.1/reference/mysql-compatibility.md @@ -67,6 +67,8 @@ The operations are executed as follows: 1. The client issues the `insert into t values (1, 1)` statement to Instance B which sets the `id` to 1 and the statement is executed successfully. 2. The client issues the `insert into t (c) (1)` statement to Instance A. This statement does not specify the value of `id`, so Instance A allocates the value. Currently, Instances A caches the auto-increment ID of [1, 30000], so it allocates the `id` value to 1 and adds 1 to the local counter. However, at this time the data with the `id` of 1 already exists in the cluster, therefore it reports `Duplicated Error`. +Also, starting from TiDB 2.1.18, TiDB supports using the system variable `tidb_allow_remove_auto_inc` to control whether the `auto_increment` property of a column is allowed to be removed by executing `ALTER TABLE MODIFY` or `ALTER TABLE CHANGE` statements. It is not allowed by default. + ### Performance schema Performance schema tables return empty results in TiDB. TiDB uses a combination of [Prometheus and Grafana](/v2.1/how-to/monitor/monitor-a-cluster.md) for performance metrics instead. diff --git a/v3.0/reference/configuration/tidb-server/tidb-specific-variables.md b/v3.0/reference/configuration/tidb-server/tidb-specific-variables.md index 6c578454443fd..713ab1f8b2f3b 100644 --- a/v3.0/reference/configuration/tidb-server/tidb-specific-variables.md +++ b/v3.0/reference/configuration/tidb-server/tidb-specific-variables.md @@ -515,3 +515,9 @@ set tidb_query_log_max_len = 20 - Scope: GLOBAL - Default value: 0 - By default, Regions are split for a new table when it is being created in TiDB. After this variable is enabled, the newly split Regions are scattered immediately during the execution of the `CREATE TABLE` statement. This applies to the scenario where data need to be written in batches right after the tables are created in batches, because the newly split Regions can be scattered in TiKV beforehand and do not have to wait to be scheduled by PD. To ensure the continuous stability of writing data in batches, the `CREATE TABLE` statement returns success only after the Regions are successfully scattered. This makes the statement's execution time multiple times longer than that when you disable this variable. + +### tidb_allow_remove_auto_inc New in v3.0.4 + +- Scope: SESSION +- Default value: 0 +- This variable is used to set whether the `auto_increment` property of a column is allowed to be removed by executing `ALTER TABLE MODIFY` or `ALTER TABLE CHANGE` statements. It is not allowed by default. diff --git a/v3.0/reference/mysql-compatibility.md b/v3.0/reference/mysql-compatibility.md index 667316d84cc1c..00d877b7dba5b 100644 --- a/v3.0/reference/mysql-compatibility.md +++ b/v3.0/reference/mysql-compatibility.md @@ -67,6 +67,8 @@ The operations are executed as follows: 1. The client issues the `insert into t values (1, 1)` statement to Instance B which sets the `id` to 1 and the statement is executed successfully. 2. The client issues the `insert into t (c) (1)` statement to Instance A. This statement does not specify the value of `id`, so Instance A allocates the value. Currently, Instances A caches the auto-increment ID of [1, 30000], so it allocates the `id` value to 1 and adds 1 to the local counter. However, at this time the data with the `id` of 1 already exists in the cluster, therefore it reports `Duplicated Error`. +Also, starting with TiDB 3.0.4, TiDB supports using the system variable `tidb_allow_remove_auto_inc` to control whether the `auto_increment` property of a column is allowed to be removed by executing `ALTER TABLE MODIFY` or `ALTER TABLE CHANGE` statements. It is not allowed by default. + ### Performance schema Performance schema tables return empty results in TiDB. TiDB uses a combination of [Prometheus and Grafana](/v3.0/how-to/monitor/monitor-a-cluster.md) for performance metrics instead.