Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.Original topic: 关于 region split 机制的疑问
[TiDB Usage Environment] Testing
[TiDB Version] v6.5.0
[Encountered Issue: Problem Phenomenon and Impact]
Based on my current understanding of region split and merge, the main related parameters are as follows:
// Control the maximum size of a region that PD can merge
show config where name like 'schedule.max-merge-region-size'; // 20MiB
show config where name like 'schedule.max-merge-region-keys'; // 200000
// Control the maximum size of a region before it is split by KV
show config where name like 'coprocessor.region-max-size'; // 144MiB
show config where name like 'coprocessor.region-max-keys'; // 1440000
// Control the size of the new region split from an existing region
show config where name like 'coprocessor.region-split-size'; // 96MiB
show config where name like 'coprocessor.region-split-keys'; // 960000
First, there seems to be some ambiguity with schedule.max-merge-region-size
and schedule.max-merge-region-keys
. Personally, I think it is necessary to clarify whether this configuration item is used to limit region merge or to trigger region merge.
My main question is about the third group, i.e., coprocessor.region-split-size / keys
. Suppose there is a region with a size of 150MiB, which meets the requirements of the first two groups of configurations and needs to be split. How is the number and size of the regions decided after the split?
Can I assume that since coprocessor.region-split-size
is 96MiB, we will get two regions of 96MiB and 54MiB respectively? If coprocessor.region-split-size
is set to 40MiB, then we will get four regions of 40MiB, 40MiB, 40MiB, and 30MiB from left to right.
Another question, when using auto_increment
, if the region is split according to the above scheme, will all the data still be concentrated in the rightmost region after the split? In this case, should the size of all our regions be almost 96MiB, and during continuous insertion, only the rightmost region will have a size change between 54MiB-144MiB, bearing the majority of the write pressure?