From 8e0be139ddd5bba05125644fddf13ba1a58c2512 Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Tue, 10 Sep 2024 11:00:19 +0800 Subject: [PATCH 01/13] 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 564d0a50efdc8067b60ef78c01565277eae1f366 Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Tue, 10 Sep 2024 11:00:23 +0800 Subject: [PATCH 02/13] 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 ca3e4223a80c09a75d570016d8507ac096e3a04c Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Tue, 10 Sep 2024 12:07:38 +0800 Subject: [PATCH 03/13] add translation --- auto-increment.md | 71 +++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 69 insertions(+), 2 deletions(-) diff --git a/auto-increment.md b/auto-increment.md index 001e1e4ecb090..af0dcbb14ebe6 100644 --- a/auto-increment.md +++ b/auto-increment.md @@ -318,9 +318,20 @@ mysql> SELECT * FROM t; | 1 | +---+ 1 row in set (0.01 sec) + +SHOW CREATE TABLE t; ++-------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| Table | Create Table | ++-------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| t | CREATE TABLE `t` ( + `a` int(11) NOT NULL AUTO_INCREMENT, + PRIMARY KEY (`a`) /*T![clustered_index] CLUSTERED */ +) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin AUTO_INCREMENT=101 /*T![auto_id_cache] AUTO_ID_CACHE=100 */ | ++-------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +1 row in set (0.00 sec) ``` -At this time, if you invalidate the auto-increment cache of this column and redo the implicit insertion, the result is as follows: +At this time, if TiDB is restarted, the auto-increment ID cache will be lost, and new insert operations will allocate IDs starting from a higher value beyond the previously cached range. ```sql mysql> DELETE FROM t; @@ -336,15 +347,71 @@ mysql> SELECT * FROM t; +-----+ | a | +-----+ +| 1 | | 101 | +-----+ -1 row in set (0.00 sec) +2 rows in set (0.01 sec) ``` The re-assigned value is `101`. This shows that the size of cache for allocating the auto-increment ID is `100`. In addition, when the length of consecutive IDs in a batch `INSERT` statement exceeds the length of `AUTO_ID_CACHE`, TiDB increases the cache size accordingly to ensure that the statement can be inserted properly. +### Clear the auto-increment ID cache + +In some scenarios, you might need to clear the auto-increment ID cache to ensure data consistency. For example: + +- In the scenario of incremental replication using [Data Migration (DM)](/dm/dm-overview.md), once the replication is complete, data writing to the downstream TiDB switches from DM to your application's writing operations. Meanwhile, the ID writing mode of the auto-increment column usually switches from explicit insertion to implicit allocation. +- When your application involves both explicit ID insertion and implicit ID allocation, you need to clear the auto-increment ID cache to avoid conflicts between future implicitly allocated IDs and previously explicitly inserted IDs, which could result in primary key conflict errors. For more information, see [Uniqueness](/auto-increment.md#uniqueness). + +You can execute the `ALTER TABLE` statement with `AUTO_INCREMENT = 0` to clear the auto-increment ID cache on all TiDB nodes in the cluster. For example: + +```sql +CREATE TABLE t(a int AUTO_INCREMENT key) AUTO_ID_CACHE 100; +Query OK, 0 rows affected (0.02 sec) + +INSERT INTO t VALUES(); +Query OK, 1 row affected (0.02 sec) + +INSERT INTO t VALUES(50); +Query OK, 1 row affected (0.00 sec) + +SELECT * FROM t; ++----+ +| a | ++----+ +| 1 | +| 50 | ++----+ +2 rows in set (0.01 sec) +``` + +```sql +ALTER TABLE t AUTO_INCREMENT = 0; +Query OK, 0 rows affected, 1 warning (0.07 sec) + +SHOW WARNINGS; ++---------+------+-------------------------------------------------------------------------+ +| Level | Code | Message | ++---------+------+-------------------------------------------------------------------------+ +| Warning | 1105 | Can't reset AUTO_INCREMENT to 0 without FORCE option, using 101 instead | ++---------+------+-------------------------------------------------------------------------+ +1 row in set (0.01 sec) + +INSERT INTO t VALUES(); +Query OK, 1 row affected (0.02 sec) + +SELECT * FROM t; ++-----+ +| a | ++-----+ +| 1 | +| 50 | +| 101 | ++-----+ +3 rows in set (0.01 sec) +``` + ### Auto-increment step size and offset Starting from v3.0.9 and v4.0.0-rc.1, similar to the behavior of MySQL, the value implicitly assigned to the auto-increment column is controlled by the `@@auto_increment_increment` and `@@auto_increment_offset` session variables. From be132567fab97ab4ec4d463189a7b654bdb72d30 Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Tue, 10 Sep 2024 13:31:59 +0800 Subject: [PATCH 04/13] Update auto-increment.md --- auto-increment.md | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/auto-increment.md b/auto-increment.md index af0dcbb14ebe6..0ccbdb158e495 100644 --- a/auto-increment.md +++ b/auto-increment.md @@ -334,16 +334,10 @@ SHOW CREATE TABLE t; At this time, if TiDB is restarted, the auto-increment ID cache will be lost, and new insert operations will allocate IDs starting from a higher value beyond the previously cached range. ```sql -mysql> DELETE FROM t; -Query OK, 1 row affected (0.01 sec) - -mysql> RENAME TABLE t to t1; -Query OK, 0 rows affected (0.01 sec) - -mysql> INSERT INTO t1 values() +INSERT INTO t VALUES(); Query OK, 1 row affected (0.00 sec) -mysql> SELECT * FROM t; +SELECT * FROM t; +-----+ | a | +-----+ From 3bc7307b13db1112507de9ef03e5b7a2d4096097 Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Tue, 10 Sep 2024 13:33:27 +0800 Subject: [PATCH 05/13] Update auto-increment.md --- auto-increment.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/auto-increment.md b/auto-increment.md index 0ccbdb158e495..fd8495d252643 100644 --- a/auto-increment.md +++ b/auto-increment.md @@ -304,14 +304,14 @@ After the value `2030000` is inserted, the next value is `2060001`. This jump in In earlier versions of TiDB, the cache size of the auto-increment ID was transparent to users. Starting from v3.0.14, v3.1.2, and v4.0.rc-2, TiDB has introduced the `AUTO_ID_CACHE` table option to allow users to set the cache size for allocating the auto-increment ID. ```sql -mysql> CREATE TABLE t(a int AUTO_INCREMENT key) AUTO_ID_CACHE 100; +CREATE TABLE t(a int AUTO_INCREMENT key) AUTO_ID_CACHE 100; Query OK, 0 rows affected (0.02 sec) -mysql> INSERT INTO t values(); +INSERT INTO t values(); Query OK, 1 row affected (0.00 sec) Records: 1 Duplicates: 0 Warnings: 0 -mysql> SELECT * FROM t; +SELECT * FROM t; +---+ | a | +---+ From c9b6f18626bbe7e2e209a8516671222dc19962a3 Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Tue, 10 Sep 2024 13:34:58 +0800 Subject: [PATCH 06/13] Update auto-increment.md --- auto-increment.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/auto-increment.md b/auto-increment.md index fd8495d252643..73a2dd9b6c156 100644 --- a/auto-increment.md +++ b/auto-increment.md @@ -331,7 +331,7 @@ SHOW CREATE TABLE t; 1 row in set (0.00 sec) ``` -At this time, if TiDB is restarted, the auto-increment ID cache will be lost, and new insert operations will allocate IDs starting from a higher value beyond the previously cached range. +At this time, if you restart TiDB, the auto-increment ID cache will be lost, and new insert operations will allocate IDs starting from a higher value beyond the previously cached range. ```sql INSERT INTO t VALUES(); From 85b7898eddc896b90da5b7b08e49fa260b7e977b Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Tue, 10 Sep 2024 13:38:52 +0800 Subject: [PATCH 07/13] Update auto-increment.md --- auto-increment.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/auto-increment.md b/auto-increment.md index 73a2dd9b6c156..ba0bfd272029f 100644 --- a/auto-increment.md +++ b/auto-increment.md @@ -358,7 +358,7 @@ In some scenarios, you might need to clear the auto-increment ID cache to ensure - In the scenario of incremental replication using [Data Migration (DM)](/dm/dm-overview.md), once the replication is complete, data writing to the downstream TiDB switches from DM to your application's writing operations. Meanwhile, the ID writing mode of the auto-increment column usually switches from explicit insertion to implicit allocation. - When your application involves both explicit ID insertion and implicit ID allocation, you need to clear the auto-increment ID cache to avoid conflicts between future implicitly allocated IDs and previously explicitly inserted IDs, which could result in primary key conflict errors. For more information, see [Uniqueness](/auto-increment.md#uniqueness). -You can execute the `ALTER TABLE` statement with `AUTO_INCREMENT = 0` to clear the auto-increment ID cache on all TiDB nodes in the cluster. For example: +To clear the auto-increment ID cache on all TiDB nodes in the cluster, you can execute the `ALTER TABLE` statement with `AUTO_INCREMENT = 0`. For example: ```sql CREATE TABLE t(a int AUTO_INCREMENT key) AUTO_ID_CACHE 100; From 8771ffc63e06078bbd07f17f0ad9f77337a072b5 Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Wed, 11 Sep 2024 13:54:45 +0800 Subject: [PATCH 08/13] Update auto-increment.md --- auto-increment.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/auto-increment.md b/auto-increment.md index ba0bfd272029f..53eda9271e195 100644 --- a/auto-increment.md +++ b/auto-increment.md @@ -347,7 +347,7 @@ SELECT * FROM t; 2 rows in set (0.01 sec) ``` -The re-assigned value is `101`. This shows that the size of cache for allocating the auto-increment ID is `100`. +The newly allocated value is `101`. This shows that the size of cache for allocating auto-increment IDs is `100`. In addition, when the length of consecutive IDs in a batch `INSERT` statement exceeds the length of `AUTO_ID_CACHE`, TiDB increases the cache size accordingly to ensure that the statement can be inserted properly. From e50aeb84a572198af39fd8883eb033184de2aece Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Mon, 21 Oct 2024 15:12:22 +0800 Subject: [PATCH 09/13] Update auto-increment.md --- auto-increment.md | 1 - 1 file changed, 1 deletion(-) diff --git a/auto-increment.md b/auto-increment.md index 53eda9271e195..814c89f78880b 100644 --- a/auto-increment.md +++ b/auto-increment.md @@ -309,7 +309,6 @@ Query OK, 0 rows affected (0.02 sec) INSERT INTO t values(); Query OK, 1 row affected (0.00 sec) -Records: 1 Duplicates: 0 Warnings: 0 SELECT * FROM t; +---+ From 86c5e48275205a8c92b2800212a459d3bb3f553c Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Mon, 21 Oct 2024 15:14:30 +0800 Subject: [PATCH 10/13] Update auto-increment.md Co-authored-by: xixirangrang --- auto-increment.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/auto-increment.md b/auto-increment.md index 814c89f78880b..18285f9b7d9d3 100644 --- a/auto-increment.md +++ b/auto-increment.md @@ -348,7 +348,7 @@ SELECT * FROM t; The newly allocated value is `101`. This shows that the size of cache for allocating auto-increment IDs is `100`. -In addition, when the length of consecutive IDs in a batch `INSERT` statement exceeds the length of `AUTO_ID_CACHE`, TiDB increases the cache size accordingly to ensure that the statement can be inserted properly. +In addition, when the length of consecutive IDs in a batch `INSERT` statement exceeds the length of `AUTO_ID_CACHE`, TiDB increases the cache size accordingly to ensure that the statement can insert data properly. ### Clear the auto-increment ID cache From 67d6adf4ca9f68768e78d8725cc3d5c612bce652 Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Mon, 21 Oct 2024 15:21:21 +0800 Subject: [PATCH 11/13] Update auto-increment.md --- auto-increment.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/auto-increment.md b/auto-increment.md index 18285f9b7d9d3..38b85fbf2ad1a 100644 --- a/auto-increment.md +++ b/auto-increment.md @@ -354,7 +354,7 @@ In addition, when the length of consecutive IDs in a batch `INSERT` statement ex In some scenarios, you might need to clear the auto-increment ID cache to ensure data consistency. For example: -- In the scenario of incremental replication using [Data Migration (DM)](/dm/dm-overview.md), once the replication is complete, data writing to the downstream TiDB switches from DM to your application's writing operations. Meanwhile, the ID writing mode of the auto-increment column usually switches from explicit insertion to implicit allocation. +- In the scenario of incremental replication using [Data Migration (DM)](/dm/dm-overview.md), once the replication is complete, data writing to the downstream TiDB switches from DM to your application's write operations. Meanwhile, the ID writing mode of the auto-increment column usually switches from explicit insertion to implicit allocation. - When your application involves both explicit ID insertion and implicit ID allocation, you need to clear the auto-increment ID cache to avoid conflicts between future implicitly allocated IDs and previously explicitly inserted IDs, which could result in primary key conflict errors. For more information, see [Uniqueness](/auto-increment.md#uniqueness). To clear the auto-increment ID cache on all TiDB nodes in the cluster, you can execute the `ALTER TABLE` statement with `AUTO_INCREMENT = 0`. For example: From 91e0f86bb8590722ffa9661c8eb9caebad67220d Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Thu, 24 Oct 2024 10:38:16 +0800 Subject: [PATCH 12/13] fix broken links --- auto-increment.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/auto-increment.md b/auto-increment.md index 38b85fbf2ad1a..4434fb109afbd 100644 --- a/auto-increment.md +++ b/auto-increment.md @@ -354,7 +354,16 @@ In addition, when the length of consecutive IDs in a batch `INSERT` statement ex In some scenarios, you might need to clear the auto-increment ID cache to ensure data consistency. For example: + + - In the scenario of incremental replication using [Data Migration (DM)](/dm/dm-overview.md), once the replication is complete, data writing to the downstream TiDB switches from DM to your application's write operations. Meanwhile, the ID writing mode of the auto-increment column usually switches from explicit insertion to implicit allocation. + + + + +- In the scenario of incremental replication using the [Data Migration](/tidb-cloud/migrate-incremental-data-from-mysql-using-data-migration.md) feature, once the replication is complete, data writing to the downstream TiDB switches from DM to your application's write operations. Meanwhile, the ID writing mode of the auto-increment column usually switches from explicit insertion to implicit allocation. + + - When your application involves both explicit ID insertion and implicit ID allocation, you need to clear the auto-increment ID cache to avoid conflicts between future implicitly allocated IDs and previously explicitly inserted IDs, which could result in primary key conflict errors. For more information, see [Uniqueness](/auto-increment.md#uniqueness). To clear the auto-increment ID cache on all TiDB nodes in the cluster, you can execute the `ALTER TABLE` statement with `AUTO_INCREMENT = 0`. For example: From ee609cb3b15a31a8899fea22b78704d49c2d0916 Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Thu, 24 Oct 2024 10:38:48 +0800 Subject: [PATCH 13/13] Update auto-increment.md --- auto-increment.md | 1 + 1 file changed, 1 insertion(+) diff --git a/auto-increment.md b/auto-increment.md index 4434fb109afbd..5bfdbfc99622c 100644 --- a/auto-increment.md +++ b/auto-increment.md @@ -364,6 +364,7 @@ In some scenarios, you might need to clear the auto-increment ID cache to ensure - In the scenario of incremental replication using the [Data Migration](/tidb-cloud/migrate-incremental-data-from-mysql-using-data-migration.md) feature, once the replication is complete, data writing to the downstream TiDB switches from DM to your application's write operations. Meanwhile, the ID writing mode of the auto-increment column usually switches from explicit insertion to implicit allocation. + - When your application involves both explicit ID insertion and implicit ID allocation, you need to clear the auto-increment ID cache to avoid conflicts between future implicitly allocated IDs and previously explicitly inserted IDs, which could result in primary key conflict errors. For more information, see [Uniqueness](/auto-increment.md#uniqueness). To clear the auto-increment ID cache on all TiDB nodes in the cluster, you can execute the `ALTER TABLE` statement with `AUTO_INCREMENT = 0`. For example: