mysql主从不同步解决方法

主从不同步需先检查Slave_IO_Running和Slave_SQL_Running状态，根据错误类型处理：主键冲突可跳过事务；表结构不一致需手动修复或使用pt-table-sync；binlog丢失则需重新备份恢复；GTID异常可通过注入空事务解决，并建议设置read_only、监控延迟、合理配置binlog保留时间及使用半同步复制预防问题。

MySQL主从不同步是数据库运维中常见问题，通常表现为从库（Slave）的延迟增加或复制中断。解决这类问题需要先定位原因，再采取相应措施。以下是常见的排查与修复方法。

检查主从同步状态

登录从库执行以下命令查看复制状态：

SHOW SLAVE STATUS\G

重点关注以下字段：

• Slave_IO_Running：是否正常拉取主库binlog
• Slave_SQL_Running：是否正常执行SQL
• Last_Error：最近的错误信息
• Seconds_Behind_Master：延迟秒数

如果其中一项为“No”，说明同步已中断。

常见问题及处理方式

根据错误类型选择对应解决方案：

1. 主键冲突或记录已存在

错误示例：Duplicate entry for key 'PRIMARY'

这种情况多出现在误操作或手动写入从库后。可跳过该事务：

SET GLOBAL sql_slave_skip_counter = 1;
START SLAVE;

注意：仅适用于非关键数据，跳过前需确认影响范围。

2. 表不存在或DDL不一致

主库执行了建表或删表操作，但从库未同步或结构不一致。

百度虚拟主播

百度智能云平台的一站式、灵活化的虚拟主播直播解决方案

36

查看详情

解决方法：

• 在从库手动创建缺失表（确保结构一致）
• 使用pt-table-sync工具校验并修复结构差异

3. 主库binlog被删除或找不到

错误提示：Could not find first log file name in binary log index

说明从库请求的binlog已被主库清理。

此时只能重新搭建从库：

• 对主库进行逻辑备份（mysqldump）或物理备份（xtrabackup）
• 恢复到从库
• 重新配置CHANGE MASTER TO指向当前主库binlog位置

4. GTID模式下同步异常

若启用GTID，出现“Fatal error on slave”时，可通过注入空事务修复：

STOP SLAVE;
SET GTID_NEXT='指定缺失的GTID';
BEGIN; COMMIT;
SET GTID_NEXT='AUTOMATIC';
START SLAVE;

具体GTID值需根据错误日志确定。

预防主从不同步的建议

避免问题发生比修复更重要：

• 禁止直接在从库写入数据（设置read_only=ON）
• 定期监控Seconds_Behind_Master指标
• 合理设置主库binlog过期时间（expire_logs_days）
• 使用半同步复制（semi-sync）提升数据一致性
• 定期用pt-table-checksum校验主从数据一致性

基本上就这些。主从不同步虽然常见，但只要掌握基本排查流程，多数问题都能快速定位和恢复。关键是平时做好监控和维护，减少人为干预带来的风险。

以上就是mysql主从不同步解决方法的详细内容，更多请关注php中文网其它相关文章！