关于 region split 机制的疑问

🪐 TiDB 技术问题 性能调优
1

【 TiDB 使用环境】测试
【 TiDB 版本】v6.5.0
【遇到的问题：问题现象及影响】
照目前我对 region split 和 merge 的理解，主要有以下相关参数

// 控制 pd 最大可以 merge 多大的 region
show config where name like 'schedule.max-merge-region-size'; // 20MiB
show config where name like 'schedule.max-merge-region-keys'; // 200000

// 控制 region 在被 kv split 之前最大可以多大
show config where name like 'coprocessor.region-max-size'; // 144MiB
show config where name like 'coprocessor.region-max-keys'; // 1440000

// 控制 region 被 split 出的新的region多大
show config where name like 'coprocessor.region-split-size'; // 96MiB
show config where name like 'coprocessor.region-split-keys'; // 960000

首先 schedule.max-merge-region-size 和 schedule.max-merge-region-keys 似乎存在一些歧义，个人认为需要明确这个配置项是用于限制 region merge 还是用于触发 region merge

image
image1135×329 34.3 KB

image
image939×191 10.8 KB

我的疑问主要集中在第三组也就是 coprocessor.region-split-size / keys，假设有一个 region 大小为 150MiB，满足前两组配置的要求需要进行 split，那么在 split 之后我们获得的 region 数量和大小是如何决策的？

我是否可以认为：因为 coprocessor.region-split-size 为 96MiB, 那么我们将获得左 96MiB 和右 54 MiB 两个 region。如果设置 coprocessor.region-split-size 为 40MiB，那么我们将获得从左至右连续的 40MiB 40MiB 40MiB 30MiB 四个 region。

另外一个问题，在使用 auto_increment 时，若 region 按上述方案 split，那么在 split 后所有的数据仍会集中写入在 split 后的最右侧的 region 上，此时我们所有的 region 的大小是否应几乎全部为 96MiB，而持续插入时只在最右侧的 region 上存在 54MiB-144MiB 的大小变化，并承担绝大部分写入压力？

2

分裂是对半分裂的，有2个算法，一个是精确分裂，就是会扫描这个region范围内的所有key，算出来从哪个key开始时一半，一个是大概估计，就是估计出对半分的key是哪个，然后根据key去分裂。
max-merge-region-size/keys 可以说是限制，也可以说是触发，超出这个限制就可以合并，不够就不合并

3

这个我是因为看图2中说明 “超过这个限制时不会合并”，但没有说明没超过时是否要合并或者由什么控制，感觉如果是由单个参数控制的话，表述上有些不同
（我也懵了刚才）

4

审题错了。。。。
这个是合并的参数。
超过20兆就不合并。
超过144兆就分裂。分裂后是假设是72兆，然后再删除数据，region慢慢少，少到20兆已下，开始合并。

5

如果都是对半分裂的话，它是怎么确定分裂出region的个数的呢，还有就是 coprocessor.region-split-size 对这个过程有什么影响？

6

一分为二。coprocessor这个我不清楚，我都是从pd里面看。如果一分为2后还不满足条件，那就再对新region触发分裂，再一分为二。

1 个赞
7

我的理解：
schedule.max-merge-region-size 是调度器中一个用来限制Region合并的最大大小（MB）的参数。当一个Region的大小超过这个限制时，就不会再和其它Region合并了。
coprocessor.region-max-size 是一个Coprocessor（协处理器）的参数。是一个用来限制Coprocessor单个Region最大大小（MB）的参数，当一个Region的大小超过这个限制时，就开始分裂了。
oprocessor.region-split-size 是一个Coprocessor（协处理器）的参数。跟上面coprocessor.region-max-size 是差不多的，也是超过这个阈值就开始分裂了，不过是从6.1.0才开始出现的新参数

8

这个我看描述上是和 split 后的 region 大小相关，但没有详细说明用途，之前看了这个 Region分片 - :ringer_planet: TiDB - TiDB 的问答社区 (asktug.com)
里面大家说是 “split 后默认分配的 region 大小为 96MiB”，但是总感觉还是不是很明确，不知道会不会导致 split 后产生大小不一致的 region

