tikv 的3个PD 全部down了,一直拉不起来。

【 TiDB 使用环境】生产环境
【 TiDB 版本】V7.5.0
【复现路径】
当前使用的是TIKV 集群,是用tiup 部署的,集群状态如图:


集群一共6个节点,23, 24 , 25 和 37 , 38 , 39 ,其中前3个节点是4个SSD盘,后3个节点是4个NVME 硬盘。
今天早上发现TIKV 服务连不上了,发现3个PD 全部是down 的状体,具体时间未知。截取了一段时间的日志:23 节点的日志

后来重启过24节点,因为发现24节点的dmesg 有打印:


因此,修改了 /etc/security/limits.conf 和 /etc/sysctl.conf ,
然后尝试tiup cluster restart ,依然没用。PD还是down的起不来。

当前最新日志截图: 23节点上的PD日志

24节点上的PD 最新日志

25 节点上的PD 最新日志

看起来是一直在选举,但是选不出来。

【遇到的问题:问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件:截图/日志/监控】

最后的fatal日志发下?

目测是操作系统的问题
image

修改配置文件应该需要重启操作系统才能生效。

这个是指什么日志 ?

这个当前已经修改为500w 了。
同时也重启了这个节点。
image
但是还没恢复。

最好是三个节点都修改一下,另外重启服务器后注意检查防火墙是否开启,如果开启也会影响TiDB集群启动。

因为看最后的pd日志,24、25都提示连接不到23。

当前进展同步:
我们在6个节点上用iptables 禁了其他客户端访问2379 和2380 端口的请i去。
然后如下图

23 节点上的PD 打印:

24 节点上的tikv 打印:

因为我们是juicefs 服务,我们尝试去连, 发现依然客户端报找不到members

当前是静止,等待下看看情况。

同时10分钟前放开IPTABLES , 发现服务又全部down, tikv 变为NA 状体,这个也不知道为何。

整理了下今天的修复,
找其他大佬协助看了下,最后认为是客户端请求链接太多了,打爆了PD 。我们通过iptables 禁止测试,也验证了确实是 ,只要限制链接范围,服务就能自己逐步恢复。

当前通过这个方式逐步恢复了。
后续有问题,我再持续跟进。

1 个赞

集群一直都是开启 TLS 的?感觉可能和认证有关系

看了上面是网络原因导致的。你还是排查下3个pd节点之间网络通不通吧。

telnet xxx:2379

解决这个问题,您可以尝试以下几个步骤:

  • 检查链接:确保提供的链接是正确的,没有多余的字符或格式错误。
  • 检查网络连接:确保您的网络连接是稳定的,并且服务器是可达的。
  • 检查服务器状态:确认服务器上的服务正在运行,并且配置正确。
  • 检查防火墙和安全设置:确保没有防火墙或安全设置阻止您的请求

怎么查看是哪些服务导致的?如何限制

学习了,有点像DDOS攻击哈哈哈

排查下网络

是什么原因导致客户端链接这么多的啊?我看你fs.file-max已经设置成5百万了啊
是等待返回的进程太多还是同时访问太多 :joy: