- nebula 版本:v2.0.1
- 部署方式(分布式 / 单机 / Docker / DBaaS):docker swarm
- 是否为线上版本:Y / N
- 硬件信息
- 磁盘( 推荐使用 SSD)ssd 960g x 2
- CPU、内存信息 36 core, 128g mem
这个导入问题在论坛里看到过类似的帖子,比如
- 关于Nebula Graph 性能评测的问题,文档不够详细准确
- Storage Error: The leader has changed. Try again later ,Storage Error: part: 22, error: E_RPC_FAILURE(-3). 查询经常抱着两个错
- storaged性能问题
由于日志在内网无法导出,日志报错和3.中的报错最为相似。根据记忆,我这边的具体报错有几类:
- Invalidate the leader for [7, 14]
- insertVerticesExecutor failed, error E_RPC_FAILURE, part 14
- Request to “192.122.3.11”:44500 failed: N6apache6thrift9transport19TTransportExceptionE:
- Storage Error: part: 48, error: E_RPC_FAILURE(-3)., ErrCode: -8
现象1:
一开始以为是数据问题,因为测试插入10条数据,其中5条成功5条失败。后来发现vertex id以1、3、4、7结尾的row都会插入失败。
通过观察日志发现连不上其中一台服务器request to 192.122.3.11:44500 failed. 意识到不是数据问题,是被分发到该台服务器上的数据才会失败。
首先可以排除镜像问题,其次可以排除数据问题,再次可以排除leader频繁改变的问题,因为log里没有这个。
将192.122.3.11这台服务器下线(balance data remove任务会失败,因为connect不上这台服务器,暴力移出docker swarm集群并将服务器上的数据全删除,修改配置文件后重新deploy),集群能正常导入数据,大概avg row(50-100w/s)。
现象2:
尝试导入example nba的数据,是没有问题的。192.122.3.11上也有数据。
问题:
- 为什么导入ldbc数据就会出现该问题(哪怕只是10条),而导入官网例子nba就没问题呢?
- 为什么只有192.122.3.11会出问题,其他服务器都能正常工作呢?
还请nebula的朋友帮忙定位以下问题
集群配置文件如下:(192.122.3.11对应ip2)
nebula-v2-swarm.yaml (7.9 KB)
importer配置文件如下:
ldbc-importer.yaml (9.6 KB)