数据库切换了，业务之前一直连接的都是主库，怎么让业务连接备库呢？
- 业务切换到新的地址，也就是业务应用配置文件修改一下新的主库
- 使用内部dns，通过域名连接，一般公司都用CoreDNS框架搭建内部的映射，有对应的域名配置对应的IP解析，所以改的话只改域名映射配置就可以了。这样的好处是项目的配置文件永远不需要改配置文件，只需要改DNS服务器的配置
- 使用keeppalived进行自动VIP漂移，也就是相当于心跳检测mysql服务器是否挂掉，它会自动切换保证随时有新的顶上去，也就自动实现了主从切换；也可以自动执行切换脚本，比如检测出主库挂了，不仅仅可以漂移VIP，也可以自动执行一个脚本，这个脚本是可以自定义，实现想要的功能，比如实现主只读，把备库可以写等等。
- 使用代理，如HaProxy
- MHA，高可用首选！结合DBLE可以实现负载！
MHA
MHA支持GTID，可以在binlog来不及传送时会尝试登录主库传送binlog到从库。当主库还没来得及把binlog传送给从库的时候，MHA会登录主库把没传送的binlog传送出去，但MHA不支持想keepalived一样漂移VIP，但是配合DBLE就可以了。
原理
MHA支持GTID，可以在binlog来不及传送时会尝试登录主库传送binlog到从库。当主库还没来得及把binlog传送给从库的时候，MHA会登录主库把没传送的binlog传送出去，但MHA不支持想keepalived一样漂移VIP，但是配合DBLE就可以了。
从下图来看，一主两从，一般从生产来看，都会架设两个从库一个主库，其次MHA作为中间件的服务器，并且每个Mysql服务器都安装一个MHA组件（MHA node脚本）
假如mysql的主库挂了，这个时候从库连接不上主库，MHA会登录Mysql主库抢救为传送出来的binlog，也就完成了第一步。有人好奇了，假如开了binlog的半同步复制的话，是不是就没有未传送的binlog，理论上至少是这样，但是binlog传送过长可能会中断变成异步binlog传送，如果用主库宕机了，手动切换，很可能抢救不了主库遗留的binlog，但是binlog还没有复制到从库。
等待从库执行中继日志追赶master，也就是MHA使用的是可靠性策略，追上之后然后 MHA会在从库执行从主库抢救出来的binlog，那么保证了主从的一致，完成了第二步。
然后提升一个从库为主库，这时候另一个从库会从一个新提升的主库复制数据，到这一步MHA的工作就完成了，可以退休了。
这个时候MHA就完成了一波周期工作，接下来还需要人工修复，把之前宕机的主库改为从库，等待下一波的容灾。