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进行测试，一定要测的就是路由。

　　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点爬起来切主库。