Under what circumstances will max-replicas become ineffective?

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

Original topic: max-replicas 在什么情况下会失效?

| username: CuteRay

[Test Environment for TiDB]
[TiDB Version] v5.4.2

In the test environment, there is a cluster with approximately 3.4T of data according to the monitoring system. The disk space is running low, so I needed to clean up some data. I checked the information_schema.table-storage-stats to see which tables are large. Then I discovered a strange phenomenon: the pd max-replicas configuration seems to have failed.

The max-replicas found via pd-ctl is the default 3, but when querying through the information_schema.table-storage-stats system table, I found that some database tables in the cluster do not have the maximum of 3 replicas. The PEER_COUNT shows 6, and strangely, in some databases, all tables have a PEER_COUNT of 6, some have a PEER_COUNT ranging from 3 to 6, and some have all 3.
The cluster does not have placement rules configured.

| username: 裤衩儿飞上天 | Original post link

Is there TiFlash?

| username: CuteRay | Original post link

No, it’s a standard deployed cluster with 6 TiKV nodes.

| username: 裤衩儿飞上天 | Original post link

Take a look at the detailed information of the relevant region.

| username: h5n1 | Original post link

Perhaps the records in this table are incorrect or inaccurate, but the results seen from SHOW TABLE REGIONS are accurate.

| username: tidb菜鸟一只 | Original post link

Why did I get an error when querying this table directly?

| username: h5n1 | Original post link


| username: tidb菜鸟一只 | Original post link

This query checks the replicas of the region, or directly querying through pdctl would be correct, right?

| username: tidb菜鸟一只 | Original post link

This works, but it seems that the peercount is indeed displayed incorrectly.

| username: CuteRay | Original post link

Yes, the information shown in this table is incorrect. What I see through show table regions is correct.

| username: CuteRay | Original post link

No, this table cannot find the number of region replicas.

| username: 有猫万事足 | Original post link

select trp.REGION_ID,count(1) from INFORMATION_SCHEMA.TIKV_REGION_PEERS trp group by trp.REGION_ID having count(1)<>3;

As long as this statement does not return any results, it should be normal.

In the table table-storage-stats, it should be the total number of peers in this table. For example, if you have 2 leader regions in this table, then the number of peers is 6.
I have a partitioned table that uses the pre-split region parameter, and the result is even like the following:

Each partition is a separate row, and the peer_count of the two partitions with data is very large. Even those without data but pre-split are not small. :joy:

| username: CuteRay | Original post link

That’s right, the SQL result is empty, which is normal.
Mine is different from yours, mine is all 6…
But thanks for clearing things up.

| username: h5n1 | Original post link

I checked my version 5.2.3, and the statistics on table size and other information are extremely inaccurate. The results of querying the same table individually and querying the entire schema are different.

Individual query:

Query all under schema:

select * from INFORMATION_SCHEMA.table_storage_stats where table_schema='skyalarm' order by 2;

| username: system | Original post link

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