最近在看这篇文档
其中有个地方提到一点.
...
还有一种特殊情况：曾经创建过大量 Table 然后又清空了（truncate 操作也算创建 Table），此时如果开启了 split table 特性，这些空 Region 是无法合并的
...
怀疑我的集群与这问题很像.
region数特别高,合并开很大治疗效果也不明显,propose wait duration时间很长.
下面贴一下现状.
从文中的理解,进行判断.
集群部署差不多5个多月了.查看gc_delete_range里有个5K左右的样子
如果按照5 * 30天 = 150天,每天就只算有3000的话,也有150 * 3000 = 45W个的样子.
难道真的像文中所说的那样,会有合并不掉的情况吗?
用pd命令看看
发现了有些 approximate_size 为 1的, 难道这就是那些不能被合并掉的?
简单的统计了一下. 50多万个, 与刚才的估算相差不大.
现在我可以怎么操作呢?
像文中那样吗? 还是有其他骚操作?
主要是,我在文档里看到的介绍都是对于3版本的操作.
但是我现在都是2,所以菜鸡不敢乱动.
https://github.com/pingcap/thirdparty-ops/tree/master/tidb-scripts
可以使用 Cluster_Region.py 脚本检查一下可以合并的 Region 数量
还有目前的 max-merge-region-size 和 max-merge-region-keys 是多少？
"max-merge-region-size": 256,
"max-merge-region-keys": 0,
我们俩是一个团队的
您好：
raftstore cpu比较高，看起来和region数量多有关. 麻烦查询下当前可以合并的region的数量，多谢.
./bin/pd-ctl -d region | jq “.regions | map(select(.approximate_size < 20 and .approximate_keys < 200000)) | length”
./bin/pd-ctl -d region | jq “.regions | map(select(.approximate_size < 20)) | length”
./bin/pd-ctl -d region | jq “.regions | map(select(.approximate_size < 50)) | length”
./bin/pd-ctl -d region | jq “.regions | map(select(.approximate_size < 96)) | length”
上传后格式有些不清楚，按照图片查询
你好： 可以看到能够merge的region并不是很多，只有1万多，请问是否有可能升级到高版本v3.0.4以后，例如v3.0.5,或者v2.1.18吗？
现在就是想着往3来升级
但是数据量太多,不敢轻举妄动,想着是先撸掉一批region再迁移或者升级什么的.
难道我现在这个数据量可以直接升级吗?
我现在想知道的是,那些size不过百的region,算是空region吗?
如果按照文档里的操作,会实现跨表的region合并吗?
你好： 上面脚本统计出来的大小是M，所以不是空region
哥们你应该统计下region size 小的，并且 region-keys 特别大的。
比如说，查看region size 在20M以内，但是keys的数量缺失大于20万的看看。
select(.approximate_size < 20 and .approximate_keys > 200000
统计了小于的和 只统计size小于的，不是可以计算出来了吗？ 您这句话是想要说明什么？
这些很有可能就是空的region啊，我的集群里面有大量的region size只有1M但是keys的数量却是700多万的region.
配置merge的时候，可以把 max-merge-region-keys 调整为一个很大的值，用来合并这些不正常的region。
我们自己讨论的也是,改下参数,然后重启下.
不知道会遇到些啥未知风险.
哥们,你们当时这么操作的时候顺利吗?
还有个不明白的是,这个keys为什么会涨到这么多,它是怎么来的呢?
我的版本是3的，只是因为是从2.0升级上去的，merge升级后并没有开启。
开启merge只需要在pd上配置参数即可，不需要重启节点的。
版本为2的话，这个要看官方文档，或者看下厂家的建议了。
您好，我也想问，合并几十万个empty region 是否需要开启跨表 region merge？怎样开启？
