1、通过CP数据文件的方式恢复MySQL 从库 启动后报错：Last_IO_Errno: 1236：A slave with the same server_uuid/server_id as thi...

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 线程。

 

 

 

 

 

 

 

 

 

 

 

 

 

转载于:https://www.cnblogs.com/liuxiaoran/p/8794998.html