如果 metad 的端口暴露出来了，其他的 pod 使用 metad 的 ip 加端口就好了。
你这边只是想验证一下 nebula 吗？如果是常规部署的话，应该是不会像上面这样部署的。这种方式的维护成本很高啊。
如果只是像本地简单验证一下，还是建议你先用 nebula-docker-compose 起个单机的集群实验一下。
我现在本地已经搭好了 nebula, 并且基于这个实现了一个知识图谱。现在在部署测试环境，原本按照 Kubernetes 部署 Nebula 图数据库集群 做的，但是一直有问题，所以就手动一个一个 docker container 搭建了。。
我们正在针对 2.0 的版本重写其中的 k8s 的配置文件，你可以再耐心等一下，估计很快就会有 PR 出来了。你到时可以先按照新的部署方式部署。最终还是要靠 nebula-operator 来在 k8s 平台上运维的。
@kevin.qiao 你的 PR 出来后，可以在这里回复一下。
请问大概什么时候能出来呀，因为我们这两天急着上线，请问还有其他的部署方式吗？或者就是我现在的部署具体是哪里有问题呀，我是按照我上面贴的配置文件做的
PR 估计今天验证完能出来，因为改动不是很多。
使用 裸的 pod 部署，以后的运维基本交给了运维人了, k8s 能帮你做的事情就很少了。
这个我和现在 K8s 的大佬商量下哈。
我想再问一下，我现在创建了几个格式一样的图空间 （标签，边类型，索引都一样）。但是用同一条命令执行，出来的结果格式完全不一样。请问有可能是什么原因呀？
第一个：
第二个：
还有的空间会报错：
但是同样的语句，在另一个空间上就是对的：
先说前面的问题，上面的所有操作都是针对同一个 graphd 吗？你部署的 graphd 是在同一个结点吗？猜测其中的一个原因是部署的不同的 graphd 使用了不同的 docker image。最近我们有更新 FETCH PROP 的返回格式，较新的 graphd 应该是返回下面的格式，老的应该是返回上面的格式。
数据插入的问题，是刚创建完 edge 就执行的插入吗？还是每次执行都是失败？如果每次都失败可以查看一下 storage 的日志，看看有什么 error 信息输出？
cc @jievince
我在 API 的查询语句有用到 "FETCH PROP ON relation -2334125896672733063->-2447195518089130532;" 这样的语句, 执行时会出现以下线程堵塞的报错，但是我用协程写的代码，应该是不会堵塞的。在 FETCH PROP 格式更新之前也没问题的。如果我把这句注释掉，其他都能正常跑通：
insert 这个问题已经解决了，是我 storaged 的配置问题。
现在 nebula-java client 的实现应该还是同步的，感觉应该跟 FETCH 语句没什么关系，你可以在 console 中看看这个句执行的时间多久。
看你用的 vertx 框架，这个框架中的每个 verticle 都是单线程执行，如果其中某个任务阻塞太久就会抛出异常。但是 FETCH 语句理论上不应该成为慢 query，但是看调用栈是在 edge（relationship）的格式化字符串上，你试试把结果变成 string 的逻辑注释掉看看还会不会出异常，如果不会的话，可能这块的逻辑需要优化。
我找到问题了，是我中间有一个 print(session.execute(…)) 的语句，注释掉就好了。应该是 session 不能被 print 吧。
1 个赞
你那句是实际是 print 的 client 返回的 response 的结果。也是调用栈里面的 String.valueOf 然后触发了 ResultSet.toString，最后调用到了 Relationship 的 toString。
我想再问一下，我把 /usr/local/nebula/etc/ 下 graphd 的配置文件挂载到主机目录下了，那在 command 命令中需要加上 --config_dir = /usr/local/nebula/etc/ 之类的命令吗？
不需要，只要你挂载的主机目录映射到容器的目录地址是 /usr/local/nebula/etc 就可以。因为镜像中使用的配置的路径就是上述目录，只要能找到对应的文件就可以了。对应 Dockerfile 的地方见这里。
确认一下 nebula-graphd.conf 名字没问题吧
应该没问题，我没有改过这个名字的
按理说不应该这样，确认一下 /data/nebula/config_stateful/graphd 这个目录下有没有上述的文件？