删掉之后再启动确实可以了. 我那两个异常的之前也就是创建图空间然后到入官网里basketballplayer的数据而已, 没做其他. 不知道为什么会这样
然后你那个正常的是里面还没有数据是吧?
是的. 我想到一个可能的原因: 创建图空间时设置partition_num值的问题. 我按照文档中的示例 CREATE SPACE basketballplayer(partition_num=15, replica_factor=1, vid_type=fixed_string(30)); 设置为15.
微信群里也有人提问:
所以我想会不会是partition_num的原因?
我现在partition_num设为3, 重启之后能够正常运行. 之前的是15.
我的硬件配置可能有点奇怪: 现在的运行的操作系统是安装在固态移动硬盘上的, 总容量480G, 分为3个区. 另外我主机里还有一块机械硬盘, 分为4个区. 所以我现在打开资源管理器一共有7个磁盘: CDE是移动硬盘上的固态, GHIJ的主机里原有的机械硬盘
nebula的repo装在E盘
你的是有个metad启异常，是因为接受其他metad的消息超过了它等待的时间，所以它一直没有等到响应，所以启动失败，然后它又是leader，所以其他storage是肯定也是启动失败的，partition_num的数量是影响metad存储的partition的信息和hosts信息，所以我怀疑你可能是其他metad读硬盘太慢，导致相应太久。你现在在固态硬盘上面了，还是用15个part，应该也是没有问题的。
我一直都是在固态上的呀 
那你设置为15个part，然后出现了的话，你把三个metad的v都改为3，然后再发日志出来。
设置为15个part, 导入了一些数据. 隔一会儿重启之后还是unhealthy
之后我在portainer中restart了这几个unhealthy的服务
这下多了一个服务是正常的
我继续restart其他unhealthy的服务, 早上试的时候restart一两次那些unhealthy的就healthy了, 但是下午试了好多次restart就又不行, 有几个unhealthy的还是unhealthy. 日志信息在下面
logs.zip (1.5 MB)
我刚刚试了下修改docker-compose.yaml中metad和的storaged参数:
重启服务之后就能正常运行了, 关掉之后再试了几次也一样可以, 整个启动过程从created到healthy大概需要一分钟.
是呀，前面和你说，消息延迟太高了。
该主题在最后一个回复创建后7天后自动关闭。不再允许新的回复。