前言：（PS：前言是后来修改本文时加的）对于这篇文章，有博友提出了一些疑问和见解， 有了博友的关注，也促使我想把这套东西做的更实用、更安全。后来又经过思考，对脚本中一些条件和行为做了些改变。经过几次修改，现在终于敢说让小伙伴本使用这套东西了。
主要目的：
以双主结构配合keepalived解决MySQL主从结构中主库的单点故障；同时通过具体的查询语句提供更细粒度、更为真实的关于主库可用性的判断。
基本思路：
将DB1和DB2做成主动被动模式的双主结构：DB1主动、DB2被动，通过keepalived的VIP对外，将VIP设置成原DB1的IP，保证改造过程对代码透明
三个前提：
两台MySQL的配置文件里需要加上“log_slave_updates = 1”；
并且“备用机”通过“read_only”参数实现除root用户之外的只读特性；
分别在两个数据库创建test.test表，插入几条数据，供检测脚本使用。
正常时，VIP在DB1，通过keepalived调用脚本定期检查mysql服务可用性（通过一个低权限用户连接mysql服务器并执行一个简单查询，根据返回结果来判定mysql是否可用）
若无法执行查询：
1. 第一次检测失败后,检查服务状态,：
若服务异常，则执行切换：关闭DB1的keepalived，使VIP漂移至DB2，通过DB2上keepalived的notify_master机制，触发脚本将DB2的mysql从被动状态（只读）切换到主动状态（可读写），并发送通知邮件。
若服务正常（则可能是一些临时性因素导致的监测失败），等待30s做第二次检查，这30s是对瞬时/短时因素造成检查失败的容忍时间，本着“能不切则不切”的原则。若第二次检查仍然失败
2. 开始执行系列切换动作
将DB1的MySQL设置为 read_only模式 （阻止写请继续求进入）
kill掉当前客户端的线程。原来担心kill掉线程会对数据执行造成影响，后来查看了官方文档“mysql shutdown process”，发现mysql正常关闭过程也有一步是如此操作，所以这里可以放心了。然后 sleep 2，给kill命令一些时间（关于kill命令的机制，参考官方解释）
关闭DB1的keepalived，使DB2接管VIP。通过DB2上keepalived的notify_master机制，触发脚本将DB2的
mysql从被动状态（只读）切换到主动状态（可读写），并发送通知邮件。
3. 管理员修复DB1后，通过脚本“change_to_backup.sh”将主库切换回DB1。脚本思路如下：
注：涉及到切换主备，就会有中断时间，所以推荐此步骤在业务低谷期执行
将DB2的read_only属性置为1
kill掉DB2上的client线程，并重启DB2的keepalived使VIP漂移至DB1
确定DB1跟上了DB2的更新，并将DB1上的read_only属性移除
关于“数据一致性”和“切换时间”：
连续两次失败以后，通过对主MySQL设置read_only属性，同时kill掉用户线程来保证在DB2接管服务之前，DB1上已经没有写操作，避免主从数据不一致。并且切换时间基本上是可确定的：
30s（两次检测间隔）+2s（等待kill命令时间）+约1s（keepalived 切换VIP），总时间不会超过35s。
以上是大致思路，具体实现看过下面的脚本，就会一目了然了。
DB1上keepalived 配置
! Configuration File for keepalived
vrrp_script chk_mysql {
script "/etc/keepalived/check_mysql.sh"
interval 30 #这里我的检查间隔设置的比较长，因为我们数据库前面有redis做缓存，数据库一两分钟级别的中断对整体可用性影响不大。这也是我没有采用成熟的方案而自己搞了这一套方案的“定心丸”
}
vrrp_instance VI_1 {
state BACKUP #通过下面的priority来区分MASTER和BACKUP，也只有如此，底下的nopreempt才有效
interface em2
virtual_router_id 51
priority 100
advert_int 1
nopreempt #防止切换到从库后，主keepalived恢复后自动切换回主库
authentication {
auth_type PASS
auth_pass 1111
}
track_script {
chk_mysql
}
virtual_ipaddress {
192.168.1.5/24
}
}