另外就是这个参数中 “分裂成多个” 这个描述让我甚至不能确定它是不是一定会 split 成两个region。。
image

9

再看你举的例子，假设有一个 region 大小为 150MiB，满足前两组配置的要求需要进行 split，那么在 split 之后我们获得的 region 数量和大小是如何决策的？
当coprocessor.region-split-size 为 96MiB, 那么我们将获得左 75MiB 和右 75 MiB 两个 region，因为75<96不会继续再分裂，如果设置 coprocessor.region-split-size 为 40MiB，那么我们将先获左 75MiB 和右 75 MiB 两个 region，因为75>40,会继续分裂为4个37.5MiB的四个region。
另外一个问题，在使用 auto_increment 时，若 region 按上述方案 split，那么在 split 后所有的数据仍会集中写入在 split 后的最右侧的 region 上，此时我们所有的 region 的大小应几乎全部为 144MiB，而持续插入时只在最右侧的 region 上存在 0MiB-144MiB 的大小变化，一旦达到144MiB就会产生下一个region，所以如果在使用 auto_increment 时，确实会存在写热点的问题， 所以 TiDB 提供了 Split Region 语法，专门针对短时批量写入场景作优化。

10

当coprocessor.region-split-size 为 96MiB, 那么我们将获得左 75MiB 和右 75 MiB 两个 region，因为75<96不会继续再分裂，如果设置 coprocessor.region-split-size 为 40MiB，那么我们将先获左 75MiB 和右 75 MiB 两个 region，因为75>40,会继续分裂为4个37.5MiB的四个region。

可是这样的话，在一个 region 的大小到达 coprocessor.region-max-size =144MiB 这个限制之前，它首先就会触碰到 coprocessor.region-split-size = 40 或者 75 这个阈值并进行分裂，这样的话两个参数的用途不就冲突了

第二个问题里面，其实我主要想关注是哪个参数控制 region 的平均大小。因为如果只是最右侧的 region 在被分裂，而之前分裂出的 region 又没有新的数据写入（因为 auto_increment），这会不会导致大部分的 region 的大小其实是 coprocessor.region-max-size 的二分之一？

11

coprocessor.region-split-size这个参数值的是分裂后的最大值，在自然增长的时候应该是触发不到这个参数的，是触发region-max-size后分裂之后才会触发吧？否则region-split-size比region-max-size小的话，region-max-size这个参数应该没用了。
第二个问题，实际上用auto_increment的话，理论上，确实最后会导致大部分的 region 的大小其实是 coprocessor.region-max-size 的二分之一

2 个赞
12

刚才去测了一下，参数设置和问题中一致，发现刚刚分裂时确实左右 region 一模一样大，虽然我一直是自增ID插入的，有时候它似乎不一定会在整个区间的尾部拆分新 region，反而可能会调整区间头部的的 region，即使当时并未向其中插入新数据。。（从 340000 到 440000 的 region 变化）

有点奇怪

无数据时

REGION_ID START_KEY END_KEY LEADER_ID LEADER_STORE_ID PEERS SCATTERING WRITTEN_BYTES READ_BYTES APPROXIMATE_SIZE(MB) APPROXIMATE_KEYS SCHEDULING_CONSTRAINTS SCHEDULING_STATE
1152529 t_25197_ 1152531 7 1152530, 1152531, 1152532 0 248 138042 29 41397

插入至 160000 条数据

  • 刚 split 后
REGION_ID START_KEY END_KEY LEADER_ID LEADER_STORE_ID PEERS SCATTERING WRITTEN_BYTES READ_BYTES APPROXIMATE_SIZE(MB) APPROXIMATE_KEYS SCHEDULING_CONSTRAINTS SCHEDULING_STATE
1315381 t_25197_ t_25197_r_108643 1315383 7 1315382, 1315383, 1315384 0 39 0 75 321510
1152529 t_25197_r_108643 1152531 7 1152530, 1152531, 1152532 0 95544232 119890 75 321510
  • split 后一段时间
