- nebula 版本：3.6.0
- 问题的具体描述
集群加入新机器后同步数据并没有向新机器发送分片，同步了几十个图空间，分片全在其他机器上，日志和服务状态没有异常。看手册介绍，分片存储在哪里是meta服务决定的，具体是什么策略呢？现在的分片情况看上去很糟糕，是否可以进行有效的人工干预？
我是说我新数据进nebula集群它不会向这一台新机器发送分片，因为一次性加了三台，另两台都是会拿到分片的，应该不是balance data配置的问题吧，我也没用这个命令进行均衡
没理解你说的，你的意思是你原来有一个nebula集群，然后你又往这个集群加了三个机器，然后其中的两台有分片自动同步过来，一台没有自动同步？
原来有一个nebula集群包含4台机器，然后往这个集群加了三个机器，在这个集群创建50个图空间，写入数据，发现只有六台机器有分片，有一台机器一直没有负载没有分片，如上面的截图所示。这个问题很难理解吗？就没有自动同步的事，全是人工触发的同步
所以你是在集群处于七台机器的时候创建的space还是说你在集群是4台机器的时候创建的space？每个space的副本数和分片数是多少呢？
这里我们讨论的图空间都是7台机器时创建的，副本数是1，分片数是3
明白了，
那我先回答你分配策略的问题，正常来说分配策略是：
对于单个space来说，副本数 * 分片数/活跃的storaged个数，这就是每个storaged节点所持有的这个space的分片数量；如果说你这种情况，副本数 * 分片数=3，storaged个数大于3,那就是按照下面的总数看哪个有空闲
对于所有space来说，就是所有space的副本数 * 分片数数量总和/活跃的storaged个数，这就是每个storaged节点持有的所有分片数
所以造成你这个现象的原因可能是，创建哪个space的时候，7.227.5.1处于离线状态或者说可能是刚加入，没有达到两个心跳周期，metad认为这个节点还没准备好
人工解决方案就是我发的，手动执行balance data命令 + balance leader命令(可能不需要，可以观察balance data命令之后主分片是否均衡)
1 个赞
但是我肯定是确认了所有服务状态正常才开始同步的，7.227.5.1也不是最后加入集群的机器，后面加入的机器正常说明不是没达到两个心跳周期，所以我觉得这两个原因不太能解释我遇到的问题。50个图空间也是分了好几天同步的，就是想测试7.227.5.1为什么不能拿到分片
目前发现是同步时把分片数改成storage数后7.227.5.1开始有分片进入了
创建为啥要叫成同步 
就让我总是反应不过来
因为创建了要写入数据，我们是从一个库往nebula写，所以叫同步习惯了
那难道是取余了？就是按照分片id直接对机器取余，然后确认分配到哪个机器上？我等会看下代码去。但是可以按照我提供的方案试下
好的，我其实也是有这个猜测，麻烦帮忙确认一下
看了下代码，是我最开始哪个说法。不是取余的
好吧，那就不清楚怎么回事了，我选择改分片数了
- partition 数只有 3，有点太少了，建议取大点，文档上有说明建议值
- partition 在创建 space 的时候就确定好了。至于这个 partition 有没有数据，要看数据有没有倾斜。
此话题已在最后回复的 30 天后被自动关闭。不再允许新回复。