MySQL连接为什么挂死了及解决方案有哪些？[图]

一、背景
近期测试反馈关于系统可靠性测试提出的问题令人感到头疼，一来这类问题有时候属于“偶发”现象，难以在环境上快速复现；二来则是可靠性问题的定位链条有时候变得很长，极端情况下可能要从A服务追踪到Z服务，或者是从应用代码追溯到硬件层面。
架构
首先，系统以MySQL作为主要的数据存储部件。整一个是典型的微服务架构（SpringBoot+SpringCloud），持久层则采用了如下几个组件：
mybatis，实现SQL<->Method的映射
hikaricp，实现数据库连接池
mariadb-java-client，实现JDBC驱动
在MySQL服务端部分，后端采用了双主架构，前端以keepalived结合浮动IP（VIP）做一层高可用。如下：
说明
MySQL部署两台实例，设定为互为主备的关系。
为每台MySQL实例部署一个keepalived进程，由keepalived提供VIP高可用的故障切换。
实际上，keepalived和MySQL都实现了容器化，而VIP端口则映射到VM上的nodePort服务端口上。
业务服务一律使用VIP进行数据库访问。

Keepalived是基于VRRP协议实现了路由层转换的，在同一时刻，VIP只会指向其中的一个虚拟机（master）。当主节点发生故障时，其他的keepalived会检测到问题并重新选举出新的master，此后VIP将切换到另一个可用的MySQL实例节点上。这样一来，MySQL数据库就拥有了基础的高可用能力。
另外一点，Keepalived还会对MySQL实例进行定时的健康检查，一旦发现MySQL实例不可用会将自身进程杀死，进而再触发VIP的切换动作。
问题现象
持续以较小的压力向业务服务发起访问，随后将其中一台MySQL的容器实例(master)重启。按照原