MySQL主从架构里从服务器挂了，主库通常不会跟着挂，先看复制线程和错误日志，能修就修；修不动就用主库备份加binlog重建从库，别急着在主库上乱操作。
从库挂了先判断：mysql主从从库挂了会影响主库吗？
先给结论：从库挂掉本身不会直接拖垮主库，主库的写入和事务提交照常进行，真正需要担心的是读流量失去分流、备份链路中断、高可用切换能力下降，业务侧如果没做读写分离兜底，部分读请求会压到主库,连接数和CPU可能短时间上升。
现场别急着重启主库,按下面顺序查：
- 看进程：
systemctl status mysqld或ps -ef | grep mysqld，确认是从库服务停了,还是机器本身失联。 - 看错误日志：
tail -n 200 /var/log/mysql/error.log，重点找磁盘满、OOM、网络断开、复制线程报错。 - 看复制状态：MySQL 8.0.22以上用
SHOW REPLICA STATUS\G，老版本用SHOW SLAVE STATUS\G。
复制状态里盯几个字段：Replica_IO_Running、Replica_SQL_Running、Last_IO_Error、Last_SQL_Error、Seconds_Behind_Source，IO线程是Connecting，多半是网络、账号权限或主库连接数问题；SQL线程报错，要看具体错误码，常见的有1032主键冲突、1062唯一键冲突、1236主库binlog找不到。
据MySQL官方文档，主从复制本质是主库把binlog事件发给从库，从库的IO线程写relay log，SQL线程回放，理解这条链路,排查时就不容易乱。
先看三个地方：进程、日志、复制状态
| 检查项 | 命令或路径 | 常见异常 |
|---|---|---|
| 服务进程 | systemctl status mysqld |
服务停止、反复重启 |
| 错误日志 | /var/log/mysql/error.log |
磁盘满、OOM、网络超时 |
| 复制状态 | SHOW REPLICA STATUS\G |
IO线程Connecting、SQL线程报错 |
多数情况下，从库挂掉分两类：一是机器或进程层面的故障，二是复制链路层面的故障，前者先把服务拉起来,后者要判断是跳过错误还是重建。
能修则修：mysql主从从库宕机后如何快速恢复？
从库宕机后要不要修，看两个指标：修复时间能不能压住，数据一致性能不能保证，如果只是进程重启、网络抖动、relay log堆积,通常修比重建快。
从库进程或机器重启
服务起来后,登录从库执行：
START REPLICA; -- 老版本用 START SLAVE; SHOW REPLICA STATUS\G
如果两个线程都是Yes，延迟在下降，基本就恢复了，如果SQL线程报错，先别反复START，把Last_SQL_Error完整看一遍。
网络抖动或主库连接断开
检查从库到主库的3306端口、防火墙、安全组、复制账号权限，确认网络通了以后,可以只重启IO线程：
STOP REPLICA IO_THREAD; START REPLICA IO_THREAD;
如果主库设置了bind-address，确认从库能连到主库真实IP,而不是只配了主机名。
磁盘满或relay log堆积
先看磁盘：df -h，从库磁盘满，常见原因是relay log没及时清理、binlog保留太多、大事务回放，处理时不要直接rm正在用的文件,用SQL命令清理：
PURGE RELAY LOGS BEFORE '2026-01-01 00:00:00';
同时确认relay_log_purge为ON，如果磁盘已经100%，先扩容或清理过期备份,再启动复制线程。
SQL线程冲突
1032、1062这类错误，说明从库数据和主库对不上，业务能接受少量不一致时，可以用sql_slave_skip_counter跳过一条：
STOP REPLICA SQL_THREAD; SET GLOBAL sql_slave_skip_counter = 1; START REPLICA SQL_THREAD;
GTID模式下跳过要换方式，用SET GTID_NEXT指定事务号，跳过只适合临时止损，长期看还是要用备份重建或pt-table-checksum核对数据。
修不好就重建：从库重建的标准操作路径
从库硬件损坏、数据文件丢失、主库binlog已经被purge，这几种情况别硬修，直接重建更稳，重建的核心是：拿一份主库一致性备份，记录对应binlog位点,导入从库后重新指向主库。
热备主库并记录位点
用mysqldump做一致性备份：
mysqldump -uroot -p \ --single-transaction \ --source-data=2 \ --routines --triggers --events \ --all-databases > /backup/full_$(date +%F).sql
MySQL 8.0.23以前用--master-data=2，备份文件头部会记录主库binlog文件和位置，数据量大时用XtraBackup更合适,热备期间对主库影响更小。
导入从库并配置复制
先把从库数据目录清干净,导入备份：
mysql -uroot -p < /backup/full_2026-01-01.sql
GTID模式直接用自动定位：
CHANGE REPLICATION SOURCE TO SOURCE_HOST='主库IP', SOURCE_USER='repl', SOURCE_PASSWORD='密码', SOURCE_AUTO_POSITION=1; START REPLICA;
非GTID模式要指定文件和位点：
CHANGE MASTER TO MASTER_HOST='主库IP', MASTER_USER='repl', MASTER_PASSWORD='密码', MASTER_LOG_FILE='mysql-bin.000123', MASTER_LOG_POS=456789; START SLAVE;
配置完看SHOW REPLICA STATUS\G，确认Replica_IO_Running和Replica_SQL_Running都是Yes,延迟逐步归零。
主从切换和从库重建哪个更划算？
这要看你手里有几台从库、业务能不能停、读流量有多大。
| 对比项 | 从库重建 | 主从切换 |
|---|---|---|
| 停机窗口 | 通常不影响主库写入 | 需要切换窗口和VIP漂移 |
| 数据一致性 | 依赖备份位点，需校验 | 依赖切换前复制延迟 |
| 操作复杂度 | 中等，步骤固定 | 较高，涉及业务连接串 |
| 成本 | 自建主要是人力；云上按备份空间和流量计费 | 自建主要是停机成本；云上包年包月实例切换不额外收费，但业务中断有代价 |
如果只有一台从库且读流量不大，重建更直接，如果从库多、业务读压力大，可以先切到其他从库，再慢慢重建故障节点，行业共识认为，恢复方案的选择要围绕数据一致性和业务停机窗口做平衡,而不是单纯比操作快慢。
北京mysql主从从服务器故障处理的现场差异
在北京做MySQL主从运维，机房和云可用区比较集中，同城灾备常见，从库挂了先确认是单机硬件问题、机柜网络问题，还是云上可用区抖动，自建机房要保留现场日志，联系IDC确认电源和交换机；云上实例先看监控里的磁盘IO和网络丢包，跨机房复制时，北京同城延迟通常不高，但跨运营商链路要重点看丢包率，处理顺序不变：先保主库，再恢复从库,最后做数据校验。
从库恢复后的验证清单
- 复制延迟：
SHOW REPLICA STATUS\G里看Seconds_Behind_Source是否持续下降。 - 数据一致性：用
pt-table-checksum对比主从关键表，或对核心表做CHECKSUM TABLE抽查。 - 读流量灰度：先把少量读请求切回从库,观察连接数和慢查询。
- 监控告警：把复制线程状态、延迟、磁盘使用率纳入告警。
- 备份验证：确认从库恢复后备份任务能正常执行,别等下次故障才发现备份也断了。
从库挂了的处理逻辑可以归纳成一句话：先保主库稳定，再判断修复成本,最后用备份和binlog把复制关系接回来。
MySQL主从从服务器挂了怎么办：常见问题解答
问：从库挂了主库还能写入吗？
能，主库继续接收写请求，但从库缺失会让读请求集中到主库，连接数和CPU可能上升，先限流或把读流量切到其他从库,再处理故障节点。
问：从库重建必须停主库吗？
通常不用，用mysqldump --single-transaction或XtraBackup做热备，记录binlog位点，导入从库后指向主库即可，主库只需要保留对应时间段的binlog,避免备份还没导完binlog就被purge。
问：从库磁盘满了能直接删relay log吗？
不能直接rm正在用的relay log文件，应该用PURGE RELAY LOGS BEFORE '时间'清理，或确认relay_log_purge=ON让系统自动清理，relay log的清理应通过SQL命令完成,而不是操作系统层面的删除。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/787061.html
