问题描述：
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 连接（业务开发人员告知的），分别对应端口
43666、 43668、 43669、 43670、 43673、 43674。
当通过重启 148 机器上的 keepalived 服务来完成 vip 切换，从而达成 mysql 主备切换时，可以看到如下抓包信息：
如下为 158 上的 tcp 链接信息。
可以看到，上面出现了 10 个 rst ……，呃，先不管为什么多出来 4 个吧。
下面看一下 148 （原 mysql master）上来自 158 的连接信息。
从上面两个截图中，只能看到有两条 tcp 链路上出现了新的请求，并且因为重启了 keepalived 的原因，出现了 tcp 的重发。这两条 tcp 链路对应的端口分别为： 43673、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 来促使 mysq 主备切换这种方式对于实际应用场景是否有意义？！如果实际情况中真的出现类似于 keepalived 重启导致的 mysql 主从切换，那么由此导致的主从不一致将如何解决 ？！业务程序通过某种保活机制触发对当前 tcp 链路是否处于“半打开”状态的检测时间间隔多少比较合适？mysql 上的 wait_timeout 设置多少比较合适！？
      真正让人感到不安的是，仅通过重启 keepalived 来进行主备切换，无论是 mysql 侧还是业务侧，居然都不会收到 tcp 的 fin 或 rst ，而只会在业务层面有“动作”时才能发现 tcp 链路的问题，这种现象对类似 mysql 这种服务来说必然会造成一些问题。