主从复制延迟的7个核心原因包括：从库硬件配置低于主库、慢查询或mdl锁等待、主库写入压力过大、大事务阻塞、ddl操作引发元数据锁、从库备份导致flush table阻塞、网络或磁盘io瓶颈；排查需结合show slave status、pt-heartbeat、系统资源监控及慢日志分析。
主从架构在大规模集群中支撑着高可用、读写分离和数据容灾，但节点多、链路长、依赖深，故障一旦发生，往往波及面广、定位难、恢复慢。关键不在于“会不会修”，而在于“能不能快速判断影响范围、精准锁定根因、稳住业务再修复”。下面结合实战场景，拆解几类最常遇到的问题及其应对逻辑。
主节点宕机或失联
这是最紧急的场景：主库不可用，写入中断，部分从库可能因心跳超时触发误判，甚至引发脑裂。
- 先确认是否真宕机：用netstat -tuln | grep :3306或systemctl status mysql查服务状态；再用ps aux | grep mysqld看进程是否存在。
- 检查网络连通性：从其他节点telnet 主IP 3306，排除防火墙拦截或端口被占；同时查主节点自身iptables -L -n是否有DROP规则。
- 若主节点已不可恢复，需人工介入切换：确保至少一个从库Seconds_Behind_Master = 0且Slave_SQL_Running = Yes，然后执行STOP SLAVE; RESET SLAVE ALL;，将其提升为新主，并更新应用连接配置。
复制延迟飙升或中断
延迟不是问题，突然飙升或卡死才是信号。常见于大事务、DDL操作、从库资源瓶颈或主从配置不一致。
- 用SHOW SLAVE STATUS\G重点看Seconds_Behind_Master、Slave_IO_Running和Slave_SQL_Running三项。若IO线程停在Connecting，大概率是网络或权限问题；若SQL线程停在Executing，可能是SQL执行卡住或死锁。
- 查从库负载：top看CPU/内存是否打满，iostat -x 1看%util是否持续100%，df -h确认磁盘空间是否充足（尤其binlog和relay log目录）。
- 临时跳过非关键错误（仅限明确可忽略的场景）：SET GLOBAL sql_slave_skip_counter = 1;后START SLAVE;，但必须同步记录并事后人工核对数据一致性。
server_id冲突或版本混用
看似低级，却极易在扩容或灰度升级时被忽略，导致复制静默失败——状态显示正常，实则未同步。
- 所有节点执行SELECT @@server_id;，确保全局唯一；检查my.cnf中server-id配置是否被覆盖或重复。
- 确认MySQL版本统一：mysql --version和SELECT VERSION();双校验。不同小版本间可能存在复制协议兼容问题（如8.0.28+对GTID的处理变化）。
- 升级前务必在测试环境模拟主从切换与全量同步，验证binlog格式（STATEMENT/ROW）、GTID开关状态是否一致。
从库只读异常或连接拒绝
应用连不上从库，或连上后报错“read-only”，常被误认为数据库问题，实际多为配置或权限层面疏漏。
- 检查read_only=ON是否被意外关闭，或被启动参数/配置文件覆盖；确认super_read_only未启用（该参数会阻止SUPER用户写入）。
- 验证用户权限：从库账号必须有REPLICATION SLAVE权限用于IO线程，同时需具备对应库表的SELECT权限供应用查询。
- 排查连接池配置：某些Java应用连接池（如HikariCP）默认启用autoCommit=false，在只读从库上执行UPDATE会直接报错，需显式设为true或路由到主库。