REGION_ID START_KEY END_KEY LEADER_ID LEADER_STORE_ID PEERS SCATTERING WRITTEN_BYTES READ_BYTES APPROXIMATE_SIZE(MB) APPROXIMATE_KEYS SCHEDULING_CONSTRAINTS SCHEDULING_STATE
1315381 t_25197_ t_25197_r_108643 1315383 7 1315382, 1315383, 1315384 0 0 97245772 95 537284
1152529 t_25197_r_108643 1152531 7 1152530, 1152531, 1152532 0 0 293310 131 103120

插入至 340000 条数据

  • 刚 split 后
REGION_ID START_KEY END_KEY LEADER_ID LEADER_STORE_ID PEERS SCATTERING WRITTEN_BYTES READ_BYTES APPROXIMATE_SIZE(MB) APPROXIMATE_KEYS SCHEDULING_CONSTRAINTS SCHEDULING_STATE
1315381 t_25197_ t_25197_r_108643 1315383 7 1315382, 1315383, 1315384 0 47125038 117705772 123 817284
1315385 t_25197_r_108643 t_25197_r_270175 1315387 7 1315386, 1315387, 1315388 0 0 0 81 232868
1152529 t_25197_r_270175 1152531 7 1152530, 1152531, 1152532 0 64541976 119092468 81 232868
  • split 后一段时间
REGION_ID START_KEY END_KEY LEADER_ID LEADER_STORE_ID PEERS SCATTERING WRITTEN_BYTES READ_BYTES APPROXIMATE_SIZE(MB) APPROXIMATE_KEYS SCHEDULING_CONSTRAINTS SCHEDULING_STATE
1315381 t_25197_ t_25197_r_108643 1315383 7 1315382, 1315383, 1315384 0 31416720 63240000 131 897284
1315385 t_25197_r_108643 t_25197_r_270175 1315387 7 1315386, 1315387, 1315388 0 0 0 81 232868
1152529 t_25197_r_270175 1152531 7 1152530, 1152531, 1152532 0 266 67055 119 106304

插入至 440000 条数据

  • 刚 split 后
REGION_ID START_KEY END_KEY LEADER_ID LEADER_STORE_ID PEERS SCATTERING WRITTEN_BYTES READ_BYTES APPROXIMATE_SIZE(MB) APPROXIMATE_KEYS SCHEDULING_CONSTRAINTS SCHEDULING_STATE
1315389 t_25197_ t_25197_r_16084 1315391 7 1315390, 1315391, 1315392 0 39 0 75 548642
1315381 t_25197_r_16084 t_25197_r_108643 1315383 7 1315382, 1315383, 1315384 0 78541260 40920000 75 548642
1315385 t_25197_r_108643 t_25197_r_270175 1315387 7 1315386, 1315387, 1315388 0 39 0 110 75297
1152529 t_25197_r_270175 1152531 7 1152530, 1152531, 1152532 0 0 293310 119 106304
  • split 后一段时间
REGION_ID START_KEY END_KEY LEADER_ID LEADER_STORE_ID PEERS SCATTERING WRITTEN_BYTES READ_BYTES APPROXIMATE_SIZE(MB) APPROXIMATE_KEYS SCHEDULING_CONSTRAINTS SCHEDULING_STATE
1315389 t_25197_ t_25197_r_16084 1315391 7 1315390, 1315391, 1315392 0 0 0 107 902733
1315381 t_25197_r_16084 t_25197_r_108643 1315383 7 1315382, 1315383, 1315384 0 278 0 52 81920
1315385 t_25197_r_108643 t_25197_r_270175 1315387 7 1315386, 1315387, 1315388 0 39 0 110 75297
1152529 t_25197_r_270175 1152531 7 1152530, 1152531, 1152532 0 0 293310 138 228509

插入至 540000 条数据

  • 刚 split 后
