Slave_IO_Running: Connecting 的真实原因常非网络不通，而是主库磁盘I/O饱和导致binlog dump线程无法及时读取发送日志；需结合show processlist、iostat -xmd 1（关注wMB/s与avgrq-sz）、iftp -P 3306及Seconds_Behind_Master跳变综合判断。
查 Slave_IO_Running 卡在 Connecting 或 Waiting 的真实原因
看到 Slave_IO_Running: Connecting，第一反应常是网络不通，但实际更可能是主库磁盘 I/O 已打满，binlog dump 线程根本无法及时读取并发送日志。此时 telnet 主库IP 3306 能通，show slave status\G 却长期卡住，就是典型信号。
实操建议：
- 先在从库执行
show processlist，观察State字段是否为Connecting to master—— 这说明连接已建，问题不在 TCP 层 - 立刻去主库查
SHOW PROCESSLIST，找User为system user、Command为Binlog Dump的线程，看它的State是Sending binlog event还是Writing to net；如果是后者且持续数秒以上，说明主库网卡或 socket buffer 堵塞 - 用
iostat -x 1在主库观察%util和await：若%util > 95%且await > 20ms，基本可判定磁盘 I/O 是瓶颈，binlog写入跟不上 dump 读取速度
对比 iostat 与 iftop 数据时该盯哪些字段
单纯比对「磁盘每秒写 MB」和「网络每秒收 MB」数值没意义，关键要看它们在复制链路中的角色是否匹配。
实操建议：
- 主库上运行
iostat -xmd 1，重点关注wMB/s（实际写入磁盘的吞吐）和avgrq-sz（平均请求大小）。如果wMB/s接近磁盘理论极限（如 SATA SSD 约 500MB/s），但avgrq-sz < 8（单位 KB），说明是大量小日志刷盘，sync_binlog=1可能正在拖慢节奏 - 从库上运行
iftop -P 3306 -f "port 3306 and host 主库IP"，看单条流的TX（发送）速率是否稳定。若出现间歇性归零或剧烈抖动（比如从 40MB/s 突降到 0），不是网络丢包，而是从库SQL Thread消费太慢，导致 TCP 窗口缩为 0，反压回主库 - 别只看峰值，用
pidstat -d 1查主库mysqld进程的Blk_wrt/s，再用ss -i查对应 socket 的rcv_space和wmem，确认是否因内核缓冲区填满而阻塞
show slave status\G 里 Seconds_Behind_Master 跳变说明什么
这个值不是实时延迟，而是从库 SQL 线程执行位置与主库当前 binlog 位置之间的时间差估算。它跳变（比如从 5 秒突增到 120 秒，又回落）往往暴露底层资源争抢，而非网络波动。
实操建议：
- 跳变 +
Read_Master_Log_Pos增长缓慢 → 主库 I/O 瓶颈。因为从库 IO 线程拉不到新事件，Exec_Master_Log_Pos停滞，但主库时间仍在走 - 跳变 +
Read_Master_Log_Pos正常增长，但Exec_Master_Log_Pos停滞 → 从库 SQL 线程被锁或 CPU 饱和。检查SHOW ENGINE INNODB STATUS中的TRANSACTIONS部分是否有长事务阻塞 - 连续多分钟
Seconds_Behind_Master = 0但Slave_SQL_Running_State显示Waiting for dependent transaction to commit→ GTID 模式下存在并行复制依赖等待，本质是事务粒度设计问题，和 I/O、网络无关
为什么 sync_binlog=1 和 innodb_flush_log_at_trx_commit=1 同时开启会放大 I/O 压力
这两个参数都强制刷盘，但作用对象不同：sync_binlog=1 每次写 binlog 都 fsync，innodb_flush_log_at_trx_commit=1 每次事务提交都刷 redolog。当主库高并发写入时，它们会竞争磁盘队列，尤其在机械盘或低配云盘上，IOPS 会被迅速耗尽。
实操建议：
- 生产环境若使用 NVMe SSD，可保留两者为 1；若为 SATA 盘或云盘（如 AWS gp3），建议设
sync_binlog=1000（每 1000 次写入刷一次 binlog），同时确保innodb_flush_log_at_trx_commit=1不动 —— 因为 redolog 刷盘直接影响事务持久性，不可妥协 - 调整后必须验证：用
mysqlslap模拟写负载，观察show slave status\G中Seconds_Behind_Master是否收敛、iostat中%util是否下降 30% 以上 - 注意：修改
sync_binlog后，主库 crash 可能丢失最多 1000 条 binlog 事件，需评估业务能否接受此 RPO
%util 未爆表时，await 和 svctm 的微小升高（比如从 1ms 到 8ms）已足够让 binlog dump 线程掉队，进而引发级联延迟。 
