主从复制疑难解答教程：数据库高手进阶之路

MySQL主从复制是保障数据库高可用和读写分离的核心技术，但在实际运维中，常会遇到复制中断、主从延迟或数据不一致等疑难问题。以下为您梳理了常见问题及相应的排查与解决思路：

一、 主从复制中断 (Replica_IO/SQL_Running 为 No)

当从库的 IO 线程或 SQL 线程停止工作时，复制链路会中断。

常见原因及解决方案：

主库 Binlog 丢失 (如 Error 1236)

原因：主库的 Binlog 清理策略不合理，导致从库还未同步的日志被提前删除。

解决：若主库仍保留该 Binlog，可通过 CHANGE MASTER TO 重新指定位置;若已删除，则需通过主库全量备份(如 mysqldump)恢复从库，再重新搭建复制。

Server-ID 冲突

原因：主从库的 server-id 配置相同。

解决：修改从库的 server-id 确保其唯一性，然后重启复制线程。

网络或权限问题

原因：网络不通、防火墙拦截或复制账号权限不足(缺少 REPLICATION SLAVE 权限)。

解决：使用 telnet 等工具检查网络连通性，并在主库确认复制账号的权限配置正确。

数据冲突导致 SQL 线程报错

原因：从库已存在主库要同步的数据(如主键重复)，或主库更新的记录在从库缺失。

解决：在 GTID 模式下，可跳过冲突事务后重启同步;在位点模式下，可通过设置 SQL_SLAVE_SKIP_COUNTER=1 跳过当前事务。

二、 主从复制延迟过大 (Seconds_Behind_Master 过高)

表现为从库数据始终落后于主库，严重影响读写分离场景下的数据一致性。

常见原因及解决方案：

大事务影响

原因：主库执行了大批量的数据插入、更新或全量删除操作，导致 Binlog 事件集中传输，从库回放耗时过长。

解决：将大事务拆分为多个小批次执行，并避免在业务高峰期进行此类操作。

从库硬件性能瓶颈

原因：从库 CPU、内存或磁盘 IO 性能不足，或承担了过多的查询请求，导致回放速度跟不上。

解决：升级从库硬件(如使用 SSD 磁盘)，增加从库节点以分散读压力，或通过中间件进行读写分流。

未开启并行复制

原因：从库默认使用单线程回放 Binlog，处理效率低。

解决：在 MySQL 5.7 及以上版本中，配置 slave_parallel_type=LOGICAL_CLOCK 和 slave_parallel_workers(建议设为 CPU 核心数的一半到一倍)来开启多线程并行复制。

网络延迟

原因：主从库跨地域部署，网络带宽不足或波动。

解决：尽量将主从库部署在同一地域，提升网络带宽，或在 MySQL 8.0 中启用 Binlog 压缩功能。

三、 主从数据不一致

主从库的数据出现差异，是复制架构中最棘手的问题之一。

常见原因及解决方案：

人为在从库进行写操作

原因：开发或运维人员误在从库执行了 DML 语句，破坏了数据一致性。

解决：强烈建议将从库设置为只读模式(read_only=ON 和 super_read_only=ON)，从根源上杜绝误操作。

表缺少主键或唯一索引

原因：在基于行的复制中，无主键会导致从库全表扫描定位数据，不仅性能差，在遇到重复行时还可能误改数据。

解决：强制所有表定义显式主键(可配置 sql_require_primary_key=ON)，并确保 Binlog 格式为 ROW 模式。

复制过滤规则不当

原因：配置了 replicate-do-db 等过滤规则，在主库跨库操作时，可能导致从库漏掉部分更新。

解决：尽量使用更精确的通配符规则，如 replicate-wild-do-table 来替代。

从库事件调度器开启

原因：若从库开启了 event_scheduler，主库同步过来的事件可能被重复执行，引发数据冲突。

解决：在从库配置文件中禁用事件调度器(event_scheduler=OFF)。

排查建议：遇到疑难问题时，首先通过 SHOW SLAVE STATUSG 查看 Last_IO_Error 和 Last_SQL_Error 字段，结合从库的错误日志(.err 文件)通常能快速定位问题根源。