【 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) 截图此页面
【附件:截图/日志/监控】
这个当前已经修改为500w 了。
同时也重启了这个节点。
但是还没恢复。
Kongdom
(Kongdom)
7
最好是三个节点都修改一下,另外重启服务器后注意检查防火墙是否开启,如果开启也会影响TiDB集群启动。
因为看最后的pd日志,24、25都提示连接不到23。
当前进展同步:
我们在6个节点上用iptables 禁了其他客户端访问2379 和2380 端口的请i去。
然后如下图
23 节点上的PD 打印:
24 节点上的tikv 打印:
因为我们是juicefs 服务,我们尝试去连, 发现依然客户端报找不到members
当前是静止,等待下看看情况。
同时10分钟前放开IPTABLES , 发现服务又全部down, tikv 变为NA 状体,这个也不知道为何。
整理了下今天的修复,
找其他大佬协助看了下,最后认为是客户端请求链接太多了,打爆了PD 。我们通过iptables 禁止测试,也验证了确实是 ,只要限制链接范围,服务就能自己逐步恢复。
当前通过这个方式逐步恢复了。
后续有问题,我再持续跟进。
1 个赞
nobody
(不定时出现)
10
集群一直都是开启 TLS 的?感觉可能和认证有关系
看了上面是网络原因导致的。你还是排查下3个pd节点之间网络通不通吧。
telnet xxx:2379
是什么原因导致客户端链接这么多的啊?我看你fs.file-max已经设置成5百万了啊
是等待返回的进程太多还是同时访问太多