由于blog各种垃圾评论太多,而且本人审核评论周期较长,所以懒得管理评论了,就把评论功能关闭,有问题可以直接qq骚扰我

mysql 5.7 server_uuid 相同导致slave故障问题解决

数据库 西门飞冰 93℃

问题

今天添加了一个mysql5.7的 slave数据库,部署完成之后,启动新部署的slave一切正常,但是收到了老slave数据库的主从同步报警。

登陆故障数据库查询到,Mysql主从同步报错如下

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-id相同导致,经过多次确认集群中server-id确实不一样。

sys_manage@10.1.13.12: (none) 09:58:41>show variables like 'server_id';
+---------------+---------+
| Variable_name | Value   |
+---------------+---------+
| server_id     | 1217423 |
+---------------+---------+
1 row in set (0.00 sec)
sys_manage@10.1.13.14: (none) 09:58:23>show variables like 'server_id';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| server_id     | 12174 |
+---------------+-------+
1 row in set (0.00 sec)

这时又个新的发现server_uuid 是相同的

sys_manage@10.1.13.14: (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)
sys_manage@10.1.13.12: (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)

错误原因:

我的新slave添加是直接把一个旧的slave停掉,然后拷贝到新的机器上启动,结果auth.cnf里面保存的uuid仍然是slave1的uuid,导致再向master申请binlog时master神经错乱,无法识别两个slave。

如下内容为网络查询总结:

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

解决方法

既然我们知道故障原因是server_uuid 相同导致,而且server_uuid是在mysql启动的时候生成的,那么我们就可以,进入mysql的数据目录,找到auto.cnf文件,将此文件移动走,然后重启mysql生成新的server_uuid 即可。

转载请注明:西门飞冰的博客-专注于Linux运维 » mysql 5.7 server_uuid 相同导致slave故障问题解决

喜欢 (0)or分享 (0)