MySQL主库切换那些事

最近连续经历了机架掉电和交换机挂掉,着实切了不少主库,虽然过程心惊胆跳,但是也算是上过战场,经过了实战演习,相信TEAM中的小伙伴们对于切主库已经可以驾轻就熟了。
MySQL的主库切换也属于DBA的一个基本技能,下面我们就来聊聊MySQL主库切换那些事。
正常切主库

首先我们说说正常情况下的主库切换,在这种情况下,我们有时间可以做计划慢慢进行切换,所以这种切换其实时流程化的操作。
我们先说一下技术层面的步骤:
1、挑选一台服务器作为新主库
可以是现有的slave,也可以是新扩容出来的slave,但是归根结底它的角色是slave
2、在new master上设置log-slave-update,用来记录中继的binlog。
3、交替使用slave start until 和 change master to命令,将现有结构从A-B 切换成A-B-C结构,即级联结构。
其中A=old master,B=new master,C=slaves
4、设定new master的read_only=OFF,保证新主库可写
5、建立old master和new master的双主结构,保证切换失败之后可以回退,并且数据一致。
需要注意的时auto_increment,如果有字段有这个属性,需要在old 和 new master上分别设置如下来规避自增冲突。

set global auto_increment_increment=2; set global auto_increment_offset=2; set session auto_increment_increment=2; set session auto_increment_offset=2; set global auto_increment_increment=2; set global auto_increment_offset=1; set session auto_increment_increment=2; set session auto_increment_offset=1;

6、改变写入目的到new master
可能是修改DNS,或者飘VIP,或者修改配置等等,这个步骤最好选择业务低峰期操作,能规避很多隐患
7、断掉双主
old master可以变成slave或者干掉whatever
我们在说说流程方面的步骤:
1、通知开发同学们我们做这个事情了。
2、做的过程中每个步骤需要第二名同事进行double check。
3、联系运维同学对new master进行测试,一定要测的就是路由。
【MySQL主库切换那些事】4、检查授权是否new master和old master一致。
5、检查参数是否new master和old master一致。
6、修改写入目的之前通知大家一声。
尤其是除业务之外的流程团队,比如NOC,或者故障管理组,或者变更管理组等等组织
7、修改写入目的之后联系业务同学check一下业务。
8、发个完成通知告诉大家可以洗洗睡了。
从上面我们可以看出,其实流程方面就2个事情“check”和“通知”,仅此而已。
正常切主库最常见的场景就是MySQL版本升级,需要对表结构进行大改或者需要修改表引擎等等,但是总体来说,基本都是顺顺利利搞定的居多。
紧急切主库

下面我们就来聊聊紧急切主库,这种情况一般发生在主库由于各种原因宕机的场景下,比如服务器挂了,机架掉电,路由宕机,硬盘,内存,cpu坏了等等情况。
在这种情况下,我们就要进行紧急切主库了,而在我们真正切换之前需要考虑清楚,我们要的究竟是服务的可用性,还是数据的一致性,这将决定我们后续操作步骤的不一样。
首先,对于互联网行业来说,服务的可用性要更高一些,我们需要更快速的将服务启动起来对外提供服务,所以在这种情况下,我们可以容忍一部分的数据存在不一致的可能性。
so,步骤如下:
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、需要指挥系统。
小业务可以单兵作战,大规模后,一定要并发处理,这个时候就需要一个调度人员来统一指挥。并且可以将业务、故障管理等等人员屏蔽在一线操作人员外面,减少风险
下面我们再说说如果是数据一致性比较重要的话应该怎么办。
1、首先确定一下实例的引擎时myisam还是innodb。
2、如果是innodb,那么在可以重启主库实例的情况下最好选择重启并等待auto recover,这样丢数据的风险最低。
3、如果是myisam,那么就只能进行主库切换了,因为myisam的表损坏之后的修表时间太不可控了,而且修好的几率也不高。
4、而在主库切换的时候,挑选new master,除了考虑性能之外,需要找到执行了主库binlog最多的一个slave作为new master,其他slave需要重发这段binlog。
5、最后,其他步骤和上面的没有多大区别了。
可以看出,在数据一致性的要求下,不太考虑时间成本。(注明的某银行有整套的IDC容灾就是不切就是这个原因)
自动化切主库

我们都活在一个自动化的时代中,这年头能自动化的都自动化了,那么切换主库可不可以呢? 自然是可以的了。
1、纯软件的有MMM,MHA。
2、带上VIP的可以用keepalived或者heartbeat。
3、玩硬件的可以用drbd,甚至上SAN。
4、更高级一点的,结合各种中间件来进行fail over。
其实,只要知道上面的原理,完全可以自己写一个,但是对于DBA来说,我们不能只知道自动化,而不知道真正的切换原理,这就本末倒置了,这也是为什么我最后才说自动化的原因。

以上就是想随便聊聊的主库切换那些事,希望所有的DBA们,都不需要半夜2点爬起来切主库。
转载于:https://www.cnblogs.com/billyxp/p/3468037.html

    推荐阅读