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前自己檢查，否則會引起腦裂。