主从复制Slave_IO_Running: NO Slave_SQL_Running: NO ，Slave failed to initialize relay log info struct解决办法

墨蓝 2024-03-17 15:51 3阅读 0赞

## **1. 解决问题的思路：** ##

*  找到mysql配置的这个文件/etc/my.cnf
 *  在文件中找到mysql错误异常日志文件的路径，我配置的是log-error=/data/mysql.err
 *  编辑/var/log/mysqld.log文件
 *  查看具体异常信息
    
    ![2c9fa97af1ed005b558fb4f945813974.png][]

## **2. 异常信息** ##

\[ERROR\] Slave I/O for channel ‘’: 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. Error\_code: 1593

![9725b82b9bdec492cf9d37e77fbf44fb.png][]

## **3. 问题定位** ##

由于uuid相同，而导致触发此异常。  
首先我只安装了一台linux 又克隆了两台，一主三从 , 关键点就在于我是克隆的，才导致了报Slave\_IO\_Running: NO  
**原因：** mysql 有个uuid , 然而uuid 是唯一标识的，所以我克隆过来的uuid是一样的，只需要修改一下uuid 就ok了，找到auto.cnf 文件修改uuid

## **4. 解决方案** ##

查询命令找此auto.cnf修改uuid即可：

find -name auto.cnf

其实这个文件就在mysql的data目录中/data/mysql，`这是我的文件位置`  
重启mysql服务器，再查看mysql从节点的状态，恢复正常

重启mysql
    service mysql restart

## **5. 登录MYSQL，重启SLAVE，再次验证** ##

#停止链路
    stop slave;
    #启动链路
    start slave;
    #查看链路
    show slave status \G

![fb37b5e71747826dd57b0f84252bbc4d.png][]

![ea88c73bc197443b5def1fbba406393e.png][]

**可能原因一**：MySQL的uuid是唯一的，查看主从机器的uuid是否唯一。

查看文件：/var/lib/mysql/auto.cnf

查看结果：主从机器的uuid不一样，此可能性被排除。

**可能原因二**：确认server-id是否唯一。

查看文件：/etc/mysql/my.cnf

查看结果：主从机器的server-id唯一，此可能性被排除。

**可能性三**：因为从库[MySQL重启][MySQL]导致二进制文件位置从库和主库不一致。

1、查看：

主库：show master status\\G

从库：show slave status\\G

2、主库从库二进制文件是不一致的，开心，可能就是这个原因了。

3、根据网上方法修改：在从库中依次执行如下操作

mysql> stop slave;  
Query OK, 0 rows affected (0.00 sec)

mysql> CHANGE MASTER TO MASTER\_LOG\_FILE='master-bin.000004', MASTER\_LOG\_POS=154;  
Query OK, 0 rows affected (0.00 sec)

mysql> start slave;  
4、再次查看从库信息：sad。。并没有解决 。

5、失望中，试着依次重启了主机、从机的MySQL。

###### 排查方式 ######

1. 首先我们先通过 performance\_schema 查看一下造成报错的原因

select \* from performance\_schema.replication\_applier\_status\_by\_worker;

**问题描述**：发现主库操作数据从库没有变动问题，可能原因是从库重启导致的无法同步问题。

**排查思路**：

1、查看主从复制状态

发现从库的IO和SQL进程都是no(正常状态应该是yes)

注意：mysql replication中slave机器上有两个关键进程，死一个都不行，一个是slave\_sql\_running,一个是slave\_io\_running，一个负责与主机的IO通信，一个负责自己的slave mysql进程。

![17218cf53316e39b9028534fa6439459.png][]

2、解决办法如下：

>stop slave; \#\#停止同步

> SET GLOBAL SQL\_SLAVE\_SKIP\_COUNTER=1; START SLAVE; \#\#设置counter为1,启动同步

>show slave status\\G; \#\#查看同步状态

![f8bdc32970e5f807c22aec86e728da56.png][]

3、发现SQL进程还是No

提示信息显示如下：

Last\_Errno: 1396

Last\_Error: Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 1 failed executing transaction 'fab1fc64-d0f2-11ec-a2a6-000c2950bca1:9' at master log mybinlog.000001, end\_log\_pos 1966. See error log and/or performance\_schema.replication\_applier\_status\_by\_worker table for more details about this failure or others, if any.

