Why are the peers constantly changing when using the "show table regions" command?

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

Original topic: show table regions查看peers为什么一直在变化?

| username: 江湖故人

[TiDB Usage Environment] Testing
[TiDB Version] v7.6.0
When checking show table regions at a frequency of once per second, I found that the peers field keeps changing, sometimes showing 1 value and sometimes 2 values. Does this happen in your environment as well? Is it a bug?

show create table t1;
Table|Create Table                                                                                                                                                            |
-----+------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
t1   |CREATE TABLE `t1` (¶  `c` int(11) DEFAULT NULL,¶  `c2` varchar(100) DEFAULT NULL¶) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin /*T! SHARD_ROW_ID_BITS=4 */|

set config pd replication.max-replicas =1;
show config where NAME like '%max-replicas%';
Type|Instance        |Name                    |Value|
----+----------------+------------------------+-----+
pd  |192.168.10.3:2379|replication.max-replicas|1    |
pd  |192.168.10.3:2382|replication.max-replicas|1    |
pd  |192.168.10.3:2384|replication.max-replicas|1    |

show table t1 regions;
REGION_ID|START_KEY|END_KEY |LEADER_ID|LEADER_STORE_ID|PEERS       |
---------+---------+--------+---------+---------------+------------+
    14025|72000001 |78000000|    16277|              2|16277, 16278|
REGION_ID|START_KEY|END_KEY |LEADER_ID|LEADER_STORE_ID|PEERS|
---------+---------+--------+---------+---------------+-----+
    14025|72000001 |78000000|    16288|              2|16288|
REGION_ID|START_KEY|END_KEY |LEADER_ID|LEADER_STORE_ID|PEERS|
---------+---------+--------+---------+---------------+-----+
    14025|72000001 |78000000|    16299|              2|16299|
REGION_ID|START_KEY|END_KEY |LEADER_ID|LEADER_STORE_ID|PEERS       |
---------+---------+--------+---------+---------------+------------+
    14025|72000001 |78000000|    16814|              3|16814, 16816|
| username: zhanggame1 | Original post link

Try restarting the cluster.

| username: dba远航 | Original post link

Is there any other operation on this table currently?

| username: lemonade010 | Original post link

Marking this for future reference.

| username: wangccsy | Original post link

Will it output if there are changes?

| username: TiDBer_jYQINSnf | Original post link

Post the changes from both times to see if it’s the same region.

| username: TiDBer_jYQINSnf | Original post link

Is this the result of multiple attempts? The leader keeps changing. Check from PD to see if the region’s version is constantly increasing?

| username: 江湖故人 | Original post link

What do you think?
The test paper, this table hasn’t changed.

| username: TiDBer_jYQINSnf | Original post link

Is the correspondence of this column correct? It looks like the region_id is always 14025, but the leader_id is sometimes 16277 and sometimes 16288.

If you are sure that the peers of a certain region are changing back and forth, confirm it in PD.
Using pd-ctl region 14025 will show the information of region 14025. If the conf_version increases, it means the peer has changed. If the version changes, it means there has been a split or merge.

| username: Soysauce520 | Original post link

Are you stress testing? Is the CPU usage of TiKV high?

| username: Aunt-Shirly | Original post link

Your replica count is set to 1, PD 配置文件描述 | PingCAP 文档中心. Normally, the number of peers corresponding to a region should be 1. The reason why there are 2 might be because you triggered hotspot scheduling or similar during testing. During the data migration process, multiple peers may appear. When migrating data from tikv1 to tikv2, a copy (peer) will first be made on tikv2. After the migration is complete, the copy on tikv1 will be deleted. Therefore, after the data migration is complete, the number of peers in the region will return to 1. To know if scheduling has occurred, you can check the monitoring under pd->operators.

| username: 数据库真NB | Original post link

There should be write or delete operations on this table, which affected the status of the data file.

| username: zhanggame1 | Original post link

Is there a large amount of data being written that causes it to keep jumping back and forth?

| username: Trouble | Original post link

Wow, that’s amazing. Can restarting fix it?

| username: redgame | Original post link

This is normal, right?

| username: 江湖故人 | Original post link

Bro, does yours do this too?

| username: 江湖故人 | Original post link

This table hasn’t undergone any changes, it might be related to my use of the playground.
It seems that others don’t have this issue in their environment, so I’ll close the issue for now.

| username: zhanggame1 | Original post link

For testing, a single-machine deployment is sufficient. The playground still seems to have many issues.

| username: system | Original post link

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