mysql主从复制如何处理网络中断_mysql容错机制说明

网络中断导致slave_io_running为no时，需先验证真实断连：检查show slave status、telnet端口、复制账号权限、主库skip-networking/max_connections、错误日志及认证插件兼容性；调整slave_net_timeout=30与master_retry_count=86400，并启用master_heartbeat_period=5000；重连后seconds_behind_master跳变属正常积压追赶，勿跳过事件；长期延迟需查i/o、中继日志空间及大事务阻塞；启用并行复制、expire_logs_days≥7、relay_log_recovery=on及gtid模式提升容错能力。

网络中断导致 Slave_IO_Running 为 No，先确认是不是真断了

网络中断是最常见的 IO 线程失败原因，但别急着重连——先排除误判。执行 SHOW SLAVE STATUSG，如果 Slave_IO_Running: No 且 Last_IO_Error 类似 error connecting to master 或 timeout，再往下查。

• 用 telnet 主库IP 3306 或 nc -zv 主库IP 3306 测试端口连通性（注意：mysql 默认不监听公网，检查 bind_address 和防火墙）
• 确认从库配置的复制账号在主库上真实存在，且授权包含 REPLICATION SLAVE 权限（SHOW GRANTS for 'repl'@'%';）
• 检查主库是否启用了 skip-networking，或 max_connections 耗尽导致拒绝新连接
• 查看从库错误日志：tail -n 50 /var/log/mysqld.log，留意是否有 authentication plugin 不兼容（如 caching_sha2_password 在旧客户端不可用）

slave_net_timeout 和 master_retry_count 怎么调才不反复断

默认 slave_net_timeout=60，即 IO 线程空闲 60 秒就主动断开；若主库写入稀疏，又没心跳机制，就会“假中断”。这不是故障，是设计行为。

• 建议设为 slave_net_timeout = 30（更敏感）+ master_retry_count = 86400（1天内无限重试），避免短暂抖动触发中断
• MySQL 5.7+ 支持 MASTER_HEARTBEAT_PERIOD（单位毫秒），例如 CHANGE MASTER TO MASTER_HEARTBEAT_PERIOD = 5000;，强制主库每 5 秒发心跳包，让 IO 线程始终保持活跃
• 注意：调整后必须 STOP SLAVE; START SLAVE; 才生效，仅 reload 配置无效

重连后数据没丢，但 Seconds_Behind_Master 突然跳变很大

这不是同步失败，而是网络恢复后，从库批量拉取积压 binlog 导致的正常现象。关键看后续是否持续下降。

• 不要手动跳过事件（sql_slave_skip_counter），IO 中断不产生 SQL 执行错误，跳过会直接丢数据
• 若延迟长期卡住不动，检查从库磁盘 I/O（iostat -x 1）、中继日志写满（df -h /var/lib/mysql）、或是否被大事务阻塞（SHOW PROCESSLIST 查看 State 为 Reading Event from the relay log 的线程是否卡住）
• 启用并行复制可加速追赶：SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK'; SET GLOBAL slave_parallel_workers = 4;（需主库也开启 binlog_transaction_dependency_tracking）

容错不能只靠“自动重连”，得有兜底动作

网络中断本身可自愈，但若中断期间主库发生 failover、binlog 被轮转清理、或从库意外重启丢失 relay log，单靠重连就失效了。

• 主库必须设置 expire_logs_days = 7（至少保留一周 binlog），避免从库重连时所需日志已被删
• 从库开启 relay_log_recovery = ON（MySQL 5.6+），崩溃重启后自动重建 relay log，防止 relay log 损坏导致复制卡死
• 生产环境强烈建议启用 GTID：gtid_mode = ON + enforce_gtid_consistency = ON，这样网络中断恢复后无需人工计算 binlog 位置，START SLAVE 自动续传
• 监控项不能只盯 Slave_IO_Running，还要告警 Seconds_Behind_Master > 300 且持续 2 分钟以上——延迟暴增往往是网络抖动+大事务叠加的信号

网络中断本身不可怕，可怕的是把它当成孤立事件处理。真正决定容错能力的，是 binlog 保留策略、GTID 是否启用、以及 relay log 是否能自我修复——这些配置一旦漏掉，下次中断可能就得重建从库。