双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 407
2014-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 407
2014-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！

转载于:http://blog.itpub.net/26515977/viewspace-1208280/