A slave with the same server_uuid as this slave has connected to the master

Got fatal error 1236 from master when reading data from binary log: 'A slave with the same server_uuid as this slave has connected to the master;

mysql version 5.6.28 
system version  rhel 6.7

    在用虚拟机配置mysql一主两从的主从复制结构，发现当一台从库启动复制的时候。另一台的Slave_IO_Running: 就停止的奇怪现象

slave01> show slave status\G;
*************************** 1. row ***************************
               Slave_IO_State: 
                  Master_Host: 192.10.10.114
                  Master_User: rep
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000009
          Read_Master_Log_Pos: 3353
               Relay_Log_File: slave01-relay-bin.000003
                Relay_Log_Pos: 1257
        Relay_Master_Log_File: mysql-bin.000009
             Slave_IO_Running: No
            Slave_SQL_Running: Yes
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table:

slave02> show slave status\G;
*************************** 1. row ***************************
               Slave_IO_State: 
                  Master_Host: 192.10.10.115
                  Master_User: rep2
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000009
          Read_Master_Log_Pos: 3353
               Relay_Log_File: slave01-relay-bin.000003
                Relay_Log_Pos: 1257
        Relay_Master_Log_File: mysql-bin.000009
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table:


    继续检查报错，发现在有问题的slave上有以下报错

Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'A slave with the same server_uuid as this slave has connected to the master; the first event 'mysql-bin.000009' at 2379, the last event read from './mysql-bin.000009' at 3353, the last byte read from './mysql-bin.000009' at 3353.'

    报错的大概意思是说，Slave的server_uuid 有冲突，导致一主多从的主从复制有问题，随后登录主库检查，发现只有一个slave server_uuid

master> show slave hosts;
+-----------+------+------+-----------+--------------------------------------+
| Server_id | Host | Port | Master_id | Slave_UUID                           |
+-----------+------+------+-----------+--------------------------------------+
|         3 |      | 3306 |         1 | 0f2ace9a-19d8-11e6-bb61-000c29e122c4 |
+-----------+------+------+-----------+--------------------------------------+

登录分别登录两个从库检查auto.cnf,发现两个slave节点的server_uuid一致，到此问题大概已经确认了，由于第二个slave节点是虚拟机复制过来的，因此mysql目录下的auto.cnf也一起复制过来，导致两个slave节点auto.cnf内容相同

[root@slave01 ~]# more /usr/local/mysql/data/auto.cnf
[auto]
server-uuid=0f2ace9a-19d8-11e6-bb61-000c29e122c4

[root@slave02 ~]# more /usr/local/mysql4/data/auto.cnf
[auto]
server-uuid=0f2ace9a-19d8-11e6-bb61-000c29e122c4

在对auto.cnf进行备份后，尝试对其进行删除，然后重新启动mysql,
 MYSQL>start slave；

slave01> show slave status\G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.10.10.114
                  Master_User: rep
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000010
          Read_Master_Log_Pos: 220
               Relay_Log_File: slave01-relay-bin.000006
                Relay_Log_Pos: 383
        Relay_Master_Log_File: mysql-bin.000010
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
            
            
            
slave02> show slave status\G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.10.10.115
                  Master_User: rep2
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000010
          Read_Master_Log_Pos: 220
               Relay_Log_File: slave02-relay-bin.000006
                Relay_Log_Pos: 383
        Relay_Master_Log_File: mysql-bin.000010
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
                      
    重启后两个slave节点的复制都已经正常了，此时在主库上进行查询，两个不同的slave的server_uuid已经输出了

master> show slave hosts;
+-----------+------+------+-----------+--------------------------------------+
| Server_id | Host | Port | Master_id | Slave_UUID                           |
+-----------+------+------+-----------+--------------------------------------+
|         3 |      | 3306 |         1 | 7ca50dca-2125-11e6-ab00-000c29695898 |
|         2 |      | 3306 |         1 | 0f2ace9a-19d8-11e6-bb61-000c29e122c4 |
+-----------+------+------+-----------+--------------------------------------+

至此，故障解决到一个段落了。

那server_uuid是个啥东西？看下官方的解释

#######什么是 server_uuid
############################

从MySQL5.6开始，除了用户提供的一个server-id之外，服务器还生成了一个真正的UUID，这个是可作为全局，只读的变量server_uuid。

该auto.cnf文件具有类似于my.cnf或my.ini文件的文件的格式。在MySQL5.6，auto.cnf只有一个[auto]条目，包含一个server_uuid的设置和值;

该文件的内容类似如下：

[auto]
server_uuid=8a94f357-aab4-11df-86ab-c80aa9429562


注意事项 

该auto.cnf文件是在mysql启动后自动生成的;不必要尝试写入或修改此文件。

开使用MySQL 5.6复制的时候，master和slave知道彼此的的UUID。一个salve的UUID的值可以在SHOW SLAVE HOSTS的输出中可以看出。一旦在从库上START SLAVE已经执行，主库的UUID的值可在SHOW SLAVE STATUS有效的输出。


注意
执行STOP SLAVE或RESET SLAVE语句不重置在slave从库上所用主库的UUID。

在MySQL 5.6.5或更高版本，服务器的server_uuid也在GTIDs用于源自该服务器上的事务

从库启动时，,如果master的UUID等于其自身，Slave I/O线程产生一个错误并中止，除非设置--replicate-same-server-id选项。此外，如果任以下列条件为真,slave I/O线程生成警告：


不存在具有预期server_uuid的master主库。
master的server_uuid发生了变化，尽管没有CHANGE MASTER TO语句曾经被执行。

注意

即使MySQL中5.6加入了 server_uuid系统变量，也不会改变对每个M准备和运行MySQL复制的节点设置唯一--server-id 的要求。