MySQL主库切换
版权声明：此文章转载自开源中国
如需转载请联系听云College团队成员阮小乙，邮箱：ruanqy#tingyun.com
最近连续几次机房变迁，着实切了不少主库但都用之前同事切主脚本，经过了实战演习，总感觉只依赖别人的东西永不会明白中间的坑以及本质原理的。所以尝试了几次纯手动切主，今天给大家分享下，手动切主的过程。
数据库切主分为正常切主、异常切主两种。
正常切主：
1、保证主动模式。即A->B(一主一从)或一主多从（A->B1,B2）#本次以一主多从讲
2、选择新主库（此次新主为B1），选取原则（个人认为都可任意一个从库即可，但注意第三步顺序）
3、需要注意的时auto_incremen，避免自增冲突
#新主主变更 localhost.(none)>set global auto_increment_increment=2; localhost.(none)>set global auto_increment_offset=2; localhost.(none)>set session auto_increment_increment=2; localhost.(none)>set session auto_increment_offset=2; #老主主变更 localhost.(none)>set global auto_increment_increment=2; localhost.(none)>set global auto_increment_offset=1; localhost.(none)>set session auto_increment_increment=2; localhost.(none)>set session auto_increment_offset=1;
4、对于新主B1首先需要打开bin-log，以及关闭read_only（线上读写分离，从库均将bin-log关闭了）先关闭实例再修改配置文件（踩过坑修改配置文件后，重启实例后配置文件被刷回去）
修改配置文件 my$port.cnf read_only = 0 log-slave-updates = 1
5、搭建A->B->C结构
B2:stop slave; B1:stop slave; B1:show slave status/G; 寻找B1现在同步A的位置点： Master_Log_File: mysql-bin.002258 Exec_Master_Log_Pos: 252972 B2：start slave until master_log_file='mysql-bin.002258',master_log_pos=252972; 以上操作就是为了保证B1与B2数据一致 B1:show master status/G; File: mysql-bin.000756 Position: 407579 B2:change master to master_host='B1',master_port=*,master_log_file= 'mysql-bin.000756',master_log_pos=407579,master_user='*',master_password='*'; 此时 ABC结构就搭建ok
6、搭建双主
为什么搭建双主呢？ 1、建立old master和new master的双主结构，保证切换失败之后可以回退，并且数据一致 2、保证双写保证数据完整性。 如何搭建： B1：show master status/G; File: mysql-bin.000756 Position: 432284 A:change master to master_host='B1',master_port=*,master_log_file= 'mysql-bin.000756',master_log_pos=432284,master_user='*',master_password='*';
7、改变写入目的到new master
可能是修改DNS，或者飘VIP，或者修改配置等等，这个步骤最好选择业务低峰期操作，能规避很多隐患
8、断双主
old master可以变成slave或者干掉whatever
异常切主（摘自http://www.tuicool.com/articles/MrQb22,老大的博客）：
下面我们就来聊聊紧急切主库，这种情况一般发生在主库由于各种原因宕机的场景下，比如服务器挂了，机架掉电，路由宕机，硬盘，内存，cpu坏了等等情况。
在这种情况下，我们就要进行紧急切主库了，而在我们真正切换之前需要考虑清楚，我们要的究竟是服务的可用性，还是数据的一致性，这将决定我们后续操作步骤的不一样。
首先，对于互联网行业来说，服务的可用性要更高一些，我们需要更快速的将服务启动起来对外提供服务，所以在这种情况下，我们可以容忍一部分的数据存在不一致的可能性。
1、找一台slave作为new master。
当然，这个前提是最少是1M1S结构，这样才有的可切，如果是1M的单点情况，那么除了祈祷服务器赶紧重启，就只有洗洗睡了
2、在new master上执行reset master。
这只是让我们后续的change操作更方便而已，注意 不需要更改log-slave-updates
3、在new master 设置 read_only=OFF，准许写入。
4、修改写入目的到new master， 最快速的恢复写入服务。
5、慢慢操作其他slave
change master to master_host="new master host", master_log_file="mysql-bin.000001",master_log_pos=107;
6、检查服务是否正常。
对于这话情况，如果一个端口还好办，如果超过10个端口，那么肯定避免不了手忙脚乱的情况， 再有心理素质的人也会被不停的报警和手机搞得心烦意乱。
针对这种情况，我来说说一些有用的经验。
1、监控覆盖要快、准、全。
我们必须第一时间知道出了问题，并且知道出了什么问题，涉及哪些业务，只有一个强健的报警系统才能让DBA在第一时间进行反映
2、尽早升级问题给领导。
领导的能量比我们想象的大的多，也许你在辛苦的切主库，领导一句话服务就降级了，主库切换也就不那么紧急了。要记住解决问题并不仅有技术手段
3、需要指挥系统
小业务可以单兵作战，大规模后，一定要并发处理，这个时候就需要一个调度人员来统一指挥。并且可以将业务、故障管理等等人员屏蔽在一线操作人员外面，减少风险
想阅读更多技术文章，请访问听云技术博客，访问听云官方网站感受更多应用性能优化魔力。
正文到此结束
热门推荐
相关文章
Loading...
![[HBLOG]公众号](http://www.liuhaihua.cn/img/qrcode_gzh.jpg)
