机器重启后导致分片不正常(当前cycle 正在执行时,重启)

zh_harry 发布于 2017/07/10 13:16
阅读 258
收藏 0

业务描述:
4台机器,一共180个分片,昨天跑job,监控一直正常
今天早上重新部署加上配置event-trace-rdb-data-source="my-datasource"
job.monitorExecution=true
结果导致分片数不正确,经监控正在执行的任务数(我们数据库有监控)发现只有10几个任务在跑
然后将以上两个匹配拿掉,再次发布,重新测试,结果一样
再次在console 后台,将机器删除掉,再次发布,重新测试,结果一样
目前测试结果,只有一个任务在跑(每台只有一个分片 总分片数180)
所以怀疑没有触发分片

还是原来的name-space 直接将分片数修改成88 查看job 后台如下图:

重新部署,重新enable job ,分片依然不正确 

解决办法:通过更换name-space 分片结果正常

所以怀疑分片的状态信息在zk中有历史记录可能导致分片不正常,具体原因不详。

有时间帮忙看一下,谢谢!!!


 

以下是问题补充:

@zh_harry:补充下,我们线下需要1000多个分片,需要注意哪些吗? (2017/07/10 13:26)
@zh_harry:monitorExecution已经撤消回false,结果依然不正确。 (2017/07/10 14:15)
@zh_harry:从结果上来看,我换了个name-space就正常了,可以推断可能是因为zk里的分片历史状态影响当前的分片结果。 (以上结果是MonitorExecution =false的情况下) 我描述一下我的操作步骤: 1.程序当前分片任务都正在执行,重新启动web程序,job 变为disable状态 2.后台enable 后,分片异常,真正执行的分片任务与后台的分片数不一致。 3.反复进行以上操作结果不变 (2017/07/10 14:42)
加载中
0
亮_ShardingSphere
亮_ShardingSphere

1. 分片数量没有限制,这个是确定的。

2. 我们确实没有测试过这么多分片的情况,我们一般是分24片。

3. monitorExecution开启之后,不应用于执行间隔短的作业,分片也不宜太多。因此每次作业间隔时间,开启了monitorExecution的作业会向zk写入分片数*2次操作(没个分片记录开始和结束状态)。因此,瞬时向zk写入2000次操作是zk所不能承受的。zk可以承载很高TPS的读请求,但写请求不行,TPS 2000的写请求是无论如何承受不了的,因此不建议分片很多的情况开启monitorExecution。单一作业tps 2k的话,多作业这个值还需要乘以作业数量。

4. 配置event-trace-rdb-data-source应无影响。

总结,应该是开启了monitorExecution导致的zk延迟。PS:ZK的写入请求根据服务器的配置应为几十至上百。因此请妥善处理monitorExecution参数。

返回顶部
顶部