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.28system versionrhel 6.7在用虚拟机配
·
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 的要求。
更多推荐
已为社区贡献2条内容
所有评论(0)