上图显示说明在客户端访问 VIP 地址，由 master1 主机提供响应的，因为 master1 当前是主
服务器，将 master1 的 mysql 服务停止，在客户端执行 show variables like‘server_id’;
上图显示说明在客户端的查询请求是由 master2 主机响应的。故障切换成功。
总结：
Keepalived+mysql 双主一般来说，中小型规模的时候，采用这种架构是最省事的。
在 master 节点发生故障后，利用 keepalived 的高可用机制实现快速切换到备用节点。
在这个方案里，有几个需要注意的地方：
1.采用 keepalived 作为高可用方案时，两个节点最好都设置成 BACKUP模式，避免因为意外
情况下（比如 脑裂）相互抢占导致往两个节点写入相同数据而引发冲突；
2.把两个节点的 auto_increment_increment（自增步长）和 auto_increment_offset（自增起
始值）设成不同值。其目的是为了避免 master 节点意外宕机时，可能会有部分 binlog 未能
及时复制到slave上被应用，从而会导致slave新写入数据的自增值和原先master上冲突了，
因此一开始就使其错开；当然了，如果有合适的容错机制能解决主从自增 ID 冲突的话，也
可以不这么做；
3.slave 节点服务器配置不要太差，否则更容易导致复制延迟。作为热备节点的 slave 服务器，
硬件配置不能低于 master 节点；
4.如果对延迟问题很敏感的话，可考虑使用 MariaDB 分支版本，或者直接上线 MySQL 5.7 最
新版本，利用多线程复制的方式可以很大程度降低复制延迟；
谢谢观看，真心的希望能帮到您！