多源复制升级必须逐源验证兼容性，因每个channel独立维护relay log和GTID，任一主库版本不兼容即导致SQL_THREAD卡死，错误日志难定位；需停所有channel、升级从库后单channel灰度试跑，并交叉验证relay log位置与主库binlog一致性。
多源复制（Multi-Source Replication）本身不改变 MySQL 版本升级的基本约束，但会让升级风险呈指数级放大——因为一个从库同时拉取多个主库的 binlog，只要其中任意一端版本不兼容，SQL_THREAD 就会卡死或报错，且错误日志往往只提示“unknown event type”，根本看不出是哪路主库惹的祸。
为什么多源复制升级必须逐源验证兼容性
多源复制不是“多个主从拼在一起”就完事了。每个 channel 都独立维护自己的 Relay_Log_File、Exec_Master_Log_Pos 和 GTID 集合。升级前若未确认每条 channel 对应主库的 binlog 格式是否被新版本从库支持，极易触发以下问题：
-
ERROR 1236 (HY000)：“binlog event with unknown type”，常见于 MySQL 8.0+ 主库启用了binlog_transaction_compression=ON，而 5.7 从库无法解析压缩事务事件 -
Slave_SQL_Running: No且Last_SQL_Error显示 “Failed to parse row event”，本质是主库binlog_row_image=MINIMAL而从库版本太旧，缺失列元数据缓存逻辑 - 某 channel 同步正常，另一 channel 却持续重试连接——其实是旧版主库（如 5.6）的
server_id在新版本从库中被误判为重复，触发内部冲突校验失败
关键点：不能只看“从库版本”，必须对每个 MASTER_HOST 单独做 SELECT VERSION() + SHOW VARIABLES LIKE 'binlog%' + SHOW VARIABLES LIKE 'gtid%' 三连查。
升级顺序：先停 channel，再升从库，最后逐个切回
多源复制没有“全局 STOP SLAVE”——STOP SLAVE 只停默认 channel，其他 channel 照常运行。必须显式指定每个 channel：
- 列出所有 channel：
SELECT CHANNEL_NAME FROM performance_schema.replication_connection_configuration; - 逐个停掉：
STOP SLAVE FOR CHANNEL 'ch_1';、STOP SLAVE FOR CHANNEL 'ch_2'; - 确认全部停止：
SELECT CHANNEL_NAME, SERVICE_STATE FROM performance_schema.replication_applier_status;中SERVICE_STATE全为OFF - 升级从库二进制、启动后，**不要直接
START SLAVE**，而是用START SLAVE FOR CHANNEL 'ch_1' UNTIL SQL_AFTER_GTIDS = 'xxx'先单 channel 试跑 5 分钟，观察Seconds_Behind_Master是否稳定归零
特别注意：MySQL 8.0.30+ 对多源 GTID 的 gtid_executed 合并逻辑有变更，若某 channel 的 Retrieved_Gtid_Set 包含已废弃的 server_uuid，升级后可能拒绝启动该 channel，需提前用 RESET SLAVE FOR CHANNEL 'ch_x' ALL 清理（仅限测试环境验证过无风险时）。
升级后必做：检查每个 channel 的 relay log 一致性
多源复制最隐蔽的坑是 relay log 文件损坏或位置错位。升级后不能只信 SHOW SLAVE STATUS\G 里的一行状态，要交叉验证：
- 对比每个 channel 的
Relay_Master_Log_File和对应主库当前Master_Log_File，确保文件名一致（如都是mysql-bin.000042） - 检查
Exec_Master_Log_Pos是否落在主库该 binlog 文件的有效范围内：mysqlbinlog --base64-output=decode-rows -v /path/to/mysql-bin.000042 | tail -20查看末尾 position - 若启用 GTID，执行
SELECT * FROM performance_schema.replication_applier_status_by_coordinator;，确认APPLIED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP时间戳连续无跳变
真实案例：某金融系统升级后所有 channel 显示正常，但某 channel 的 Exec_Master_Log_Pos 停在 123456，而主库该文件最大 position 是 999999——原因是升级过程中该 channel 的 relay log 写入异常，但 SQL thread 未报错，靠人工比对才发现延迟实际已达 2 小时。
多源复制升级真正的复杂点不在操作步骤，而在于你永远不知道哪条 channel 的主库悄悄启用了某个新特性，或者哪台主库的运维同学上周手动改过 my.cnf 却没同步文档。所以升级窗口期必须留足时间做 channel 级别灰度验证，而不是把所有 channel 当成一个整体来“上线”。
