MySQL Utilities 高可用工具体验 MySQL Utilities 高可用工具体验

MySQL Utilities是MySQL官方的工具集，其中包括高可用相关的几个工具。 以下是对当前最新版本1.6的使用体验。

MySQL Server 5.6+

基于GTID的复制

Python 2.6+

Connector/Python 2.0+

在1台机器准备3个不同端口的MySQL实例用于测试

192.168.107.211:9001(master)

192.168.107.211:9002(slave1)

192.168.107.211:9003(slave2)

OS: CentOS 7.1

MySQL: Percona Server 5.7.19

Python： 2.7.5

Connector/Python：2.1.7

mysql-utilities：1.6.5

生成实例1的配置文件my1.cnf

创建MySQL实例

除去各种检查，mysqlreplicate真正做的事很简单。如下

先在master上创建复制账号

mysqlreplicate会为每个Slave创建一个复制账号，除非通过以下SQL发现该账号已经存在。

然后在slave上设置复制

在启用GTID的情况的下，从哪儿开始复制完全由GTID决定，所以mysqlreplicate中的那些和复制起始位点相关的参数，比如-b，统统被无视,其效果相当于-b。

注意:mysqlreplicate不会理会当前的复制拓扑，所以如果把master和slave对调再执行一次，就变成主主复制了。

slave1的复制配置好后，用同样的方法配置slave2的复制

mysqlrplshow通过在master上执行SHOW SLAVE HOSTS发现初步的复制拓扑。 由于Slave停止复制或改变复制源时不能立刻反应到master的SHOW SLAVE HOSTS上，所以初步获取的复制拓扑可能存在冗余， 因此，mysqlrplshow还会再连到slave上执行SHOW SLAVE STATUS进行确认。

然而，elect只是从slaves中选出第一个合格的slave，并不考虑复制是否已停止，以及哪个节点的日志更全。

下面把slave1的复制停掉

再在master执行一条SQL

现在slave1上少了一个事务

但elect仍然会选slave1

switchover会连接到每一个节点并等待所有slave回放完日志才执行切换，因此有任何一个节点故障或任何一个slave复制故障都不会执行switchover。

启动刚才停掉的slave1的复制

再次执行switchover，成功

执行switchover时，有一段Waiting for slaves to catch up to old master.，如果任何一个slave有故障无法同步到和master相同的状态，switchover会失败。即switchover的前提条件是所有节点（包括master和所有salve）都是OK的。

failover时要求所有slave的SQL线程都是正常的，IO线程可以停止或异常。 如果未指定--candidates，一般会以slaves中第1个slave作为新主。 如果新主的binlog不是最新的，会先向拥有最新日志的slave复制，并等到binlog追平了再切换。

从上面操作过程来看，借助MySQL Utilities管理MySQL集群还比较简便，但结合代码考虑到各种场景，这套工具和MHA比起来还不够严谨。

没有把从库的READ_ONLY设置集成到脚本里

switchover时没有终止运行中的事务，实际也没有有效的手段阻止新的写事务在旧master上执行。

failover不检查master死活，需要DBA在调用failover前自己检查，否则会引起脑裂。