MySQL集群与主从复制可互补构建混合架构：集群（如MGR）负责单写强一致与自动故障转移，主从负责读扩展与分析类查询；须严格单向复制、分层监控与切换协同。
MySQL集群和主从复制可以互补结合，形成兼顾高可用、读写分离与数据强一致性的混合架构。核心思路是：用主从复制解决读扩展和基础容灾，用MySQL集群（如InnoDB Cluster、MGR或Percona XtraDB Cluster）解决多节点写入一致性与自动故障转移问题——二者不互斥，关键在分层定位。
明确角色分工：集群管写，主从管读
典型混合架构中，将InnoDB Cluster（基于MGR）作为核心写入层，三节点组成单写多读的高可用集群；再从集群的Primary节点引出1～2个异步从库，专用于报表、BI、历史查询等重读轻写场景。这样既保障了事务写入的强一致性（通过MGR的Paxos协议），又避免了集群内所有节点都承担读压力导致性能下降。
- 集群内节点间使用Group Replication，保证数据变更实时同步且自动选主
- 主从链路采用传统异步复制（ROW格式+GTID），降低对集群性能影响
- 读请求按业务类型路由：在线交易读走集群Secondary节点，分析类读走下游从库
避免环路与冲突：复制拓扑必须单向隔离
混合架构最易出错的是复制方向混乱。严禁让集群Secondary节点同时作为主从结构的Master，也禁止下游从库反向写回集群——这会引发主键冲突、GTID不连续、甚至集群分裂。正确做法是只允许“集群Primary → 独立从库”这一条单向通道，并在从库上设置read_only=ON和super_read_only=ON。
- 集群所有节点默认启用group_replication_enforce_update_everywhere_checks=OFF（单主模式下）
- 下游从库的my.cnf中显式配置replicate_ignore_db=mysql，防止权限表同步引发异常
- 定期校验SHOW REPLICA STATUS\G中的Seconds_Behind_Master和Retrieval/Execution线程状态
故障切换需分层响应：集群自动，主从手动或半自动
当集群Primary宕机，MGR会在几秒内完成新Primary选举，应用连接池需支持自动重连新主地址（推荐配合MySQL Router使用）。而下游从库不会自动切换源端——它仍连着原Primary的IP，此时需外部工具（如Orchestrator、MHA或自定义脚本）监听集群元数据变更，触发CHANGE REPLICATION SOURCE TO指令重连新Primary。
- MySQL Router可自动感知MGR拓扑变化，将应用请求动态转发至当前Primary或可用Secondary
- 建议为下游从库配置SOURCE_RETRY_COUNT=30和SOURCE_CONNECT_RETRY=10，避免短暂网络抖动导致复制中断
- 若使用VIP方案，确保VIP只漂移到集群Primary，不绑定到从库，防止误切
监控与备份策略要统一覆盖两层
集群节点和下游从库需纳入同一套监控体系。重点关注：MGR成员状态（performance_schema.replication_group_members）、复制延迟、GTID执行位置差值（pt-table-checksum校验集群Primary与下游从库的数据一致性
