问题
今天添加了一个mysql5.7的 slave数据库，部署完成之后，启动新部署的slave一切正常，但是收到了老slave数据库的主从同步报警。
登陆故障数据库查询到，Mysql主从同步报错如下
1. 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.003459’ at 4, the last event read from ‘/data/dblogs/binlog_3306/mysql-bin.003466’ at 445747689, the last byte read from ‘/data/dblogs/binlog_3306/mysql-bin.003466′ at 445747689.’
问题原因
如报错信息可以见到，这种现象是server-UUid相同导致，并且经过多次确认集群中server-id是不一样，而server_uuid是一样，如下所示。
两台机的server-id是一样的
slave1@192.168.179.52: (none) 09:58:45>show variables like ‘server_id’;
+—————+———+
| Variable_name | Value |
+—————+———+
| server_id | 2 |
+—————+———+
1 row in set (0.00 sec)
slave2@192.168.179.53: (none) 09:58:58>show variables like ‘server_id’;
+—————+——-+
| Variable_name | Value |
+—————+——-+
| server_id | 3|
+—————+——-+
1 row in set (0.00 sec)
两台机的server_uuid 是相同的
slave1@192.168.179.52: (none) 09:59:45>show variables like ‘server_uuid’;
+—————+————————————–+
| Variable_name | Value |
+—————+————————————–+
| server_uuid | 851bc22f-c0ce-11e6-a3bf-1866dae7e3f0 |
+—————+————————————–+
1 row in set (0.00 sec)
slave2@192.168.179.53: (none) 10:00:42>show variables like ‘server_uuid’;
+—————+————————————–+
| Variable_name | Value |
+—————+————————————–+
| server_uuid | 851bc22f-c0ce-11e6-a3bf-1866dae7e3f0 |
+—————+————————————–+
1 row in set (0.00 sec)
错误原因：
俺要配置mysql 一主多从的主备架构环境，就将原来的配好的一主一从的主从环境的从机，直接复制备份一套出不，然后修改主机名和IP地址，就直接尝试新增的从机跟主机作主从配置，也就是执行命令change master。。。就报错，因为俺的新增从机是直接备份出来的，结果auth.cnf里面保存的uuid仍然是slave1的uuid，导致再向master申请binlog时master神经错乱，无法识别两个slave。
如下内容为网络查询总结：
1. MySQL 5.6 用 128 位的 server_uuid 代替了原本的 32 位 server_id 的大部分功能。原因很简单，server_id 依赖于 my.cnf 的手工配置，有可能产生冲突 —— 而自动产生 128 位 uuid 的算法可以保证所有的 MySQL uuid 都不会冲突。
2. 在首次启动时 MySQL 会调用 generate_server_uuid() 自动生成一个 server_uuid，并且保存到 auto.cnf 文件 —— 这个文件目前存在的唯一目的就是保存 server_uuid。
3. 在 MySQL 再次启动时会读取 auto.cnf 文件，继续使用上次生成的 server_uuid。
4. 使用 SHOW 命令可以查看 MySQL 实例当前使用的 server_uuid：
5. SHOW GLOBAL VARIABLES LIKE ‘server_uuid’;
6. 它是一个 MySQL 5.6 global variables
7. 全局唯一的 server_uuid 的一个好处是：可以解决由 server_id 配置冲突带来的 MySQL 主备复制的异常终止
8. 在 MySQL 5.6，Slave 向 Master 申请 binlog 时，会首先发送自己的 server_uuid，Master 用 Slave 发送的 server_uuid 代替 server_id （MySQL 5.6 之前的方式）作为 kill_zombie_dump_threads 的参数，终止冲突或者僵死的 BINLOG_DUMP 线程。
解决方法
既然我们知道故障原因是server_uuid 相同导致，而且server_uuid是在mysql启动的时候生成的，那么我们就可以，进入mysql的数据目录，找到auto.cnf文件，将此文件移动走，然后重启mysql生成新的server_uuid 即可。
以下文章点击率最高
Loading…