May 25 14:37:09 master1 Keepalived_vrrp[3165]: VRRP_Instance(VI_1) Entering BACKUP STATE May 25 14:37:09 master1 Keepalived_vrrp[3165]: VRRP sockpool: [ifindex(2), proto(112), unicast(0), fd(10,11)] May 25 14:37:50 master1 Keepalived_vrrp[3165]: VRRP_Instance(VI_1) Now in FAULT state
2. 在Keepalived中有两种模式，分别是master->backup模式和backup->backup模式，这两种模式有什么区别呢？
在master->backup模式下，一旦主库宕掉，虚拟IP会自动漂移到从库，当主库修复后，keepalived启动后，还会把虚拟IP抢过来，即使你设置nopreempt（不抢占）的方式抢占IP的动作也会发生。在backup->backup模式下，当主库宕掉后虚拟IP会自动漂移到从库上，当原主恢复之后重启keepalived服务，并不会抢占新主的虚拟IP，即使是优先级高于从库的优先级别，也不会抢占IP。为了减少IP的漂移次数，生产中我们通常是把修复好的主库当做新主库的备库。
3. 本文是在MySQL主库高可用 -- 双主单活故障自动切换方案 基础上，结合自己对于MySQL的理解整理的。原文的脚本直接执行有点问题，思路有有点瑕疵，于是结合自己的实际环境，重新修改了一把。
4. 在测试的过程中，有以下几点需要注意：
1> master1检测脚本的逻辑是如果MySQL的服务不可用，则通过service keepalived stop命令来关闭keepalived，但在实际测试的过程中，却出现了即便执行了service keepalived stop命令，keepalived进程依然没有停止，导致MySQL的服务虽然不可用了，但VIP并不没有漂移到master2上。
优化方案：在执行service keepalived stop后，等待5s，再次检测keepalived的状态，如果keepalived没有关闭，则直接kill掉。
2> keepalived的日志默认是输出到/var/log/messages中，这样不便于查看。如何自定义keepalived的日志输出文件呢？
如果是用service启动的，修改/etc/sysconfig/keepalived文件
KEEPALIVED_OPTIONS="-D -d -S 0"
如果不是，则启动的时候指定以上参数，如：
/usr/local/keepalived/sbin/keepalived -d -D -S 0
修改/etc/syslog.conf
# keepalived -S 0 local0.* /var/log/keepalived.log
重启syslog
RHEL 5&6��service syslog restart
RHEL 7：service rsyslog restart