- nebula 版本:数据库v2.0.1 + Java客户端v2.0.0
- 部署方式(分布式 / 单机 / Docker / DBaaS):分布式
- 是否为线上版本:Y
- 相关的 meta / storage / graph info 日志信息(尽量使用文本形式方便检索):无错误日志
我们在三台机器上部署了NebulaGraph集群,三台机器的IP分别为:
- 内网xxx.xxx.xxx.29 公网yyy.yyy.yyy.29
- 内网xxx.xxx.xxx.72 公网yyy.yyy.yyy.72
- 内网xxx.xxx.xxx.79 公网yyy.yyy.yyy.79
重要前提:在我们的环境下,不同机器间只能通过内网IP相互访问,无法通过公网IP相互访问。
调用MetaClient的listHosts()方法:
方法返回的HostAddr集合中包含以下六个地址:
可以看出,同一台机器的HostAddr重复列出了两次,其中一次是内网地址,另一次是公网地址。
这个情况会造成什么问题呢?
问题就是StorageClient中的scan系列方法,会先调用MetaClient的listHosts()
然后与方法返回的HostAddr建立连接
然而我们上述的重要前提是,我们无法与机器的公网地址建立连接
这就会导致,其中三个连接无法建立,且该异常信息会被填充到exceptions列表
而如果exceptions列表非空,scan系列方法就会抛出异常失败
就导致了
StorageClient不可用,如下例:
1 个赞
问题一:
应该是之前给storage修改过ip,所以旧的ip也会保存,但是旧的ip会在一个星期之后就会删除的。
问题二:
storageClient获取host信息需要做下修改,应该拿那些online的机器。我们做下修改,谢谢你的反馈。
我记错了,是一天。你可以修改在metad的配置文件里面增加 --removed_threshold_sec= 60这个参数,重启服务,一分钟后就会删除offline的host, removed_threshold_sec 现在是 24*3600*3600
1 个赞
不好意思问题好像没解决,我这样设置并重启metad后,StorageClient一条边都扫不到,ScanEdgeResultIterator的next()方法最终用来返回的results永远是空集
此外还出现了
success=false → finalResults=null → scanEdgeResult.dataSets=null → ScanEdgeResult的constructEdgeRow()方法判断dataSets.isEmpty()时抛空指针 的问题,不过这个问题next()很多次以后才会出现,没有debug出来
你上面的问题是offline的host删除问题,你改了时间没有删除吗?你在console执行 show hosts截图
你现在的问题是扫不到数据,那麻烦你贴下扫数据的代码,还有你通过console读数据的截图。
改了时间删除了
扫数据代码和上面问题基本是一样的,上面问题也是MetaClient导致StorageClient扫数据失败
在NullPointerException出现前,next()的finalResults都是空集
buxcon
10
这个事情比较影响业务,请问我直接drop space然后重新写入有可能避开这个问题吗
buxcon
11
drop space后重新写图,问题似乎得到了解决。
next()方法中的finalResults不再存在是空集的情况,ScanEdgeResult的constructEdgeRow()方法也不再抛空指针。
不过既然是在代码中指定的dataSets有可能为null,调用dataSets.isEmpty()前还是先进行一下!=null的判断比较好吧。
调用dataSets.isEmpty()前还是先进行一下!=null的判
dataSet 为空的问题在 master 代码已经是修复的
buxcon
13
我们用的maven的release包,请问这个包什么时候会发版呀,之前好像说六月底
是更推荐用master代码自己打包吗
版本可能要8月份再发了,不过你可以用snapshot版本,当然服务端也要用master版本,因为接口有改动。或者你自己把相应的pr check pick到release的代码上面,自己打个包,就不用升级服务端。pr链接 fix NPE when get scan results by Nicole00 · Pull Request #297 · vesoft-inc/nebula-java · GitHub
buxcon
15
好的。
在这之后今天又出现了新问题:更新已有的图时提示space not fount
你执行show hosts 截图下,我猜你之前的数据是在修改storageip之前就导入的,然后修改了storage 的ip,所以space就会找不到,因为在metad看来,space是分配到原来storage ip上面的。
buxcon
17
出来的三个是内网地址,也就是上面所谓的xxx.xxx.xxx.29、xxx.xxx.xxx.72、xxx.xxx.xxx.79。
数据确实是修改storageip前导入的,然后现在发现其实查询也不行了