Will the AUTO_RANDOM primary key change after TiKV node scaling?

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

Original topic: AUTO_RANDOM的主键在Tikv的节点扩缩容后会发生改变吗

| username: TiDBer_6rCNKzOu

Will the AUTO_RANDOM primary key change after scaling in or out TiKV nodes?
I am preparing to scale out the nodes, but I am concerned about this issue because there are tables that use AUTO_RANDOM IDs for associations.

| username: forever | Original post link

Existing data will not be affected. After TiKV scaling in or out, the data movement unit, which is the region, will not change its data content.

| username: 小龙虾爱大龙虾 | Original post link

It will not affect at all; once the data is written, it will not be changed arbitrarily.

| username: zhanggame1 | Original post link

What already exists will not change.

| username: Kongdom | Original post link

It won’t change. If it changes after being written, that would be too strange.

Are you asking about auto-increment primary keys? Auto-increment primary keys might have some gaps because the auto-increment values are allocated in advance. If you scale down, there should be a missing segment.

| username: h5n1 | Original post link

It both has and doesn’t have an impact, as it is inherently random and unordered.

The principle of auto_random key is roughly as follows:

  • Sign bit: A fixed sign bit set to 0, meaning the AutoRandom allocation is always non-negative, with a length of 1.
  • Shard bits: These bits generate random numbers to scatter the ID value range. The length of this segment is specified in the parentheses following AutoRandom, with a default of 5. It uses stats to perform hashing.
  • Increment bits: These bits are used to ensure the uniqueness of the ID and the continuity of allocations during multi-value inserts within a single statement or multiple inserts within a visible transaction. The increment part is also influenced by auto_id_cache (similar to auto_increment).

The schematic diagram of the three segments is as follows:

| username: heiwandou | Original post link

It won’t change.

| username: dba远航 | Original post link

AUTO_RANDOM does not affect existing data. Shrinking the memory part in the server might result in some loss, but there are no other impacts.

| username: 稻和稻草 | Original post link

AUTO_RANDOM primary keys typically do not change after scaling in or out TiKV nodes. In TiDB, AUTO_RANDOM is a primary key generation strategy used to automatically generate a unique primary key when a table does not explicitly specify one. The generation of this primary key relies on the internal mechanisms of the database and ensures global uniqueness within the same database instance.

When you scale in or out TiKV nodes, you are essentially changing the number of physical storage nodes, which does not affect the internal primary key generation mechanism of the database instance. The generation of AUTO_RANDOM primary keys is not influenced by the number of physical storage nodes, so the AUTO_RANDOM primary keys in existing tables will not change after scaling operations.

However, during the scaling process, it is necessary to ensure the integrity and consistency of data migration. During scaling operations, the TiDB cluster will automatically migrate data to balance the load across nodes. During this process, read and write operations can proceed normally because TiDB has designed failover and data replication mechanisms to ensure data consistency during scaling.

In summary, AUTO_RANDOM primary keys will not change after scaling in or out TiKV nodes, so you can proceed with scaling operations with confidence. However, it is important to note that scaling operations may impact the performance of the cluster, so it is advisable to plan ahead and choose an appropriate time to perform the operation.

| username: andone | Original post link

What already exists will not change anymore.

| username: system | Original post link

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