案例二：
一主多从的架构下，主库master宕机
解决思路：
1，登录从库
show processlist；
查看两个线程的更新状态
![wKioL1d46XXAm2LmAALthMC5r1I585.png]( "0003.png")
结果说明：
之前主从同步正常
分别登录其余2个从库32,33查看：
cat /data/3306/data/master.info
cat /data/3307/data/master.info
比较，那个POS最大，说明更接近主库，那么我们就选举此slave作为新的master。
或者利用半同步技术，直接选举实时同步了的这个库为新的master
如果，master down掉，此时master还在有写入，我们需要将master的binlog拉到新选中的slave，
进行数据补全，在把其他slave执行新选中的master，使其继续同步。
切换步骤以及注意事项：
1，确保所有的relay_log 全部更新完毕
在每个从库执行
stop slave io_thread；
show processlist；
直达看到Has read all relay log; 表示从库更新都执行完毕；
2，登录
新选举的master（也就是旧的一个slave），执行以下命令
stop slave;
reset master;
quit;
3,进入新选举的slave数据目录，删除master.info relay-log.info ，防止继续从旧的master读数据
cd /data/3306/data
rm -rf master.info relay-log.info
检查授权表，read-only 等参数，需要删除
4，提升次新选举的从库为主库
vim /data/3306/my.cnf
开启binlog：
log-bin = mysql-bin
如果存在以下参数，一定要删除
log-slave-updates
read-only
--replication-do-db
--replication-ignore-db
--replication-do-table
--replication-ignore-table
--replication-wild-do-table
--replication-wild-ignore-table
重启服务、提升主库完毕
5，如果主库服务器没宕，需要去主库拉去binlog，补全主库的从库
6，其他从库操作
检查（同步user，rep均存在，意思就是保证其他slave有权限连接新的master）
登录slave：
stop slave
change master to master_host='new_master_ip';如果不同步，就指定POS
start slave；
show slave status\G；
++++++++++++主库宕机切换成功
7，修改程序配置文件，将之前的masterIP更换为新的masterIP
重启服务
本文转自crazy_charles 51CTO博客，原文链接：http://blog.51cto.com/douya/1795367，如需转载请自行联系原作者
