这种解决方法好像不成功啊···
上面的配法通过graph访问的应该没问题，但是这个storage client我让别的同学帮忙看看 
原理是这样的，分布式的系统的服务、进程彼此之间协作有一个服务发现的机制，一方面是要通信另一方面还要知道谁是谁（服务实例的 id）
Nebula 里的服务发现机制
- 所有的服务实体在 meta 里边去维护，比如它/它们知道所有的 storaged 分别是 s1:9779; s2:9779 …
- meta 怎么知道其他服务是谁呢？怎么发现他们呢？是他们通知 meta 的，他们在自己的配置里配上了 meta地址后就和 meta 通信了，然后告诉 meta 我是 s1:9779，而我是的这个地址，就是每一个服务配置里的 local_ip:port。
- 有了前两个机制，其他组件包括 meta 都是根据 meta 里维护的服务的列表去访问每一个服务实体的
所以这意味着想要访问这些服务的客户端（无论是 meta/graph 内部的客户端，还是外部的），都需要能够访问相应服务自己配置的 local_ip:port。
关于 storage client
一般的 storage client 是直连 meta 从 meta 获取 storage 服务列表，然后直连 storage 地址通信的，所以，如果你配置的storage local_ip 是一个本地回环(127.0.0.1，只有本机可以访问它），对于服务内部来说，本机的graphd,metad 上的 storage client 访问没问题，所以你的数据库是可用的，但是跑在其他机器上的 java storage client 就没办法访问了。
一般来说单机集群，这不是什么问题，因为大多数场景下我们不需要 storage client 去扫数据（都是一个 tag，一个 edge 那么全图扫的，属于分析场景）的，只需要通过 graph client 去进行 nGQL 的读写，只需要让 graphD 监听在外部可达的地址就可以了，graph client ，真正访问数据都是通过 graphD 内部的 storageclient 去读写 storageD。
那么如果你配置了 storage local ip 127.0.0.1 之后，导入了数据，想要再用外部 storage client 扫数据要怎么办呢？
如果不是线上服务，测试用的集群，在保证没有写的情况下，修改 storage 的 local ip 为外部可达的网段，重启服务，用 curl 改变 meta 里记录的旧的地址为新的
这里我写过一个小文章解释类似的情况 https://www.siwei.io/nebula-algo-spark-k8s/
还有，一般来说我们不太需要 storage client 的哈
2 个赞
那请问我目前是需要修改storaged_conf里的local ip和metad_conf里的哪一个ip吗
如果 java storage client 运行在 nebula 这个机器以外，需要保证 meta 和 storage 的 local ip 是外部可访问的地址，127.0.0.1 是不行的哈。
- 配置里把 127.0.0.1 换成别的网卡的地址，内部外部都可以访问
- 用 curl 把 meta 和 storage 地址都换了，参考 如何将一个机器的数据迁移到另一台机器 - #17，来自 dingding
如果可能，也可以把图库删了重新部署，用非127.0.0.1 的配置，再重新导入数据。
1 个赞
您好我把metad_conf和storaged_conf里的local ip改为了外部可访问的，其他配置没变。请问第二步curl是将原来哪个机器的数据进行迁移呢，这里不知道该怎么写。（因为我127这台主机就是10.200.37.61这台）
我觉得这样可能就可以，如果不是生产环境可以试试
curl -Gs "http://10.200.37.61:19559/replace?from=127.0.0.1&to=10.200.37.61"
好的谢谢，是直接在命令行里输入吗，还是nebula的console里呢
命令行里，需要有 curl 哈
您好我在命令行里写好了，如下：
目前metad、storaged、graphd三个配置文件的networking如下：
然后三个服务也restar过了，status的状态应该也是没问题的：
但刚去打开nebula studio结果用户名密码输入之后，点击连接一直没有反应了···
目前还没有试java里storage client，不知道会怎么样
你可以在配置里 grep 127 看下哈， meta_server_addr 好像没改
请问是将这三个配置文件的meta_server_addr也改成10.200.37.61吗，改完之后还需要再做一次curl操作吗
curl 做一次应该就行，这个配置对应的就是这部分 2. 里 提及的其他服务通过这个地址去自己找到 meta。
Nebula 里的服务发现机制
- 所有的服务实体在 meta 里边去维护，比如它/它们知道所有的 storaged 分别是 s1:9779; s2:9779 …
- meta 怎么知道其他服务是谁呢？怎么发现他们呢？是他们通知 meta 的，他们在自己的配置里配上了 meta地址后就和 meta 通信了，然后告诉 meta 我是 s1:9779，而我是的这个地址，就是每一个服务配置里的 local_ip:port。
- 有了前两个机制，其他组件包括 meta 都是根据 meta 里维护的服务的列表去访问每一个服务实体的
您好我将三个配置文件里的meta_server_addr修改好了，status服务是正常的，nebula studio可以进入，但show hosts发现127这个还是offline的，并且在storage client这边处在一直运行的状态，没有结果。
有通过 curl 执行过替换对么？
对，我看你是8号的时候已经在改了新的地址，没有 curl 去替换的情况下创建了新的 space hosttest0608 在 10.200.37.61 作为“新的” storage 的情况下，数据有点乱了（被识别为两个 storage 的实体分别有了数据），如果导入不是特别慢，你不妨把环境删干净重新导入一下。
或者，把 storaged 换回 127.0.0.1 启动起来，用 snapshot 把数据迁移一下，论坛有帖子，但是我感觉太浪费时间了，你还要去熟悉那些东西。
这种混乱的状态不值得浪费时间，不如清理干净，给外部能访问的配置重新导数据。
另外，以防万一，你确定你是真的需要 storage client 哈？java graph client 不能满足你的需求对么？