【原创】基于 Keepalived 作主备的 MySQL 在切换时遇到的问题

问题描述：
MySQL 基于 keepalived 实现主备切换，业务 A 和业务 B （其实 A 和 B 上跑的业务是相同的 ）同时使用 MySQL 作数据库查询。经过重启 keepalived 服务来测试 MySQL 主备切换后，可以为业务提供正常的服务。

问题现象：
测试人员发现 MySQL 主从切换以后，与业务 A 相关的 TCP 链接信息已经变动为新 TCP 链接，而与业务 B 相关的 TCP 链接信息仍旧未变化。

具体环境以下：
业务A：172.16.177.158
业务B：172.16.177.159

VIP：172.16.177.147
MySQL master：172.16.177.148
MySQL slave：172.16.177.149




在业务正常运行状态下，业务A 经过 VIP 与 MySQL master（148）创建 6 条 TCP 链接（业务开发人员告知的），分别对应端口
4366六、 4366八、 4366九、 43670、 4367三、 43674。

当经过重启 148 机器上的 keepalived 服务来完成 VIP 切换，从而达成 MySQL 主备切换时，能够看到以下抓包信息：

以下为 158 上的 TCP 连接信息。




能够看到，上面出现了 10 个 RST ……，呃，先无论为何多出来 4 个吧。

下面看一下 148 （原 MySQL master）上来自 158 的链接信息。



      从上面两个截图中，只能看到有两条 TCP 链路上出现了新的请求，而且由于重启了 keepalived 的缘由，出现了 TCP 的重发。这两条 TCP 链路对应的端口分别为： 4367三、43669。
这里重发请求的端口与 158 上的抓包中显示的一致。

再看一下 149 （原 MySQL slave）上来自 158 的链接信息。




能够看到这里也出现了 10 条 TCP 链路被 RST 。与上面的 10 条 TCP 连接是对应的。

综上，整个过程能够描述为：

• 最开始 158 与 148 创建了6条 OCS 业务的 TCP 链接；
• 在重启 keepalived 的时候，刚好使用端口 43673 和 43669 的 TCP 链接正在信令交互，而此时正处于 VIP 147 从 148 向 149 漂移的过程之中，此时这两条 TCP 链路上的请求会由于得不到任何回应而触发重传；
• 当 VIP 成功绑定到 149 上后，上述两条 TCP 链路上的重传请求会被 RST，而当其余 TCP 链路上有新的请求时，才会被 RST。被 RST 后，OSC 会从新创建 TCP 链接。

下面单独看下每条 TCP 链路的情况：

端口 43673 的 TCP 链路。

端口为 43669 的 TCP 链路。

端口为 43666 的 TCP 链路。

端口为 43674 的 TCP 链路。

端口为 43670 的 TCP 链路。

端口为 43668 的 TCP 链路。

端口为 43671 的 TCP 链路。

端口为 43665 的 TCP 链路。

端口为 43672 的 TCP 链路。

端口为 43667 的 TCP 链路。



上述现象在对于 159 上的业务来讲也是这样，再也不重复说明。

总结：
      上述问题的出现值得思考的地方有，经过重启 keepalived 来促使 MySQL 主备切换这种方式对于实际应用场景是否有意义？！若是实际状况中真的出现相似于 keepalived 重启致使的 MySQL 主从切换，那么由此致使的主从不一致将如何解决 ？！业务程序经过某种保活机制触发对当前 TCP 链路是否处于“半打开”状态的检测时间间隔多少比较合适？MySQL 上的 wait_timeout 设置多少比较合适！？
      真正让人感到不安的是，仅经过重启 keepalived 来进行主备切换，不管是 MySQL 侧仍是业务侧，竟然都不会收到 TCP 的 FIN 或 RST ，而只会在业务层面有“动做”时才能发现 TCP 链路的问题，这种现象对相似 MySQL 这种服务来讲必然会形成一些问题。