【详述】问题详细描述
【背景】程序stream load 每6s执行一次，每次抽取数据3500左右
【业务影响】
【StarRocks版本】例如：2.3.2
【集群规模】
【表模型】例如：主键模型
【导入或者导出方式】
这种 too many version，出现的情况下，be底层为什么不会自动版本合并了呢 ，程序停了2小时，启动就报错，不在消费数据
如果修改compaction参数，修改那几个参数，修改值为多少合适
【附件】
- fe.log/be.INFO/相应截图
show tablet $tablet_id，然后再执行下detailcmd，看下versioncount比较大的副本，然后curl metaurl，发下这个结果
出现问题的情况下，如何手工加速这个版本合并，程序启动不再报too many version
升级到2.3的最新版本试试，如果是EMR用户，可以联系他们升级
手动compaction示例：http://10.102.0.57:8040/api/compact?tablet_id=xxxxxxx&schema_hash=xxxxx&compaction_type=cumulative对11392815这个tablet手动调用compaction
这个命令试了不好用
这个是因为cumulative他有一个合并的间隔窗口。这个时为了处理MVCC的，防止合并了之后后面的查询还要查某个旧的快照，可以考虑调低这个时间
这个时主键模型？
我也遇到相同问题，手动合并也执行了，没有用。现在这个表没法使用了。主键表。麻烦给看看。
方便加个微信看看？
我在社区群6,你发个消息哇
怎么加你，我在社区群3和社区群6，你微信名叫什么，我加你，谢谢
解决方案:
先获取row_set_id
然后手动对这些rowsetid做compaction
现在解决了老的又出现新的，请问下怎么彻底解决
解决了老的出现了新的是什么意思
就是我把一张表删除重建之后就好了，运行一段时间又会出现别的表有这个问题，昨天一天出现了4-5张表了
现在你是哪个版本？
StarRocks 2.5.7版本