解决 Slave_SQL_Running: NO 问题（方案：数据库的备份）

最新推荐文章于 2025-06-06 15:34:06 发布

奋斗吧，青年！

最新推荐文章于 2025-06-06 15:34:06 发布

阅读量2.3w

点赞数 6

CC 4.0 BY-SA版权

本文链接：https://blog.youkuaiyun.com/lilygg/article/details/98187015

本文介绍了解决MySQL主从复制中因数据不一致导致的IO连接失败问题的方法。通过在主库备份数据并导入从库，解决了server1和server3之间的数据不一致，确保了主从复制的正常运行。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

实验环境：

server1和server2主从复制（基于GTID）已经搭建成功

server1：  172.25.66.1   master
server2：  172.25.66.2   slave

点击此处即可查看mysql主从复制搭建详细过程

需求：

现需要再加入一个server3结点，搭建一主两从

server3：  172.25.66.3  slave

问题： IO连接失败

根据报错提醒，得知是主库server1和从库server3的数据不一致造成的

检查发现，server1和server3确实数据不一致

[root@server1 ~]# mysql -u root -p'hym19970818HYM#'
mysql> show databases;

[root@server3 ~]# mysql -u root -p'hym19970818HYM#'
mysql> show databases;

解决方案：

先将主库的数据备份出来，然后再导入从库即可

1.备份数据库

#备份所有数据库到2019.8.2.sql文件中
[root@server1 ~]# mysqldump -uroot -phym19970818HYM# --all-databases > 2019.8.2.sql

发现有警告：由于我这里搭建的基于GTID方式的主从复制，而GTID在一个数据库中是唯一的，当导入其他的库可能会重复，所有会有一个警告提醒。

根据警告提示，加上 --set-gtid-purged=OFF 参数即可。注意该警告不能忽略，否则会造成导入从库失败的严重后果。

[root@server1 mysql]# mysqldump -uroot -phym19970818HYM# --set-gtid-purged=OFF --all-databases > 2019.8.2.sql
mysqldump: [Warning] Using a password on the command line interface can be insecure.

虽然还剩一个警告，但该警告的意思是在命令行使用密码不安全，此警告可以忽略。

2.发送备份的数据库文件

[root@server1 mysql]# scp 2019.8.2.sql root@172.25.66.3:

3.导入数据库

[root@server3 ~]# mysql -uroot -phym19970818HYM# < 2019.8.2.sql
mysql: [Warning] Using a password on the command line interface can be insecure.

#测试： 有westos数据库，说明导入成功
[root@server3 ~]# mysql -u root -p'hym19970818HYM#'
mysql> show databases;

4.重启slave

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

mysql> start slave;
Query OK, 0 rows affected (0.06 sec)

测试：

mysql> show slave status\G;