Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.
Original topic: max-replicas 在什么情况下会失效？
[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.
No, it’s a standard deployed cluster with 6 TiKV nodes.
Take a look at the detailed information of the relevant region.
Perhaps the records in this table are incorrect or inaccurate, but the results seen from SHOW TABLE REGIONS are accurate.
Why did I get an error when querying this table directly?
Add WHERE TABLE_SCHEMA='xxxx'.
This query checks the replicas of the region, or directly querying through pdctl would be correct, right?
This works, but it seems that the peercount is indeed displayed incorrectly.
Yes, the information shown in this table is incorrect. What I see through show table regions is correct.
No, this table cannot find the number of region replicas.
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. 
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.
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;
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
|
username: CuteRay
|
username: 
|
username: 
|
username: 
|
username: 
|
username: