【 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节点规划其实并不不是高可用
要求不一样嘛 
也算高可用，因为数据没丢失，很容易恢复，继续提供服务
scale-out pd集群的原理就是把一个新节点 join-in 到原有集群中，我是真怀疑这种状态下还能成功，我会测试下。
至于用pd-recover 恢复这个就更谈不上高可用了。
我觉得你这个解释可能还是有点问题
pd 三节点只是宕机一个，又不是宕机了两个节点,为啥会不满足选举条件呢
没事，实践出真知～ 
有没有哪位官方的小伙伴出来给解答下 
pd节点端口还存在的话，不影响节点之间心跳。就不能被认为宕掉了
ETCD 默认是 raft 协议，Raft协议 只支持奇数位的实例来完成选举操作
至于为啥 raft 是这样的，你可以自行查阅相关的资料
这个和我们推测的结果差不多，觉得这个说法还是比较靠谱。
那现在问题就是 pd是不是要多加一些条件做自身可用性的判断，及时让出leader 位置，毕竟这个时候还是两个节点可用， 也就是说多数派可能是正常。 如果切换leader成功，集群是可以正常服务的，恢复速度会更快吧
你这种情况，是否可以认为数据库盘写满了，但是网络间端口心跳还在，无法触发 leader election ,需要手动干预。
也可以查下日志。是否有 leader election， 确定是没触发选举 还是选举不成功。
磁盘满，网络心跳还在，不能认为是宕机，最好的方式还是监控告警，及时处理。
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。