共计 1185 个字符，预计需要花费 3 分钟才能阅读完成。
问题
咱们常常应用浮动 IP（SIP，或叫 VIP），来实现数据库的高可用部署。业务通过拜访浮动 IP，始终拜访主数据库。
如果业务正在拜访数据库时，数据库主从产生切换，导致 SIP 漂移，那正在应用的数据库连贯会受到影响么?
试验
咱们创立同子网的两台虚拟机，别离装置 MySQL。
再筹备一台额定的虚拟机，用来模仿业务，拜访数据库，此处省略装置过程。
这两台虚拟机的 IP 别离是 x.x.x.37 和 x.x.x.39，为了容易辨别，咱们设置 PS1，来辨别两个 linux 的会话。
下图以 37 为例，这里设置了 PS1，并确认机器上有创立好数据库，
39 与之相似：
咱们再选取一个 SIP: x.x.x.200，将其绑定到 37 上，
向子网进行 arp 宣告，告诉大家 ip 变更了：
当初业务机器上，测试一下拜访 SIP 胜利：
咱们在数据库中用 sysbench 灌入数据，此处省略步骤，只看后果：
而后向数据库执行一个 select，这里咱们用了一个 sleep，使得数据库返回后果集慢一些，大略每秒输入 1000 行左右：
执行 SQL 后，MySQL 客户端会不停输入后果，如果产生了任何连贯问题，咱们能够立即发现。
当初让 SIP 产生一次切换。筹备好如下命令：先在 37 上卸下 SIP，再在 39 上加上 SIP，发送 arp 宣告。
筹备好命令后，开始拼手速，让命令以很短的工夫先后执行。
执行后，会发现业务机上跑的 select 输入停了，会停很久当前，
咱们来看看这个景象的原理：
在 37 上，咱们能够找到这根连贯：
几十秒后，进入 FIN-WAIT-1 阶段，也就是说 37 曾经感知到这根连贯不太对，再 48 秒后，会敞开这根连贯：
而此时在业务机器上，这根连贯仍然存在，会在 116 分钟当前，探测 tcp keepalive 失败后，才感知到连贯出问题：
咱们试着将业务机的 tcp keepalive 距离调小一点，看看能不能让业务机更快感知到连贯出了问题：
再重做一下试验，会发现几秒钟后，MySQL client 就会感知到连贯出了问题：
咱们来抓个包看看：
重做试验，用 Wireshark 关上抓包后果：
能够看到 SIP 切换后，TCP Keepalive 包发往了交换机，但没有收到应答包。当超过 TCP Keepalive 的指定次数后，利用机器感知到了连贯谬误，发动了 RST 断开连接。
也就是说：当 SIP 产生切换时，旧连贯收回的包曾经被抛弃了，旧连贯会始终期待应答，所以须要 TCP keepalive 这种被动探测机制，才会探测到无应答的情况。
小贴士
当利用连贯到数据库时，倡议要配置 TCP keepalive 性能，并且距离要调小到业务能承受的范畴内。默认的 TCP keepalive 的距离是几小时能力感知故障。
然而：不要模拟试验中这样，调整操作系统级别的 TCP Keepalive 参数。应在利用建设连贯时将 TCP keepalive 参数配置在连贯级别。
对于 MySQL 的技术内容，你们还有什么想晓得的吗？连忙留言通知小编吧！
