“error connecting to master”但telnet通，说明mysql未启动重试逻辑，默认只连一次失败即停；gtid模式下需检查auto_position是否为1及last_io_error；slave_net_timeout与tcp_keepalive_time配置不当会导致超时问题；mgr场景出现“gcs: timeout”应排查网络层而非主从复制。
错误日志里看到 “error connecting to master” 却 telnet 通，说明重连根本没触发
这不是网络不通，是 MySQL 压根没启动重试逻辑。默认行为就是：只连一次，失败就停在 Slave_IO_Running: No，不自动重连。GTID 模式下尤其明显——如果 AUTO_POSITION = 0 或压根没设，哪怕 slave_net_timeout 调成 1，IO 线程也不会 retry。先查日志里有没有这句：The slave I/O thread stops because a fatal error is encountered...，再立刻执行：SHOW SLAVE STATUS\G，重点看 Auto_Position 是否为 1 和 Last_IO_Error 是否为空或仅含连接类提示。
日志反复出现 “Got timeout reading communication packets”，说明主库发包慢或被中间设备掐断
这个错误不是客户端连不上，而是连接已建、但后续数据收不到。根源在 slave_net_timeout 设置不合理，或中间有防火墙/NAT 设备清连接（常见超时 300 秒）。此时必须同步检查两件事：
- 从库执行
SELECT @@global.slave_net_timeout;，若 ≥ 3600，基本可判定抖动后要等近一小时才重试 - 主从两端都运行
ss -i state established '( dport = :3306 )' | grep keep，确认内核tcp_keepalive_time是否小于中间设备空闲阈值（云厂商通常 300–900 秒）
tcp_keepalive_time 必须设为 600 或更低，并配 tcp_keepalive_intvl=30、tcp_keepalive_probes=3。
日志中高频出现 “gcs: timeout while waiting for message”，别查主从，直奔网络层
这是 MGR 组复制特有的 GCS 心跳中断信号，和传统主从无关。一旦看到这条，立刻停掉所有 GTID/relay log 类排查，转而做三件事：
- 确认所有节点
skip-name-resolve=ON，且loose-group_replication_local_address写的是静态 IP（如"192.168.164.30:33061"），绝不能是域名 - 用
mtr --report -c 100对其他节点探测，重点关注丢包率 > 0.5% 或 RTT 标准差 σ > 20ms - 检查
performance_schema.global_variables中group_replication_exit_state_action是否为offline_mode——若是，节点进程还在，但已拒绝新事务，看起来像“掉线”
重连恢复后 Seconds_Behind_Master 突然飙高，别急着告警，先看 Slave_IO_Running 状态
这个指标为 NULL 时，90% 是 Slave_IO_Running 没跑起来，不是 SQL 线程慢。监控脚本如果只盯 Seconds_Behind_Master > 60 就发警报，大概率误报。真正该组合判断的是：
-
Slave_IO_Running = Yes且Slave_SQL_Running = Yes -
Seconds_Behind_Master不为NULL - GTID 模式下，
Retrieved_Gtid_Set和Executed_Gtid_Set差值稳定增长
Seconds_Behind_Master 飙高几秒属正常；但如果持续 > 60 且 Slave_IO_Running 是 Connecting，说明 MASTER_CONNECT_RETRY 和 slave_net_timeout 没对齐，比如前者是 60、后者是 30，就会卡在“断开→等 60 秒→重试→失败→再等 60 秒”的死循环里。