![0c99e6c5120857be115e4605eaa510d7.png][]

4、根据上面的提示，查询到的异常数据出现在opp\_starck表中

\#select \* from performance\_schema.replication\_applier\_status\_by\_worker\\G; 确定事务发生在表opp\_strack上，定位在表上，再去排查是哪张表

![6ab67ef10f16df1647c43deeb139e816.png][]

**可以参考**：[mysql主从同步报错，提示Last\_Error: Coordinator stopped because there were error(s) in the worker(s). The most\_mysql 报错 last\_谁还不是小白鼠的博客-CSDN博客][mysql_Last_Error_ Coordinator stopped because there were error_s_ in the worker_s_. The most_mysql _ last_-CSDN]

5、主从数据恢复一致后需要在slave上跳过报错的事务，在从库中执行

**使用GTID跳过错误的方法：**找到错误的GTID跳过（通过exec\_master\_log\_pos去binlog里找GTID，或者则通过监控表replication\_applier\_status\_by\_worker找到GTID，也可以通过excured\_gtid\_set算GTID），这里使用监控来找到错误的GTID。找到GTID之后，跳过错误的步骤：

>stop slave; \#停止同步

>set @@session.gtid\_next='fab1fc64-d0f2-11ec-a2a6-000c2950bca1:9'; \#跳过错误的GTID

>begin; \#提交一个空事务，因为设置gtid\_next后，gtid的生命周期就开始了，必须通过显性的提交一个事务来结束，否则报错：ERROR

>commit

>set @@session.gtid\_next=automatic; \#设置回自动模式

>start slave; \#启动同步

>show slave status\\G; \#再次确认状态

![88cb1c12502bdaedfed58baa4b2c10bd.png][]

6、如下图主从复制恢复正常

![d62b23b8518a554f55e3e5b2647086a7.png][]

**GTID**：是对于一个已提交事务的唯一编号，并且是一个全局(主从复制)唯一的编号。

**GTID核心参数**

**重要参数：**

gtid-mode=on --启用gtid类型，否则就是普通的复制架构

enforce-gtid-consistency=true --强制GTID的一致性

log-slave-updates=1 --slave更新是否记入日志

注：

Slave\_IO\_State \# 从库的当前状态  
Slave\_IO\_Running \# 读取主服务器二进制日志的I/O线程是否正在运行  
Slave\_SQL\_Running \# 执行读取主服务器中二进制日志事件的SQL线程是否正在运行  
Seconds\_Behind\_Master \# 是否为0，为0就是已经同步了

如果Slave\_IO\_Running或Slave\_SQL\_Running不同时为YES，请尝试执行  
mysql> stop slave;  
mysql> reset slave;  
mysql> start slave;

[2c9fa97af1ed005b558fb4f945813974.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/aece37e3225c450883f02eda1a8a1484.png
[9725b82b9bdec492cf9d37e77fbf44fb.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/e44e90617beb4d0d94632fd93f2123e0.png
[fb37b5e71747826dd57b0f84252bbc4d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/e5ca1892fc404bc3a7c6b4e9f7127f2f.png
[ea88c73bc197443b5def1fbba406393e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/92daad1a7c514bfebfc3a2acf2e95f9d.png
[MySQL]: https://so.csdn.net/so/search?q=MySQL%E9%87%8D%E5%90%AF&spm=1001.2101.3001.7020
[17218cf53316e39b9028534fa6439459.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/ebd252d3e0c94c6cab40582748372c20.png
[f8bdc32970e5f807c22aec86e728da56.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/a8e70fb95e9d47569b240fb947eb1633.png
[0c99e6c5120857be115e4605eaa510d7.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/5238baf621894f828c66808f919f693d.png
[6ab67ef10f16df1647c43deeb139e816.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/5e02139747ae4998b6cd0b854cd34793.png
[mysql_Last_Error_ Coordinator stopped because there were error_s_ in the worker_s_. The most_mysql _ last_-CSDN]: https://blog.csdn.net/memory6364/article/details/86152717
[88cb1c12502bdaedfed58baa4b2c10bd.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/69eb6405e8ca45ebb89e9e86567062e6.png
[d62b23b8518a554f55e3e5b2647086a7.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/96f5bcbde136413e9a47a962c614a840.png