Issues with Centralized Allocation of Auto-Increment IDs in v6.5.0_2

Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.

Original topic: v6.5.0 的中心化分配自增 ID 的问题_2

| username: GreenGuan

When migrating tables from MySQL to TiDB, we hoped to use TiDB’s auto-increment feature but discovered that the auto-increment IDs were rolling back across different TiDB nodes. In this example, there are 2 compute nodes and 3 KV nodes. We temporarily refer to the compute nodes as tidb1 and tidb2.

Environment Initialization:
The following is a statement excerpted from mysqldump. We hoped to modify auto_id_cache to 1 but found it could only be changed to 2.

Steps:
Step 1: Connect to tidb1, insert normally, then exit.

Step 2: Connect to tidb2, insert and find that the step size has become 2 (possibly due to auto_id_cache), then exit.

Step 3: Connect to tidb1, insert and find the ID rollback phenomenon.

Step 4: Connect to tidb1, insert twice more in sequence, note that there is still a 30007 not used in this structure.

Step 5: Connect to tidb1 again to test if tidb1 continues, and find that it does indeed continue. Note that there is still a 30007 not used in this structure.

Step 6: Connect to tidb2 again and find the ID rollback phenomenon.

| username: WalterWj | Original post link

I feel like we can go to the feedback section and report this. It still seems to be some unexpected situations.

| username: GreenGuan | Original post link

completed

| username: Billmay表妹 | Original post link

Here is the explanation: AUTO_INCREMENT | PingCAP 文档中心. Currently, we only support setting AUTO_ID_CACHE to 1 when creating a table to support globally monotonic increments. This is not a bug; it is a product design limitation.

| username: system | Original post link

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.