REGION_ID START_KEY END_KEY LEADER_ID LEADER_STORE_ID PEERS SCATTERING WRITTEN_BYTES READ_BYTES APPROXIMATE_SIZE(MB) APPROXIMATE_KEYS SCHEDULING_CONSTRAINTS SCHEDULING_STATE
1315389 t_25197_ t_25197_r_16084 1315391 7 1315390, 1315391, 1315392 0 78540552 60210511 126 1214773
1315381 t_25197_r_16084 t_25197_r_108643 1315383 7 1315382, 1315383, 1315384 0 0 57495261 52 81920
1315385 t_25197_r_108643 t_25197_r_270175 1315387 7 1315386, 1315387, 1315388 0 39 0 110 75297
1315393 t_25197_r_270175 t_25197_r_431708 1315395 7 1315394, 1315395, 1315396 0 39 0 92 271336
1152529 t_25197_r_431708 1152531 7 1152530, 1152531, 1152532 0 80676142 86015 92 271336
  • split 后一段时间
REGION_ID START_KEY END_KEY LEADER_ID LEADER_STORE_ID PEERS SCATTERING WRITTEN_BYTES READ_BYTES APPROXIMATE_SIZE(MB) APPROXIMATE_KEYS SCHEDULING_CONSTRAINTS SCHEDULING_STATE
1315389 t_25197_ t_25197_r_16084 1315391 7 1315390, 1315391, 1315392 0 0 50220000 126 1214773
1315381 t_25197_r_16084 t_25197_r_108643 1315383 7 1315382, 1315383, 1315384 0 0 0 52 81920
1315385 t_25197_r_108643 t_25197_r_270175 1315387 7 1315386, 1315387, 1315388 0 0 100339986 110 75297
1315393 t_25197_r_270175 t_25197_r_431708 1315395 7 1315394, 1315395, 1315396 0 0 100340050 95 157031
1152529 t_25197_r_431708 1152531 7 1152530, 1152531, 1152532 0 0 289060 109 154677

插入至 660000 条数据

  • 刚 split 后
REGION_ID START_KEY END_KEY LEADER_ID LEADER_STORE_ID PEERS SCATTERING WRITTEN_BYTES READ_BYTES APPROXIMATE_SIZE(MB) APPROXIMATE_KEYS SCHEDULING_CONSTRAINTS SCHEDULING_STATE
1315389 t_25197_ t_25197_r_16084 1315391 7 1315390, 1315391, 1315392 0 94250670 107456465 141 1294794
1315381 t_25197_r_16084 t_25197_r_108643 1315383 7 1315382, 1315383, 1315384 0 0 0 52 81920
1315385 t_25197_r_108643 t_25197_r_270175 1315387 7 1315386, 1315387, 1315388 0 0 0 110 75297
1315393 t_25197_r_270175 t_25197_r_431708 1315395 7 1315394, 1315395, 1315396 0 0 0 95 157031
1315397 t_25197_r_431708 t_25197_r_593240 1315399 7 1315398, 1315399, 1315400 0 39 0 80 229803
1152529 t_25197_r_593240 1152531 7 1152530, 1152531, 1152532 0 96808754 71305 80 229803
  • split 后一段时间
REGION_ID START_KEY END_KEY LEADER_ID LEADER_STORE_ID PEERS SCATTERING WRITTEN_BYTES READ_BYTES APPROXIMATE_SIZE(MB) APPROXIMATE_KEYS SCHEDULING_CONSTRAINTS SCHEDULING_STATE
1315389 t_25197_ t_25197_r_16084 1315391 7 1315390, 1315391, 1315392 0 94250670 107456465 141 1294794
1315381 t_25197_r_16084 t_25197_r_108643 1315383 7 1315382, 1315383, 1315384 0 0 0 52 81920
1315385 t_25197_r_108643 t_25197_r_270175 1315387 7 1315386, 1315387, 1315388 0 0 0 110 75297
1315393 t_25197_r_270175 t_25197_r_431708 1315395 7 1315394, 1315395, 1315396 0 0 0 95 157031
1315397 t_25197_r_431708 t_25197_r_593240 1315399 7 1315398, 1315399, 1315400 0 39 0 80 229803
1152529 t_25197_r_593240 1152531 7 1152530, 1152531, 1152532 0 266 222005 77 121525
13

tidb的region拆分并不仅仅在region超过最大大小时才执行，执行Region拆分请求：当一个Region的大小超过一定阈值时，或者有热点数据导致负载压力过大时，TiKV集群中的调度器会发出Region拆分请求。

1 个赞
14

此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。