Last_IO_Error: Fatal error:slave have equal MySQL Server UUIDs原因及解决

千家信息网最后更新 2024年12月12日Last_IO_Error: Fatal error:slave have equal MySQL Server UUIDs原因及解决最近在虚拟机上部署MySQL主从复制架构的时候，碰到了
"Last_IO_Error: Fatal error: The slave I/O thread stops because master and slave have equal MySQL server UUIDs; these UUIDs must be different for replication to work."
这个错误提示。
即主从架构中使用了相同的UUID。检查server_id系统变量，已经是不同的设置，那原因是？

1、错误提示：
mysql> show slave status \G;
*************************** 1. row ***************************
Slave_IO_State:
Master_Host: 192.168.30.138
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: binlog.000023
Read_Master_Log_Pos: 331
Relay_Log_File: mysql2-relay-bin.000001
Relay_Log_Pos: 4
Relay_Master_Log_File: binlog.000023
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:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 331
Relay_Log_Space: 120
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 1593
Last_IO_Error: Fatal error: The slave I/O thread stops because master and slave have equal MySQL server UUIDs; these UUIDs must be different for replication to work.
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
Master_UUID:
Master_Info_File: /data/mysql/data/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp: 160520 10:54:33
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 0
1 row in set (0.00 sec)

查看slave的状态时Last_IO_Error有错误提示。

2、检查server_id和UUID
master：
mysql> show variables like '%server%';
+---------------------------------+--------------------------------------+
| Variable_name | Value |
+---------------------------------+--------------------------------------+
| character_set_server | utf8 |
| collation_server | utf8_general_ci |
| innodb_ft_server_stopword_table | |
| server_id | 1 |
| server_id_bits | 32 |
| server_uuid | e5fa0e64-0c48-11e6-a2f7-000c292545f2 |
+---------------------------------+--------------------------------------+
6 rows in set (0.00 sec)

slave:
mysql> show variables like '%server%';
+---------------------------------+--------------------------------------+
| Variable_name | Value |
+---------------------------------+--------------------------------------+
| character_set_server | utf8 |
| collation_server | utf8_general_ci |
| innodb_ft_server_stopword_table | |
| server_id | 2 |
| server_id_bits | 32 |
| server_uuid | e5fa0e64-0c48-11e6-a2f7-000c292545f2 |
+---------------------------------+--------------------------------------+
6 rows in set (0.00 sec)

从上面的可过看到两边server_id不一致，但是UUID是一致的。

检查auto.cnf文件
此文件在datadir目录
[root@mysql1 data]# cat auto.cnf
[auto]
server-uuid=e5fa0e64-0c48-11e6-a2f7-000c292545f2

[root@mysql2 data]# cat auto.cnf
[auto]
server-uuid=e5fa0e64-0c48-11e6-a2f7-000c292545f2

3、解决方法
因为我这是虚拟机操作，整个系统使用了克隆的方式搭建的从库，所以导致了主从UUID一致。
1）删除从库上原来的auto.cnf文件
[root@mysql2 data]# mv auto.cnf auto.cnf.bak

2）重启MySQL进程
[root@mysql2 data]# service mysqld restart
Shutting down MySQL.. [ OK ]
Starting MySQL.... [ OK ]
[root@mysql2 data]#

3）查看auto.cnf文件，UUID已经发生了变化
[root@mysql2 data]# cat auto.cnf
[auto]
server-uuid=0f7d1af5-1e37-11e6-97e2-000c29a23ba9

4）重启slave
[root@mysql2 data]# mysql -uroot -p
Enter password:
。。。。。。。。。。。

mysql> start slave;
Query OK, 0 rows affected, 1 warning (0.00 sec)

5）查看slave状态。
mysql> show slave status \G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.30.138
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: binlog.000023
Read_Master_Log_Pos: 410
Relay_Log_File: mysql2-relay-bin.000003
Relay_Log_Pos: 359
Relay_Master_Log_File: binlog.000023
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:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 410
Relay_Log_Space: 533
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
Master_UUID: e5fa0e64-0c48-11e6-a2f7-000c292545f2
Master_Info_File: /data/mysql/data/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 0
1 row in set (0.00 sec)

至此问题解决，同步正常。
在虚拟机克隆方式搭建主从时需要注意，否则容易出现上面的问题。