1、问题：
MySQL从库中查看主从状态： show slave status\G,发现出现IO的报错：
Last_IO_Errno: 1236 Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'A slave with the same server_uuid/server_id as this slave has connected to the master; the first event 'mysql-bin.001878' at 874478273, the last event read from './mysql-bin.001878' at 878264052, the last byte read from './mysql-bin.001878' at 878264052.'
2、背景:
这边有一台MySQL 服务器，有1,2，3 三个从库.第一天晚上 3 号从库用于其他数据库恢复操作，所以删掉了，只删掉了数据。 第二天晚上，我用 2 号从库对 3 号从库进行了恢复，步骤是停掉2号从库的slave 进程，然后关库，然后将2号从库data下的 所有数据全部cp 到了3号从库的data下，修改权限，然后重新启动了2台从库，可以正常启动。 问题是，我启动2号从库的slave进程，3号从库的slave IO进程就会断掉，我启动3号从库的slave 进程，2号就会断掉。这个是哪里的原因？
3、处理思路
首先想到的是server_id 的问题，然后我对两台从库的server_id 进行了排查，发现server_id 是不同的，没有问题。 然后根据 Last_IO_Errno 的报错信息很清楚的发现：
A slave with the same server_uuid/server_id as this slave has connected to the master 意思是：与此从机具有相同server_uuid / server_id的从机已连接到主机。也就是说，问题就出在了server_uuid上。 查看两边的 server_uuid，发现果然是一样的！
2号从库：
3号从库：
果断修改MySQL datadir 目录下的auto.cnf 文件中uuid,我的理解是只要与其他从库不一样就行。
修改完成之后重启MySQL 服务。
service mysqld stop;
service musqld start;
进入数据库启动slave 进程 然后查看各个从库的状态，发现IO 进程恢复正常。
4、对server_uuid 的解释（网络资料）：
由于恢复是直接把2号的slave停掉，然后直接cp到新的机子上，所以 auto.cnf 里面保存的uuid 仍然是2号从库的uuid， 导致从库在向master 申请binlog时master出错，导致从库IO进程断开。 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 线程。
