升级多源复制汇聚节点须逐个停通道、记录GTID与位点、手动恢复配置，避免自动定位导致错乱；升级后需验证SQL线程状态、事务应用及错误日志，防止静默失败。
升级多源复制的汇聚节点（即接收多个主库 binlog 的从节点）不能直接套用单主从升级流程——它既不是纯粹的“从库”，也不是可随意写入的“主库”，而是一个承担数据聚合职责的特殊角色。升级失败最常导致的后果是：某一路复制中断、GTID 位点错乱、甚至全量同步重做，业务报表延迟数小时起步。
为什么不能停掉所有主库再升级汇聚节点
多源复制的汇聚节点通常持续接收多路 binlog，每路都有独立的 channel 和 relay_log。如果在升级前未显式停止各 channel，MySQL 服务重启后会尝试按旧版本逻辑重放 relay log，但新版本解析器可能不兼容旧格式的 event（尤其是 ROW 格式中字段类型扩展或 enum/set 变更），引发 Could not execute Write_rows_v1 event on table 类错误。
- 必须逐个执行
STOP SLAVE FOR CHANNEL 'xxx';，不能只用STOP SLAVE;（它只影响默认 channel） - 升级前需确认所有 channel 的
Seconds_Behind_Master为 0，且Slave_SQL_Running_State显示Slave has read all relay log - 特别注意：若某 channel 使用了
MASTER_AUTO_POSITION=1，升级后首次启动时会尝试自动定位 GTID，但旧版 GTID set 可能被新版本截断或解析异常——建议升级前先SELECT @@GLOBAL.gtid_executed;记录快照
升级过程中如何避免复制通道错位
MySQL 版本跨大版本（如 5.7 → 8.0）时，mysql.slave_master_info 和 mysql.slave_relay_log_info 表结构会发生变更，而多源复制依赖这些表持久化每个 channel 的位置信息。直接升级可能导致某几个 channel 的 position 丢失，重启后从最早可用 binlog 开始重放，造成重复写入或主键冲突。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 升级前务必导出各 channel 的精确位点：
SHOW SLAVE STATUS FOR CHANNEL 'order_src' \G中记录Exec_Master_Log_Pos、Relay_Master_Log_File、Master_Host - 不要依赖
mysqldump --all-databases备份系统库——mysql库中的复制元数据表在 8.0 中已转为事务表，dump 时可能不一致；应使用mysqlpump --system或直接SELECT导出关键字段 - 升级后首次启动，先不启动任何 channel：
SET GLOBAL master_info_repository = 'TABLE'; SET GLOBAL relay_log_info_repository = 'TABLE';再逐个CHANGE MASTER TO ... FOR CHANNEL手动恢复位点，而非依赖自动恢复
升级后必须验证的三类复制行为
即使所有 channel 显示 Slave_IO_Running: Yes 和 Slave_SQL_Running: Yes，也不能认为复制正常——多源场景下，SQL 线程实际是串行回放所有 channel 的 events，极易因某条 DML 冲突卡住，但状态仍显示运行中。
- 检查
SHOW PROCESSLIST中是否有Waiting for dependent transaction to commit或Reading event from the relay log长时间停留（超过 30 秒） - 对每个 channel 执行
SELECT * FROM performance_schema.replication_applier_status_by_coordinator;，确认APPLYING_TRANSACTION字段非空且LAST_ERROR_NUMBER = 0 - 人工注入校验数据：在每个上游主库分别插入带唯一标识的测试行（如
INSERT INTO test_sync VALUES ('order-20261105-001', NOW());），观察汇聚节点是否在 5 秒内全部出现，且无主键冲突或跳过
最容易被忽略的是：升级后首次全量重放 relay log 时，InnoDB 对 ROW_FORMAT=COMPRESSED 或虚拟列的处理逻辑变化，可能让某条看似正常的 DML 在 SQL 线程中静默失败——它不会报错，只是跳过，且 Seconds_Behind_Master 仍缓慢推进。必须盯住 error log 中的 Warning 级别日志，而不是只看 ERROR。
