通过Storage Client读取数据库时，报get storage client error错误

maweilu123 · 2022 年6 月 9 日 09:59

在console里drop吗，127那个这不是还有space在里面吗，这是要直接删除？

henry · 2022 年6 月 9 日 10:02

你这个是测试数据吗？

maweilu123 · 2022 年6 月 9 日 10:03

不是测试数据，里面有1个多亿数据···

maweilu123 · 2022 年6 月 10 日 07:20

请问还有没解决方法吗

henry · 2022 年6 月 10 日 07:46

你这个有数据drop不来了，之前没注意看。你现在出现两个host 是什么情况？你改了ip以后重新加了hosts吗？另外你现在meta storage graph三个配置文件里local_ip到底是什么？

maweilu123 · 2022 年6 月 10 日 07:56

1.我也不明确为什么会出现两个host；2.修改ip后没有add hosts。这是修改完直接show hosts的结果；3.三个配置文件里的ip就都是.61这个ip

henry · 2022 年6 月 10 日 08:08

之前没仔细看前面的经过刚才看了一遍，把整个逻辑给你理一遍，首先你要先理解127.0.0.1这个ip是本地ip，只有本地能连接也就是服务端本地连接，所以你一开始配置的127这个的时候外部即客户端是无法访问，所以你之前就应该配置实际ip。但你已经有数据了，你将配置文件里的127全部改成时实际ip，但meta里的ip信息还是127的，所以你启动后meta起不来一直报错，解决办法是将meta里的ip信息替换成新的ip，这个相当于迁移，这个操作比较复杂，我现在推荐一个简单好用的办法：
就只改graph的–local_ip为实际ip，meta和storage不变还是127，三台的–meta_server_addrs改回原来的127。因为客户端时通过graph连的，你改graph后不用迁移meta信息。例子：

maweilu123 · 2022 年6 月 10 日 08:13

好的谢谢我试下

maweilu123 · 2022 年6 月 10 日 08:34

我按照这个方式改好了，服务都能启动起来，可我在客户端访问原来在127里的数据时，还是报了同样的错

maweilu123 · 2022 年6 月 10 日 08:39

客户端里配置如下：

maweilu123 · 2022 年6 月 11 日 07:51

这种解决方法好像不成功啊···

henry · 2022 年6 月 13 日 02:39

上面的配法通过graph访问的应该没问题，但是这个storage client我让别的同学帮忙看看

wey · 2022 年6 月 13 日 02:47

原理是这样的，分布式的系统的服务、进程彼此之间协作有一个服务发现的机制，一方面是要通信另一方面还要知道谁是谁（服务实例的 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 的哈

maweilu123 · 2022 年6 月 13 日 04:09

那请问我目前是需要修改storaged_conf里的local ip和metad_conf里的哪一个ip吗

maweilu123 · 2022 年6 月 13 日 04:12

这是我之前按照上面说的配置完之后的metad_conf：

storaged_conf：

graphd_conf：

wey · 2022 年6 月 13 日 06:23

如果 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 的配置，再重新导入数据。

maweilu123 · 2022 年6 月 13 日 06:42

您好我把metad_conf和storaged_conf里的local ip改为了外部可访问的，其他配置没变。请问第二步curl是将原来哪个机器的数据进行迁移呢，这里不知道该怎么写。（因为我127这台主机就是10.200.37.61这台）

wey · 2022 年6 月 13 日 06:59

我觉得这样可能就可以，如果不是生产环境可以试试

curl -Gs "http://10.200.37.61:19559/replace?from=127.0.0.1&to=10.200.37.61"

maweilu123 · 2022 年6 月 13 日 07:09

好的谢谢，是直接在命令行里输入吗，还是nebula的console里呢

wey · 2022 年6 月 13 日 07:10

命令行里，需要有 curl 哈