mysql主从同步报错怎么办_mysql复制异常排查

主从同步报错应先执行show slave statusg，重点检查slave_io_running、slave_sql_running、seconds_behind_master、last_io_error和last_sql_error；常见原因包括网络/权限问题、sql执行失败、gtid事务跳过不当、表结构不一致及binlog被清理。

主从同步报错时，先看 SHOW SLAVE STATUSG 的关键字段

绝大多数复制异常都能从这个命令的输出里定位根源。重点关注 Slave_IO_Running、Slave_SQL_Running、Seconds_Behind_Master、SQL_Delay 和最核心的 Last_IO_Error 与 Last_SQL_Error。

常见错误现象：

• Slave_IO_Running: No：通常意味着网络不通、主库权限不足、或主库 binlog 被清理导致找不到指定日志文件
• Slave_SQL_Running: No：说明中继日志（relay log）里的某条语句在从库执行失败，比如主键冲突、表结构不一致、函数不可用等
• Seconds_Behind_Master: NULL 且 SQL 线程未运行：大概率是 SQL 线程卡在某个错误上，必须手动干预

跳过单条出错的 SQL（SET GLOBAL sql_slave_skip_counter = 1）慎用

这个命令只对基于语句复制（SBR）有效，且仅跳过下一条事件；对基于行复制（RBR）基本无效（mysql 5.7+ 默认 RBR），强行使用可能造成主从数据不一致。

更安全的做法是用 gtid_next 跳过：

STOP SLAVE; SET GTID_NEXT='f8e7f9b2-1a3c-11ef-8a12-00155d012345:12345'; BEGIN; COMMIT; SET GTID_NEXT='AUTOMATIC'; START SLAVE;

其中 f8e7f9b2-1a3c-11ef-8a12-00155d012345:12345 是 Last_SQL_Error 中提示的出错事务 GTID。务必先确认该事务确实可丢弃（例如是测试数据、重复插入等），否则跳过会引发主从差异。

主从表结构不一致导致的 column count doesn't match value count

这是 RBR 模式下非常典型的错误：主库写入时用了 INSERT INTO t(a,b) VALUES(1,2)，但从库表 t 多了一列 c（或少了一列），导致解析 binlog 行事件失败。

排查步骤：

• 对比主从库对应表的 SHOW CREATE table tG 输出
• 检查是否启用了 slave_type_conversions（默认为空，不自动兼容类型差异）
• 确认 DDL 是否只在主库执行、且已正确同步到从库（注意 ALTER TABLE 在 RBR 下也会记录为事件）

修复建议：优先用 pt-online-schema-change 或 gh-ost 做在线 DDL，避免主从结构漂移；若已出错，先停从库，手工补全缺失列或删除冗余列，再 START SLAVE。

主库 binlog 被清理，从库报 Could not find first log file name in binary log index file

说明从库需要读取的 binlog 文件（如 mysql-bin.000123）已在主库被 PURGE BINARY LOGS 或过期策略删除。

此时无法靠常规方式恢复同步，只能：

• 重新做一次全量同步（mysqldump + CHANGE MASTER TO ... MASTER_LOG_FILE 指向最新 binlog）
• 启用 binlog_expire_logs_seconds（MySQL 8.0.14+）替代旧的 expire_logs_days，设为足够长（如 604800 秒 = 7 天）防止误删
• 监控从库的 Seconds_Behind_Master，一旦延迟过大，及时介入，避免追日志时触发清理

别指望 RESET SLAVE 能解决问题——它只是清空从库的复制元数据，不解决日志丢失的本质。