记一次mysql连接池被冲垮的事故

本次是生产环境发布hotfix后，发现用户部分流量超时，运营群里炸锅，告警邮件爆仓。
问题发现
运营同学反馈系统部分不可用，排查后发现，是部分pod（项目是docker + k8s部署）节点mysql连接异常。

image.png

止血

1. 因为此前出现过相同情况，有一次发布hotfix，发现其中一个节点mysql连接失败，重启后全部节点正常

   
   
   image.png

但是此次重启多次却无法解决问题。

2. nacos下线问题节点，让两个pod硬抗
   发生问题背景
   发了一个hotfix，发布后出现该问题。
   排查问题
3. 回滚代码，重新发布，问题仍然存在，说明代码没有问题
4. 部分节点正常，说明容器网络环境正常
   前两步操作已经消耗二十多分钟，还是毫无头绪。

再次排查

1. nacos注册成功，有流量进入
   a. 注册正常，负载均衡流量进入正常

2. grafana面板pod在线数量先正常，后减少
   a. 日志采集开始时正常
   b. 后期采集失败，无法获取到在线状态

   
   
   image.png

3. 发现还会报出 IO error
   a. 那么grafna无法收到日志，有可能是因为IO error

4. 查看mse nacos上关于问题节点的流量情况，发现现有冲高流量，紧接着出现问题
   a. 那么有猜想，在mysql线程池还未初始化完成，服务已经开始接收流量
   b. 巨大的流量，占用大量CPU资源，mysql线程池初始化失败

5. 尝试增大nacos延迟注册时间，和小流量预热时间

问题解决
再次重启服务，发现所有pod启动成功

1. 下图中grafna上pod在线数量最低时为0（但nacos依然正常进行流量负载）。
2. 后来的拉高是滚动发布过程中，过度简短pod数多余设置数量

3. 延迟注册后，没有出现异常pod

   
   
   image.png

其他思考
为什么mysql连接池未初始化成功，就开始接收流量？

1. Prometheus提起上报了在线状态，表现为在grafana上pods数高于设置数
2. nacos 提前注册成功，开始接收负载流量