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，那还是有很多坑的，各位在使用过程中要测试充分，小心使用哦。