reference: add tidb session variable description about tidb_allow_remove_auto_inc

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 <span class="version-mark">New in v2.1.8 and v3.0.4</span>
+
+- 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 `ALTER TABLE MODIFY` or `ALTER TABLE CHANGE`. It is not allowed by default.

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 with TiDB 2.1.18 and 3.0.4, TiDB supports removing `auto_increment` property of a column by `alter table modification` or `alter table change` through the system variable `tidb_remove_auto_inc`, which 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.

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.
+- 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 <span class="version-mark">New in v2.1.8</span>
+
+- 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 `ALTER TABLE MODIFY` or `ALTER TABLE CHANGE`. It is not allowed by default.

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 with TiDB 2.1.18, TiDB supports removing `auto_increment` property of a column by `alter table modification` or `alter table change` through the system variable `tidb_remove_auto_inc`, which 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.

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 <span class="version-mark">New in v3.0.4</span>
+
+- 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 `ALTER TABLE MODIFY` or `ALTER TABLE CHANGE`. It is not allowed by default.

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 removing `auto_increment` property of a column by `alter table modification` or `alter table change` through the system variable `tidb_remove_auto_inc`, which 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.