雙slave的server_uuid相同問題

早上做資料移轉，部署完slave2,發現3台機子的日誌狂刷：

舊slave：

2014-05-29 14:35:35 996 [Note] Slave: received end packet from server, apparent master shutdown: 2014-05-29 14:35:35 996 [Note] Slave I/O thread: Failed reading log event, reconnecting to retry, log 'mysql-bin.000005' at position 4072014-05-29 14:35:35 996 [Warning] Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommende

新slave：

2014-05-29 14:35:35 16770 [Note] Slave: received end packet from server, apparent master shutdown: 2014-05-29 14:35:35 16770 [Note] Slave I/O thread: Failed reading log event, reconnecting to retry, log 'mysql-bin.000005' at position 4072014-05-29 14:35:35 16770 [Warning] Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. 

master：

2014-05-29 14:35:35 8242 [Note] Start binlog_dump to master_thread_id(86182) slave_server(55), pos(mysql-bin.000005, 407)2014-05-29 14:35:35 8242 [Note] Start binlog_dump to master_thread_id(86183) slave_server(111), pos(mysql-bin.000005, 407)2014-05-29 14:35:35 8242 [Note] Start binlog_dump to master_thread_id(86184) slave_server(55), pos(mysql-bin.000005, 407)

這種現象應該是server-id相同導致master不知道哪個是slave，在多次確認server-id確實不一樣後陷入無比鬱悶當中。

slave 1：

slave 2：

這時有個新的發現：server_uuid 是相同。

沒錯，我的遷移是直接把舊的slave停掉，然後拷貝到新的機子上，結果 auto.cnf  裡面儲存的uuid 仍然是slave1 的uuid，導致在向master 申請binlog時master神經錯亂。

更加詳細的解釋如下(btw：這是網上的一段解釋，偶瞧著不錯直接搬過來，原作者如有侵權請聯絡我 :-))：

MySQL 5.6 用 128 位的 server_uuid 代替了原本的 32 位 server_id 的大部分功能。原因很簡單，server_id 依賴於 my.cnf 的手工配置，有可能產生衝突 —— 而自動產生 128 位 uuid 的演算法可以保證所有的 MySQL uuid 都不會衝突。在初次開機時 MySQL 會調用 generate_server_uuid() 自動產生一個 server_uuid，並且儲存到 auto.cnf 檔案 —— 這個檔案目前存在的唯一目的就是儲存 server_uuid。在 MySQL 再次啟動時會讀取 auto.cnf 檔案，繼續使用上次產生的 server_uuid。使用 SHOW 命令可以查看 MySQL 執行個體當前使用的 server_uuid：SHOW GLOBAL VARIABLES LIKE 'server_uuid';它是一個 MySQL 5.6 global variables全域唯一的 server_uuid 的一個好處是：可以解決由 server_id 配置衝突帶來的 MySQL 主備複製的異常終止在 MySQL 5.6，Slave 向 Master 申請 binlog 時，會首先發送自己的 server_uuid，Master 用 Slave 發送的 server_uuid 代替 server_id （MySQL 5.6 之前的方式）作為 kill_zombie_dump_threads 的參數，終止衝突或者僵死的 BINLOG_DUMP 線程。

By linwaterbin

2014-05-29

Good Luck！