TiDB v4.0.14, PD leader 节点数据盘写满的情况下无法提供服务, 为什么leader 没有自动做切换呢

【 TiDB 使用环境】生产环境 /测试/ Poc
TiDB v4.0.14, PD leader 节点数据盘写满的情况下无法提供服务, 其他pd 节点没有重新选举出Leader,导致集群彻底无响应持续20min。

最后恢复了pd 的leader 节点后集群正常

【 TiDB 版本】
TiDB v4.0.14
【复现路径】做过哪些操作出现的问题
【遇到的问题:问题现象及影响】
【资源配置】
【附件:截图/日志/监控】

这种情况应该算pd 的leader 节点宕掉了吧, 三个pd 的话,另外两个应该是可以自己重新选一个Leader出来继续提供服务的吧

只有三个 PD,其中一个已经服务失效了,那么实际上存活的只有2个 PD, 这样子就不能满足选举的场景了。只能保证此时 PD 的数据是一致的,不会丢

如果能及时的追加一个 PD 节点,则会启动选举,然后选举也是需要时间的。

如果是生产环境,你需要评估整个周期需要多久才能恢复服务了

那意思是一个集群要保证pd leader 宕机后还能正常选举leader 并保持服务,最少需要4 ~ 5个节点才行 啊

还有pd leader 节点宕机后pd 集群已经不正常了,这个时候join 一个新节点能添加进去?

一般要看高可用到什么程度,比如 tikv 节点会采用 5 节点,3 副本,或者 5 节点,5 副本

PD 也可以参考这种规划

至于 PD 集群不正常了,用 scale-out 可以试试 就知道了!
实在不行,还可以考虑用 PD Recover 来就行恢复,这种会比较有风险了.

那看来pd 基本3节点规划其实并不不是高可用

要求不一样嘛 :see_no_evil:

也算高可用,因为数据没丢失,很容易恢复,继续提供服务

scale-out pd集群的原理就是把一个新节点 join-in 到原有集群中,我是真怀疑这种状态下还能成功,我会测试下。
至于用pd-recover 恢复这个就更谈不上高可用了。

我觉得你这个解释可能还是有点问题

pd 三节点只是宕机一个,又不是宕机了两个节点,为啥会不满足选举条件呢

没事,实践出真知~ :cowboy_hat_face:

有没有哪位官方的小伙伴出来给解答下 :pray:

pd节点端口还存在的话,不影响节点之间心跳。就不能被认为宕掉了

ETCD 默认是 raft 协议,Raft协议 只支持奇数位的实例来完成选举操作

至于为啥 raft 是这样的,你可以自行查阅相关的资料

这个和我们推测的结果差不多,觉得这个说法还是比较靠谱。

那现在问题就是 pd是不是要多加一些条件做自身可用性的判断,及时让出leader 位置,毕竟这个时候还是两个节点可用, 也就是说多数派可能是正常。 如果切换leader成功,集群是可以正常服务的,恢复速度会更快吧

你这种情况,是否可以认为数据库盘写满了,但是网络间端口心跳还在,无法触发 leader election ,需要手动干预。

也可以查下日志。是否有 leader election, 确定是没触发选举 还是选举不成功。

磁盘满,网络心跳还在,不能认为是宕机,最好的方式还是监控告警,及时处理。