Storage 服务宕机能不影响客户端查询吗？

问答 问题
1
  • nebula 版本：3.0.0
  • 部署方式：分布式
  • 安装方式：RPM
  • 是否为线上版本：Y
  • 硬件信息
    • 磁盘（ 推荐使用 SSD）
    • CPU、内存信息

问题的具体描述：

我们的 Nebula 集群共三台机器节点，每个节点上分别部署一个 metad、storaged、graphd 服务。

最近我们在对我们的服务进行故障演练，需要模拟一台机器宕机的场景。我们手工停止 metad 或 graphd 服务，发现在 console 中都还可以正常对图数据进行查询。但是当我们停掉一个 storage 服务后，查询就会报 Storage Error 这样的错：

(root@nebula) [xxj_20221201_002]> MATCH (v1:PRESS)-[e1:PRESS_BOOK]->(v2:BOOK) WHERE id(v1) IN ['30'] RETURN v2;
[ERROR (-1005)]: Storage Error: part: 6, error: E_RPC_FAILURE(-3).

Thu, 08 Dec 2022 19:11:18 CST

(root@nebula) [xxj_20221201_002]> MATCH (v1:PRESS)-[e1:PRESS_BOOK]->(v2:BOOK) WHERE id(v1) IN ['30'] RETURN v2;
[ERROR (-1005)]: Storage Error: Not the leader of 5. Please retry later.

Thu, 08 Dec 2022 19:11:21 CST

此时用 show hosts 查看节点，发现宕机的节点状态仍然是 ONLINE，大约过 30s 左右的时间，才变成 OFFLINE，Leader count 也正确分配到其他节点上。此时就可以正常查询了。

我的问题是，从宕机到自动恢复中间的 30s 是否可以调整？没有找到这方面的配置。或者是否可以在客户端做到无缝的 failover？目前测试 Java SDK 和 nebula console 都会报错。

我们的服务需要保障高可用，30s 的等待时间有点久了，不知道可有比较好的解决方案？

2

可以适当减小raft_heartbeat_interval_secs，但raft从原理上就无法实现无缝failover，或者说如果要实现无缝，性能的代价会非常高。考虑failover是非经常发生的，这是非常不合算的。

3

我觉得这和 raft 不应该是一个层次的概念。因为从 show hosts 结果来看，三个节点的 Partition distribution 都是 15 个分区，每个节点上都有着完整的数据，那么对于查询这种无状态的操作来讲，无论节点是 leader 还是 follower，都应该可以查到数据。（比如根据节点做读写分离，leader 支持读写，follower 只读）

还是说 nebula graphd 必须依赖 raft 选举，只能从 leader 上查询数据么？

据我所知，etcd 也是通过 raft 保证数据的一致性，搭建三节点 etcd 集群后，随机挂掉一个节点，客户端仍然可以正常查询。

1 个赞
4

目前我们只支持从leader上查数据。从follower中读虽然内部支持，但是还没有测试完全。

5

follow支持可读从个人角度认为，是合理的；只是从之前收集到的诉求来看，对这块的诉求还没有那么强，所以还没有落地；
稍微纠正下的一点是，做了partition以后，并不是每个节点都是完整数据，而是打散到三个节点上的，确保每个节点的负载是均衡的。也正是因为这个逻辑，所以之前follow支持读才没有那么强诉求；

6

感谢纠正。期待后续的版本中能引入这个特性，毕竟对于一些高可用的应用来说，无论开发还是运维，都背着强大的 SLA 压力啊~

2 个赞
7

我简单查了下，一般统计可用率是看1分钟内是否全部请求失败的。
不知道你们是怎么定义失败率的？
我也碰到过为了极高的可用目的，搭了两个集群的。

8

此话题已在最后回复的 30 天后被自动关闭。不再允许新回复。