Star

长时间未恢复auto compact后遇到的问题

背景:
有两个space,a和b
a是在线服务,持续使用中(不停的在进行insert、go等操作)
b是新建的space,打算往里灌数(大量的边,上百亿)

操作步骤:
1.为了往b里面灌数的速度快一些,所以先停掉了auto compact
2.开始往b里面大量灌数
3.灌完数之后忘了打开auto compact了
4.过了很久很久之后想起来了,此时打开auto compact
5.整个集群进入到"假死"状态(所有insert、go请求全部超时,甚至studio都链接不上graph,即便链接上了到选space那里都选不了,疯狂转菊花)

疑问:
1.为什么会造成"假死"状态?还会有什么操作会导致类似的情况发生吗?我应该如何避免?~
2.在已经忘了很久才重新打开auto compact的情况下,我应该如何操作才能顺利的重新开启auto compact?

还望不吝赐教~~非常感谢~!

问题1,一般是没做compact,数据量太大
问题2,可以修改disable_auto_comactions参数(在storage 配置文件里面),设置成false,然后重启服务。

数据量大~ 就应该假死嘛? compact的线程数是固定的呀~

等到compact结束呢?状态是否恢复正常了?

在compact后恢复正常了~
我那个compact的线程数就4个… 所以即便数据量很大的情况下,compact会导致服务完全不可用吗?~

还有一个后遗症… 就是leader的分布全部混乱了… 然后此时如果你去balance leader的话 他半天没有响应,过一段时间就超时了… 但是你再show hosts的时候,他实际接受了balance leader指令,也执行了balance…

因为我们的part是在一个rocksEngine中的逻辑划分,做compact的时候是针对整个engine的操作,这个过程中会导致partLeader错乱的情况。

1赞

compaction的时候,io往往会打满,这种情况下你可以给compaction限速。rate_limit
同时compaction线程数也是可以设置的,num_compaction_threads。
导完数据之后做compaction,建议在线上流量低峰期做。

1赞

我猜是1. L0的数量太多了,我记得L0是无法并发的(因为overlap太多了)
or 2. IO太猛了
3. 大数据量写入可以试试已经开发好的spark sst ingest工具。比IO写入更合理一些

感谢各位的解答~!
现在balance leader又出问题了…我再单开一贴…

如果IO很大的时候,raft选举会有问题。。。日志没法写下去。

你storaged的参数贴一下。

配置之前贴过啦~

现在经过一宿了。。io应该已经降下来了~

开了个新帖子~ 大佬请移步

1赞

浙ICP备20010487号