我是新搭建的一套从库集群，先搭建v6.5.0版本，发现触了那个buG后，然后，又升级版本到v7.5.0。监控数据只有2-3天的数据，没法对比。不过，性能使用上，感觉比以前6.5.0版本要强很多。

好的，我看看v7.5.1版本，如果稳定，就再升级一下。tiup版本升级值得信赖！

1、生产环境的从库集群，平滑无感知从v6.5.0升级到v7.5.0版本。 2、生产环境彻底解决之前遇到的bug问题： 主从库集群均为v6.5.0版本，主库集群有cdc组件，从库集群有Tifalsh组件，进行同步大表时，tiflash会出现产生大量core文件 3、升级后超级大表的查询速度也比原来快了许多，tiflash的加载大表的速度明显加快。

调整那两个参数配置后，效果还是比较明显： [image]

嗯，好的，我使用pd-ctl修改试下

我是使用tiup cluster edit-config cluster_name编辑配置文件，添加的配置参数： max-merge-region-keys: 200000 max-merge-region-size: 20 然后，重新reload pd，发生参数并没有生效，需要reload 整个集群吗？

很奇怪，这几个参数，在2套集群，都是没有指定。但是，主库集群显示的是： [image] 难怪主库那边只有200+个empty region。看来可能是这个原因了。谢谢

[image] 2个参数均为0，1个参数为1h。这个是不是代表，无法自动合并merge呢？

根据抓取tiflash的日志，获取到当时报错的region_id，然后，再进行查询分组得到，主要集中在这3张加载到tiflash中的分区表： select -- region_id, table_id, -- DB_NAME, table_name, count(*) from information_schema.TIKV_REGION_STATUS where REGION_ID in ( 16373822 ,16373518 ,16373766 ,16373814 ,16383394 ,16374068 ,16373682 ,18008487 ,16383378 ,1…

这个量级手工合并，确实很费劲。 那只能等它自动合并？已经持续有一段时间，没有看到自动合并的迹象，哈哈 我看看你说的这几个参数，尝试调整下，等它自动合并了

# tiup ctl:v6.5.0 pd -u http://10.3.8.231:2379 region 16381494 Starting component `ctl`: /root/.tiup/components/ctl/v6.5.0/ctl pd -u http://10.3.8.231:2379 region 16381494 { "id": 16381494, "start_key": "7480000000000039FFFE5F728000000007FFA013A40000000000FA", "end_key": "7480000000000039FFFE…

更正一下，主从库集群版本均为：v6.5.0版本，是从以前的v5.4.0升级上来的。

TIKV_REGION_STATUS

感谢这么多大佬给的指点和建议，我再排查一下。目前，还有2个问题： 1、设置了tikv的region大小以及自动分割大小后，空region会不会自动合并 2、目前，这套集群从库每个月的6号，都会对1张大表进行dumpling和lightning导入到新表中，中间会有drop操作，没有delete操作 3、研发那边反馈，最近有几个围合进行过删除操作，但是，这个empty region最近一个月内，一直保持在387k，说明近期的删除操作，不是主因。 [image]

我们这边确实有几张大表是做的分区表，但是，分区表的分区字段是按照fld_area_guid进行hash。 [image] 我参考大佬的这个链接，看下如何能手工合并一下。

[image] APPROXIMATE_SIZE的大小情况