是的，MySQL 8.0.1起原生支持多源复制，但仅支持单Slave接收多Master的binlog，要求各Master启用ROW格式、独立server-id、无同名库表冲突，并需正确配置权限、通道名、GTID及中继日志参数。
电商生产环境不能只靠单主单从扛流量，多源复制（Multi-Source Replication）是必须的——但 MySQL 8.0 默认不开启，且配置稍有偏差就会导致 IO_THREAD 启动失败或数据冲突。
MySQL 8.0 多源复制是否原生支持
是的，MySQL 8.0.1 起已原生支持多源复制，无需第三方工具。但注意：它只支持「一个 Slave 接收多个 Master 的 binlog」，不能反向；所有 Master 必须启用 ROW 格式、独立 server-id、且不能有同名数据库表结构冲突。
常见错误现象：CHANGE REPLICATION SOURCE TO ... FOR CHANNEL 'xxx' 执行成功，但 START REPLICA FOR CHANNEL 'xxx' 报错 ERROR 2003 (HY000): Can't connect to MySQL server，本质是网络通但权限没开全，或 source_host 写成了 localhost。
- 每个 Master 必须开放
REPLICATION SLAVE权限给 Slave 用户，例如：GRANT REPLICATION SLAVE ON *.* TO 'repl'@'10.0.0.42' IDENTIFIED BY 'xxx'; - Slave 节点的
my.cnf中必须设置relay_log_recovery=ON和enforce_gtid_consistency=ON（若用 GTID），否则多通道启动时可能卡在 relay log 初始化阶段 - 不要复用同一个
replica_parallel_workers值来压测多通道——高并发下易触发Lock wait timeout exceeded，建议按通道数均分，如 4 个源就设为 2
如何为每个 Master 创建独立复制通道
通道名（channel name）不是随意起的，它会成为 relay log 文件前缀和 performance_schema 表的索引键，一旦创建无法修改，必须语义清晰、带业务标识，比如 'pay_master'、'user_master'。
实操步骤（在 Slave 节点执行）：
- 先停掉默认通道（如果之前启过单源）：
STOP REPLICA; - 为支付库 Master 添加通道：
CHANGE REPLICATION SOURCE TO SOURCE_HOST='10.0.0.41', SOURCE_USER='repl', SOURCE_PASSWORD='xxx', SOURCE_PORT=3306, SOURCE_AUTO_POSITION=1 FOR CHANNEL 'pay_master'; - 为用户库 Master 添加通道：
CHANGE REPLICATION SOURCE TO SOURCE_HOST='10.0.0.43', SOURCE_USER='repl', SOURCE_PASSWORD='xxx', SOURCE_PORT=3306, SOURCE_AUTO_POSITION=1 FOR CHANNEL 'user_master'; - 逐个启动：
START REPLICA FOR CHANNEL 'pay_master'; START REPLICA FOR CHANNEL 'user_master';
验证命令：SELECT CHANNEL_NAME, SOURCE_HOST, SERVICE_STATE FROM performance_schema.replication_connection_status; —— 确保 SERVICE_STATE 是 ON；再查 replication_applier_status_by_coordinator 看 coordinator 是否 RUNNING。
多源复制下如何避免跨库写入冲突
电商场景里，订单库和商品库可能都写入 audit_log 表，若两个 Master 都有该表且结构不同，Slave 应用时直接报错 Table definition has changed，且不会自动跳过。
根本解法不是靠 slave_skip_errors（已废弃），而是前置隔离：
- 所有 Master 的
my.cnf必须配置replicate_ignore_db或更安全的replicate_wild_ignore_table，例如在支付 Master 上加：replicate_wild_ignore_table = %\.sys_%，防止系统表干扰 - 强烈建议各业务线 Master 使用唯一库名前缀，如
pay_orders、user_profiles，并在 Slave 上用replicate_rewrite_db统一映射到本地命名空间（如(pay_orders, prod_pay)），避免同名库冲突 - 禁止在 Slave 上执行任何 DML/DCL——哪怕只是
SELECT ... FOR UPDATE，都可能因 gap lock 导致后续通道的事务被阻塞
监控与故障恢复的关键检查点
电商大促期间最怕的是某个通道延迟飙升却没人发现，等报警时订单对账已经断了 15 分钟。别依赖 Seconds_Behind_Master，它在多源下只显示默认通道值。
必须定期运行的检查语句：
- 查各通道延迟：
SELECT CHANNEL_NAME, SERVICE_STATE, RECEIVED_TRANSACTION_SET, APPLIED_TRANSACTION_SET, LAST_ERROR_NUMBER FROM performance_schema.replication_applier_status_by_worker; - 查 IO 线程状态：
SELECT CHANNEL_NAME, SOURCE_IO_STATE, LAST_IO_ERROR, LAST_IO_ERROR_TIMESTAMP FROM performance_schema.replication_connection_status; - 查 relay log 磁盘占用（多通道会生成大量
relay-bin-pay_master.000001类文件）：du -sh /data/mysql/data/relay-bin-*，超 20GB 就要清理旧文件并确认relay_log_purge=ON
最易被忽略的一点：MySQL 8.0 多源复制不支持 RESET REPLICA ALL 后自动重建所有通道，必须手动重新执行全部 CHANGE REPLICATION SOURCE TO ... FOR CHANNEL。线上切流前务必把建通道语句存进配置管理平台，别只记在本地 shell 历史里。
