集群里某一台storage服务宕机,两副本情况下,partition leader不会发生转移

nebula 版本:v1.1.0

部署方式(分布式 / 单机 / Docker / DBaaS):分布式:三节点

硬件信息

磁盘(SSD / HDD):SSD
CPU、内存信息:

问题的具体描述
停掉某一台storaged进程,往这台节点插入数据,删除数据报错: Insert vertex not complete, completeness: 0

查询数据:[ERROR (-8)]: Get tag props failed

nebula的partition leader不会发生切换的吗

show hosts 看下?

手工停止了stop了一台storage服务,状态也显示了 offline,但是leader partition没切换。
之后往这台节点增删改查也会报错

space是几副本的?

nba3是两副本,nba2是停了storage服务的时候创建的

三个节点,2副本,一个节点挂掉后容易丢数据。

现在不是丢数据的问题啊,leader没有切换,如果用到生产,业务根本不敢用。

一个建议,3个节点的话,副本数指定到3好些。
如果一个机器挂掉,执行下 BALANCE LEADER
另外,要尽快把挂掉的节点重启,否则如果再挂一个节点集群彻底不能提供服务了

1 个赞

现网宕机,没法自动切换leader吗,即使自动切换了leader,graph会有感知吗,graph需要重启吗

grpah不需要重启

但是文档是这么写的

BALANCE LEADER

那宕机后还是需要人工干预,没有BALANCE LEADER的话,客户端读取数据时还是会有问题啊。没法保证高可用

总结一下这个问题
1,首先3个节点创建了2个副本,当一个节点挂掉后,可能某个partition只剩一个副本了,这样的话很危险,所以建议创建space的时候指定副本为3.
2,如果一个节点挂掉,nebula 会自动切换leader,这个过程有一个选举leader的时间,在这个时间段,对应的part不能提供对外服务。
3,当leader通过raft选举成功后,graph端的leader信息可能有滞后情况,这时通过上边文档中的重启graphd是一种解决办法。执行一条语句,执行后会同步leader信息,这也是一种办法。
4,如果leader出现分布不均匀的情况,可以用BALANCE LEADER使其分布均匀。
5,如果有一个节点挂掉了,可以的话要尽快重启,因为时间越长,重启的代价也就越大,可能会导致拉snapshot。

两副本是没有容错的,leader挂掉没有办法重新选举,至少三副本才有容错,理论上副本越多容错越高,当然可用性也会降低。