MySQL 主从单向同步配置与故障排除指南

晚来风

发布时间：2026-10-15| 4人浏览过

原创

本文介绍 MySQL 单向主从复制的完整配置步骤，包括主库权限分配、从库参数设置以及连接验证。同时深入分析并解决同步过程中常见的 Slave_SQL_Running: No 报错问题，提供基于日志断点恢复和事务跳过两种实用的故障排除方法。

配置环境与前提准备

MySQL 主从同步要求主服务器（Master）与从服务器（Slave）安装相同版本的 MySQL，且目标数据库名称需保持一致。虽然初始数据无需完全一致，但建议尽可能保持同步起点的数据状态相近，以减少后续纠偏工作。

第1步：Master 服务端配置

在主服务器 192.168.0.1 上执行以下操作：

创建专用同步账号

为从库创建一个仅用于复制数据的备用账号，赋予必要的权限。

GRANT REPLICATION SLAVE,RELOAD,SUPER ON *.* TO backup@'192.168.0.2' IDENTIFIED BY 'wwwjb51net';

注意：创建用户后，请确保客户端能从 IP 192.168.0.2 成功连接至主服务器，以验证网络连通性及权限生效情况。

修改主库配置文件

在 [mysqld] 段落中添加以下配置，启用二进制日志并设置唯一的服务 ID：

server-id=10
log-bin=mysql-bin

第2步：Slave 客户端配置

在从服务器 192.168.0.2 上进行如下配置：

修改从库配置文件

同样在 [mysqld] 段落下添加从库特有参数。请注意区分服务 ID，避免与主库冲突，并指定主库地址及认证信息。

server-id=11
master-host=192.168.0.1
master-user=backup
master-password=wwwjb51net
replicate-do-db=jb51

其中 replicate-do-db 指定需要同步的具体数据库名（示例中为 jb51）。

第3步：启动与基础测试

修改配置文件后，重启 MySQL 服务以使配置生效。随后进入从库数据库：

mysql -h 192.168.0.1 -u root -p

在后台主库中添加测试数据，观察从库对应表中的数据是否实时追加，以初步判断同步链路是否通畅。

常见问题排查：Slave_SQL_Running: No

在实际操作中，初次配置常因事务回滚、人为写入错误或版本差异导致同步中断。执行 show slave status\G; 查看状态时，若出现 Slave_SQL_Running: No 且 Last_Errno: 1062（通常为主键重复），可参考以下解决方案。

解决方案 I：基于 Binlog 断点强制同步

此方法适用于数据量不大或允许少量非关键数据丢失的场景。它强制从库从主库指定的日志位置开始同步。

停止从库线程：
```
slave stop;
```
获取主库当前位置：
登录主库 192.168.0.1，执行：
```
show master status;
```
记录输出中的 File 和 Position 值（例如：mysql-bin.000020 和 135617781）。
在从库执行手动同步：
登录从库，使用 change master to 命令指向新的同步点：
```
change master to
master_host='192.168.0.1',
master_user='backup',
master_password='wwwjb51net',
master_port=3306,
master_log_file='mysql-bin.000020',
master_log_pos=135617781;

slave start;
```
注：示例中端口为默认 3306，若原环境配置了非标准端口（如 3307），请按实际调整。
验证结果：
再次执行 show slave status\G;，确认 Slave_IO_Running 和 Slave_SQL_Running 均为 Yes，且 Seconds_Behind_Master 为 0。

解决方案 II：跳过出错事务

若不想中断同步流程，可尝试忽略当前的错误事务。此方法适用于确认出错数据不重要或已手动修正的情况。

slave stop;
set GLOBAL SQL_SLAVE_SKIP_COUNTER=1;
slave start;

上述命令将跳过接下来的一个事务。如果错误持续存在，可能需要重复执行多次或检查具体错误原因。需注意，该方法不一定能彻底解决所有类型的主从不一致问题。

简要总结

MySQL 单向同步的核心在于准确配置主库日志、从库中继及认证权限。当遇到同步中断时，优先根据错误日志判断是数据冲突还是网络问题。对于严重的不一致，解决方案 I 提供了更可控的重新开始方式；而对于轻微的错误，解决方案 II 则是快速恢复的手段。定期监控 Seconds_Behind_Master 有助于提前发现同步延迟风险。

以上就是 MySQL 主从单向同步配置及故障排除的详细内容，更多关于 MySQL 运维优化的资料请关注本站其它相关文章！