MySQL主从复制无法实现多实例聚合同步，因它仅支持一对一单向全量复制，不支持跨实例去重、字段映射与冲突处理；需用Maxwell等binlog解析工具多进程拉取并路由写入汇总库。
MySQL 多实例数据怎么同步到一个汇总库
靠 MySQL 自带的主从复制做不到跨实例聚合，必须用外部工具或自建逻辑。官方 mysqldump + 定时导入太慢、不实时；mysqlbinlog 解析又难对齐多个实例的 GTID 或位点。真正能落地的，是用 Maxwell 或 Canal 拉取 binlog，再按表名/库名路由写入汇总库。
为什么不能直接用主从复制做分库汇总
主从复制是一对一、单向、全量（或按库过滤）的，不支持「把 A 实例的 order_db、B 实例的 user_db 同时写进 C 实例的 dw 库」这种多源聚合。即使开启 replicate_do_db，也无法跨实例去重、字段映射、冲突处理。
- 多个主库可能有同名表（比如都叫
users），直接同步会覆盖 - 不同实例的
auto_increment值会撞，插入时报Duplicate entry - 没有统一时间戳字段，无法判断哪条更新更“新”
-
SET sql_log_bin=0在从库关日志后，后续变更无法被下游捕获
Maxwell 怎么配置才能稳定聚合多实例
Maxwell 本身只连一个 MySQL 实例，所以得启动多个 Maxwell 进程，每个连一个分库，输出到同一 Kafka 主题（或不同主题但由 Flink/Logstash 统一路由）。关键在 producer 和 filter 配置。
- 每个 Maxwell 实例配独立
client_id，避免 offset 冲突 - 用
--filter='include: db1\.orders, include: db2\.users'精确选表，别用通配符漏掉字段 - 输出 JSON 时加
--output_ddl=true，方便下游识别建表语句 - 汇总库写入端必须做
REPLACE INTO或INSERT ... ON DUPLICATE KEY UPDATE，否则主键冲突就卡死 - 注意
maxwell的bootstrapper全量同步阶段会锁表，生产环境要避开高峰
同步延迟大或丢数据，先查这三处
不是网络或磁盘问题，大概率是 binlog 格式、权限或消费端没跟上。
- 确认所有分库都设了
binlog_format = ROW，STATEMENT模式下 Maxwell 解析不了函数和临时表 - 检查 Maxwell 用户是否有
SELECT、REPLICATION CLIENT、REPLICATION SLAVE权限，少一个就停在 initial sync - 如果用 Kafka，看
kafka-consumer-groups --describe输出里LAG是否持续增长——说明下游消费太慢，得调大fetch.max.wait.ms或加消费者
最常被跳过的细节：多个分库的 server_id 必须全局唯一，否则 Maxwell 会收不到部分实例的 event，而且这个值改完要重启 MySQL。
