mysqlfabric实现了对主从架构的一些常规维护功能。那mysqlfabric靠谱吗？会不会有什么Bug?我的同事们还是持怀疑态度的。
这里我将对mysqlfabric的基本运维的源码进行分析。
我们知道，mysqlfabric的常规运维有以下几个：
1.mysql的主从切换(有可能一主多从)。
mysqlfabric group my_group promote (这里假设group_id为: my_group)
2.mysql的主从切换，且指定某个从(slave)做为新的主(master)。
mysqlfabric group my_group promote --slave_id=xxx_server_id
3.把某个服务的状态修改为SPARE(闲置、备用)状态。
mysqlfabric server set_status xxx_server_id spare
这里我们以"mysqlfabric group my_group promote"这个方法为例进行分析，该方法的执行步骤如下(本来要画流程图，但发现很多步骤当中所调用的方法，都嵌套了四、五层以上，所以还是直接用文字来描述，同时把源码中的方法调用过程进行简单描述)：
1.从多个slave中找出可以成为新的master的最佳候选者(candidate)。
即_do_find_candidate方法：找出相比于master延迟最小的slave，成为master，即最佳侯选者。当然这个slave要满足：开启binlog, gtid,log_slave_updates。同时复制的slave status不能有出错信息。
2.校验最佳候选者是否满足成为新master的所有条件(注：上面的"2.mysql的主从切换，且指定某个从(slave)做为新的主(master)"实际上就是从这一步直接开始，即有指定slave_id时，就不需要执行获取最佳侯选者的步骤了)。
即_check_candidate_switch方法。
3.设置master为只读状态。
该步骤的方法调用过程：_block_write_switch---->_do_block_write_master(设置read_only,secondary,以及group的master_uuid为None)。
4.让候选者的数据追赶上master(就是我们常说的追数了~)。
该步骤的方法调用过程：_wait_slaves_switch---->_utils.synchronize(server, master)---->_replication.sync_slave_with_master(slave, master, timeout=0)---->wait_for_slave_gtid(slave, master_gtids, timeout)
5.让除了候选者之外的slave的数据追赶上master。
该步骤的方法调用过程：_wait_slaves_switch---->_do_wait_slaves_catch(group_id, master, [slave_uuid])---->_utils.synchronize(server, master)---->_replication.sync_slave_with_master(slave, master, timeout=0)---->wait_for_slave_gtid(slave, master_gtids, timeout)
6.主从切换。
即_change_to_candidate方法：(1.清空新主的复制属性，并设置为read_write 2.把其他的相关server重新指到新master)---->_utils.switch_master(server, master)(停slave，指向新master，设置slave为read_only，启动slave)---->_replication.switch_master(真正进行指向新master)
总结：fabric在数据库运维这端的逻辑控制还是比较完善，大家还是可以放心使用的。
但是mysql connector for java的sdk，那还是有很多坑的，各位在使用过程中要测试充分，小心使用哦。
本文出自 “nycle's blog” 博客，请务必保留此出处http://nycle.blog.51cto.com/1119720/1636020
原文：http://nycle.blog.51cto.com/1119720/1636020