查指定通道复制线程是否存活，必须用show replica status for channel 'master1'\g，关注slave_io_running和slave_sql_running是否均为yes；若任一为no则通道中断，seconds_behind_master失效；io为connecting说明网络、主库或权限问题，sql为no且报错需人工干预；gtid模式下需比对retrieved_gtid_set与executed_gtid_set是否持续收敛。
查指定通道的复制线程是否存活
多源复制中，每个主库对应一个 Channel_name，状态不互通。不能只看 SHOW REPLICA STATUS\G 的第一行——它默认返回第一个通道，容易漏掉异常通道。
必须显式指定通道名查询：
SHOW REPLICA STATUS FOR CHANNEL 'master1'\G
重点关注：Slave_IO_Running 和 Slave_SQL_Running 是否都为 Yes；若任一为 No，该通道已中断，Seconds_Behind_Master 数值失效。
- 若
Slave_IO_Running = Connecting：大概率是网络不通、主库宕机、或复制用户权限失效 - 若
Slave_IO_Running = No且Last_IO_Error提示error connecting to master：检查主库bind_address、防火墙、repl用户是否允许从该 IP 登录 - 若
Slave_SQL_Running = No且Last_SQL_Error显示Duplicate entry或Table doesn't exist：说明 SQL 线程卡在某条 DML 或 DDL 上，需人工干预
比对 GTID 集合是否持续收敛
GTID 模式下，Retrieved_Gtid_Set（已拉取但未执行）和 Executed_Gtid_Set（已执行）应逐步趋近。若两者长期不等，且 Retrieved_Gtid_Set 停滞不动，说明 IO 线程没在拉日志；若差值稳定增长但 Executed_Gtid_Set 不动，说明 SQL 线程堵死。
执行命令确认：
SELECT Channel_name, Retrieved_Gtid_Set, Executed_Gtid_Set FROM performance_schema.replication_connection_status WHERE Channel_name = 'master1';
- 若
Retrieved_Gtid_Set为空或长时间不变 → IO 层问题（主库无新事务、网络断开、binlog 被 purge） - 若
Retrieved_Gtid_Set持续变大但Executed_Gtid_Set卡住 → SQL 层问题（如从库缺失表、字段类型不兼容、触发器报错） - 注意：GTID 模式下不能用
sql_slave_skip_counter，跳过需用SET GTID_NEXT+ 空事务方式，否则破坏 GTID 序列
检查 relay log 是否写满或损坏
从库磁盘满、relay log 文件损坏、或 relay_log_space_limit 设置过小，都会导致 IO 线程静默失败——不报错但停止写入，表现为 Relay_Log_Space 不再增长。
先查空间占用：
SELECT @@relay_log_space_limit, @@relay_log_purge;
- 若
relay_log_space_limit > 0且磁盘剩余空间不足该值，IO 线程会暂停写入 relay log - 若
relay_log_purge = OFF，旧 relay log 积压可能撑爆磁盘；建议保持ON（默认） - 手动验证 relay log 是否可读：
mysqlbinlog /var/lib/mysql/relay-log-bin.000001，报错则文件损坏，需清空relay_log_index并重启复制
确认主库 binlog 是否被提前清理
这是最隐蔽也最常被忽略的根源：主库 expire_logs_days 设得太小（比如 1 天），而某个通道因故障停顿超时，从库再连时请求的 Master_Log_File 已被 purge，错误信息通常是：
Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file'
验证步骤：
- 在从库查该通道当前位点：
SELECT Master_Host, Master_Log_File, Read_Master_Log_Pos FROM performance_schema.replication_connection_status WHERE Channel_name = 'master1'; - 登录主库执行：
SHOW BINARY LOGS;，确认Master_Log_File是否还在列表中 - 若已丢失，且该通道启用了 GTID，则需对比主库
gtid_executed与从库Executed_Gtid_Set，用SET GLOBAL gtid_purged = 'xxx'补齐缺失集合（务必确保 purged 集合完全覆盖缺失部分，否则仍失败） - 若非 GTID 模式，只能重做该通道：导出主库当前数据 + 新的 binlog position，重新
CHANGE MASTER TO ... FOR CHANNEL
真正麻烦的不是发现不同步，而是发现时已经丢了几天日志——所以日常必须监控 Retrieved_Gtid_Set 增长趋势和主库 binlog 存留周期，不能只盯 Seconds_Behind_Master。
