Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.
Original topic: Duplicate entry for key ‘PRIMARY’
[TiDB Usage Environment] Test
[TiDB Version] 4.0.11
[Problem Encountered] Program encounters duplicate primary key conflict
[Reproduction Path] Occasional in program code
[Problem Phenomenon and Impact]
The table’s primary key is auto-incremented. When the program inserts without specifying the primary key, it reports a primary key conflict, and the conflicting primary key is from data several months ago. I want to know under what extreme circumstances this issue could occur?
[Attachments]
Check if it matches your situation.
Has there ever been a situation where the primary key was explicitly inserted? This could potentially lead to primary key conflicts.
Are you referring to the situation where the data from June 210031 was manually inserted with a specified ID value, and then subsequent inserts without specifying an ID might also result in conflicts? How can this situation be resolved?
You can consider restarting all TiDB nodes, which will reallocate based on the maximum ID value of the table. However, try to avoid explicitly inserting auto-increment IDs in the future.
If manual maintenance requires manually specifying the ID for insertion, does it also require a restart? Wouldn’t that make maintenance very troublesome?
The auto-increment ID is a value assigned in batches to each TiDB server by the system (default is 30,000 values). It depends on how many TiDB servers you have. Directly display and write a larger value. Subsequently, use implicit execution uniformly.
Is there a way to reproduce this issue? The developers reported that the code would encounter this problem, but I manually executed it hundreds of times without any occurrence.
Oh, it might be caused by execution on different nodes.
Tried on different nodes, easily reproducible.
This topic was automatically closed 1 minute after the last reply. No new replies are allowed.