做实验怎么提高成功率？
1. 保持和文档里面的东西一样
2. 学会看日志 ＃看日志是让我们学会思考；将debug模式找开，打开方式baidu里面找；
3. 学会总结
举一反三，总结过程，创造新东西
------------------------------------------------------------
keepalived+双主环境搭建
yum install keepalived
yum -y install MySQL-python
keepalived的两台机器上都要装的
markdown 格式,学习一下;
/etc/keepalived/keepalived.conf
/etc/keepalived/checkMySQL.py -h 127.0.0.1 -P 3306
echo "/usr/local/mysql/lib" >> /etc/ld.so.conf.d/mysql-x86_64.conf
ldconfig
libmysqlclient.so.16 no such file
libmysqlclient.so.18
cd /usr/local/mysql/lib
ln -s libmysqlclient.so.18 libmysqlclient.so.16
ldconfig
主：
keepalived.conf
vrrp_script vs_mysql_82 {
script "/etc/keepalived/checkMySQL.py -h 127.0.0.1 -P 3306"
interval 60 ##建议是15s以上，表示间隔多长时间作一下检查；
}
vrrp_instance VI_82 {
state BACKUP
nopreempt
interface eth0
virtual_router_id 82
priority 100
advert_int 5
authentication {
auth_type PASS
auth_pass 1111 ＃＃＃最多只支持8位
}
track_script {
vs_mysql_82 ##特别注意： virtual_router_id 82 0-255
}
virtual_ipaddress {
192.168.11.100
}
}
多实例 每个一组vip
keepalived有几种状态呢？master/backup/fault
vrrp_script vs_mysql_82 {
script "/etc/keepalived/checkMySQL.py -h 127.0.0.1 -P 3306"
interval 60
}
vrrp_instance VI_82 {
state BACKUP
nopreempt
interface eth0
virtual_router_id 82
priority 100
advert_int 5
authentication {
auth_type PASS
auth_pass 1111
}
track_script {
vs_mysql_82
}
virtual_ipaddress {
192.168.11.100
}
}
你希望VIP在那台机器上，就在那台机器上先启动KEEPALIVED
确定VIP绑定成功
checkMySQL.py脑裂的问题没有处理：
脑裂：假设Keepalived里两台机器A,B，A有VIP，B有可能会认为A死掉了，B也会接管VIP
A和B上面都有VIP了？
现在如果网络Ok了，谁的VIP生效？
这个是谁最后更新arp列表成功，谁生效。一般是第二个抢占的，会占用vip,可以ssh vip试试
通常是防火墙开着导致的；
chkconfig --list|grep on
chkconfig iptables off
建议大家把iptables 关掉
iptables , selinux 都是关掉的
vi /etc/sysconfig/selinux
修改/etc/selinux/config 文件
将SELINUX=enforcing改为SELINUX=disabled
什么样的场景会出现脑裂，以及应对？
1,vrrp通信中断 ＃＃这个是防火墙策略的问题；两台机器一个交换机下面
2,网络中断
vrrp_script vs_mysql_82 {
script "/etc/keepalived/checkMySQL.py -h 127.0.0.1 -P 3306"
interval 60
}
在这个脚本里加一个ping 网关；Return 0
观查一下keepalived的启动及切换日志
tail -f /var/log/message
keepalived ＃主进程
healtcheck ＃调用脚本的进程
VRRP ＃vrrp协议
都配置成backup，别搞成master ,
2. 如果state配置的BACKUP，则直接进入BACKUP状态，如果在不存在Master的情况下，执行track_script,成功进入Master,失败进入FAULT; 在存在MASTER的情况下，保持在BACKUP状态。
其中都是BACKUP配置是，会比较priority的大小，同时启动时，较大的prority，会成为首选的Master.
我们这里的 priority是一样的，谁先启动谁用master;
3. FAULT状态是，试图进入Master没成功时才会进入Fault状态。[所以也能解释： 为什么BACKUP在存在Master的时，只会进入BACKUP状态]，在FAULT状时不会接管VIP。
4. Keepalived正常退出，会进入stop state,提前会把VIP释放掉，如果keepalived补Kill掉，那么VIP不会被释放。
ip addr show
因此在脚本里最好不用写kill `pidof keepalived`
VIP管理的特性
keepalived管理lvs;
lvs: Linux Virtual Server
LVS是Linux Virtual Server的简写，意即Linux虚拟服务器，是一个虚拟的服务器集群系统。本项目在1998年5月由章文嵩博士成立，是中国国内最早出现的自由软件项目之一。目前有三种IP负载均衡技术（VS/NAT、VS/TUN和VS/DR），十种调度算法（rrr|wrr|lc|wlc|lblc|lblcr|dh|sh|sed|nq）。
章博士去滴滴了。
想在挂几个Slave怎么来操作呢?
基于GTID+keepalived
一种是把Slave挂到非VIP的Master上
另一种是把Slave挂到VIP上同步
传统复制，slave是挂在m2上，为什么不能挂在vip 上,因为binlog不一样；
如果m1挂掉的话，vip会到m2上，还能再切换吗？M1 加回来要会成什么样的结构？
纟
怎么变到这个过程呢？
观查Sql_thread执行到什么位置用两个变量？
relay_master_log_file,exec_master_log_pos
show master status; 还会变呢
m1,s1,s2 的数据还会有变化吗？ 应该是不会变的；
stop slave;
set global sql_slave_skip_counter=1;
start slave;
如果需要挂两个从库，可以挂呢，为什么
s1. stop slave;
change master to master_host=m2, ... auto_position=1;
start slave;
在GTID模型下，还需配置双主吗？
KEEPALIVED+GTID 还需要配置成双主吗
start slave;
change master to master_host=m2, ... auto_position=1;
在传统复制里要配置成双主
在传统复制如果不想配置双主有没有办法做这件事呢
在接管VIP之前，做一个show master status; 并记录下来
notify_master /path/get_master_pos.sh
echo "show master status"|mysql -h127.0.0.1 -P3307 -uroot -pxxxx
echo "show master status"|mysql -h127.0.0.1 -P3307 -uroot -pxxxx
>/path/`date %xxxx `.
notify_master
notify_backup
notify_fault
从库怎么做一个高可用呢？
#Keepalived 启动及STATE转换分析
>这里讨论一下keepalived启动及关闭是状态转换及相应的脚本执行
******
***Keepalived启动后状态依赖于 keepalived.conf中配置的state, 下面分别说明***
1. 当state配置是的master状态时，先执行track_script， keepalived试图进入Master状态，参考track_script返回的结果,如果返回成功，则为Master状态，如果失败，进入FAULT状态
Oct 15 17:15:14 node78 Keepalived[7699]: Starting Keepalived v1.2.7 (12/20,2012)
Oct 15 17:15:14 node78 Keepalived[7700]: Starting Healthcheck child process, pid=7701
Oct 15 17:15:14 node78 Keepalived[7699]: Starting Keepalived v1.2.7 (12/20,2012)
Oct 15 17:15:14 node78 Keepalived[7700]: Starting Healthcheck child process, pid=7701
Oct 15 17:15:14 node78 Keepalived[7700]: Starting VRRP child process, pid=7702
....
Oct 15 17:15:14 node78 Keepalived_healthcheckers[7701]: Configuration is using : 4685 Bytes
Oct 15 17:15:14 node78 Keepalived_healthcheckers[7701]: Using LinkWatch kernel netlink reflector...
Oct 15 17:15:14 node78 root: Failed:redis-cli -h 127.0.0.1 -p 6680 PING
Oct 15 17:15:14 node78 Keepalived_vrrp[7702]: VRRP_Instance(redis1) Transition to MASTER STATE
Oct 15 17:15:15 node78 Keepalived_vrrp[7702]: VRRP_Instance(redis1) Entering FAULT STATE
Oct 15 17:15:15 node78 Keepalived_vrrp[7702]: VRRP_Instance(redis1) Now in FAULT state
Oct 15 17:15:15 node78 root: From notify: INSTANCE redis1 FAULT 90
如果有兄弟在Master状态，track_script返回成功，则接管Master状态，原来的进入BACKUP状态。（线上为两者为BACKUP状态）
2. 如果state配置的BACKUP，则直接进入BACKUP状态，如果在不存在Master的情况下，执行track_script,成功进入Master,失败进入FAULT; 在存在MASTER的情况下，保持在BACKUP状态。
其中都是BACKUP配置是，会比较priority的大小，同时启动时，较大的prority，会成为首选的Master.
3. FAULT状态是，试图进入Master没成功时才会进入Fault状态。[所以也能解释： 为什么BACKUP在存在Master的时，只会进入BACKUP状态]，在FAULT状时不会接管VIP。
4. Keepalived正常退出，会进入stop state,提前会把VIP释放掉，如果keepalived补Kill掉，那么VIP不会被释放。
##总结
对于Keepalived双方都是配置的state ***BACKUP***状态的情况下，不能适用于对于数据有持久化要求的场景（原因先启动Redis在启动Keepalived都需要先执行一个notify_backup脚本）
场景1： 指定主从启动 RedisA->RedisB
启动Redis A上Keepalived的进入BACKUP状态，执行notify_backup, 变为RedisB的从
启动Redis B上keepalived的进入BACKUP状态，执行notfiy_backup，变为Redis A的从
Note: 这个阶段很有可能出现互为主从的结构，然后Redis不响应写，响应读也很慢，任何命令都会很慢，大的量的访问有可能会挂掉。
直致最终两者出现一个升级为master ,执行notify_master
避免方法：
在Redis双方都挂掉，或是都重新启动时，先起动一个节点，保证第一个节起为Master状态，VIP接管成功后，再起另一个状态。
场景2： 双方起动后两边都有VIP，但主从关系正常
原因： 一方的keepalived被kill掉后，另一方起动keepalived，接管了vip,但原来的VIP没释放，故障的keepalived启动后，进入backup状态VIP没清理造成的。但通信上，应该是以接管的为主。
处理办法：确定KEEPALIVED相应的INSTANCE的状态后，手工释放那个无效的VIP。
场景3：两边都有VIP，主从关系不正常）
原因：
Master/Slave网络有问题，双方联系不上对方了，各自认为是自已是主了。
如原来的BACKUP和MASTER网络之间有问题，BACKUP接收到MASTER发来的通知包时，BACKUP就会升级新的主服务器。 这样就出现了两边都有VIP，STATE都MASTER的状态。
企望这种情况下保持不动：
处理办法：
在MASTER状态下，vrrp_script只检测自已的监管的进程（Redis）是否存在或是INFO输出是否正常。
在Slave状态下,vrrp_script要做两个检测：
自已的网络是否正常 依赖是不是能PING通网关
在检测是监管的进程是不是正常
全OK，exit 0具备进入Master状态，如果任一不OK，exit 1在期望接管理时，会进入FAULT状态
场景4： FAULT->MASTER的过程
在配置为state BACKUP下，当keepalived满足从FAULT进入MASTER时(vrrp_script返回成功），KEEPALIVED会先进入BACKUP状态，执行notfiy_backukp,然后在进入MASTER状态。
作业：
完成keepalived+双主
扩展 LVS做从库负载
ＭＨＡ环境搭建；
