Server_uuid of dual slave is the same

In the morning, we performed data migration. After deploying slave2, we found that the logs of the three machines were rampant:

Old 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

New 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)

This phenomenon should be caused by the same server-id that the master does not know which slave is. After multiple confirmation that the server-id is indeed different, the master will be very depressed.

Slave 1:

Slave 2:

In this case, the server_uuid is the same.

Yes, my migration is to stop the old slave and copy it to the new host. The result is auto. the uuid stored in cnf is still the uuid of slave1, resulting in the master nervous system disorder when applying for binlog from the master.

A more detailed explanation is as follows (Btw: This is an explanation on the Internet. I even moved it directly. If the original author has any infringement, please contact me :-)):

MySQL 5.6 uses the 128-bit server_uuid to replace most of the original 32-bit server_id functions. The reason is simple. server_id depends on the manual configuration of my. cnf, and conflicts may occur. The 128-bit uuid automatically generated algorithm ensures that all MySQL uuid does not conflict with each other. At the first startup, MySQL will call generate_server_uuid () to automatically generate a server_uuid and save it to the auto. cnf file. The only purpose of this file is to save server_uuid. When MySQL starts again, it reads the auto. cnf file and continues to use the last generated server_uuid. Run the SHOW command to view the server_uuid: show global variables like 'server _ uuid 'currently used by the MySQL instance. It is a globally unique server_uuid of MySQL 5.6 global variables: the MySQL Master/Slave replication exception caused by the server_id configuration conflict ends at MySQL 5.6. When Slave applies for binlog from the Master, it first sends its server_uuid, the Master uses server_uuid sent by Slave instead of server_id (the method before MySQL 5.6) as the parameter of kill_zombie_dump_threads to terminate the BINLOG_DUMP thread in conflict or dead state.

By linwaterbin

2014-05-29

Good Luck!