mysql主从复制和集群有什么不同_mysql架构对比解析

主从复制是单向异步数据同步，仅主库可写；集群支持多节点并发写入，通过共识协议保证一致性。主从用CHANGE MASTER TO配置，集群需dba.createCluster()等专用初始化；主从延迟常见，集群写失败可能全事务回滚。

主从复制是单向数据同步，集群是多节点协同服务

mysql 主从复制本质是一主多从的异步（或半同步）数据拷贝，写操作只发生在主库，从库仅提供读扩展或灾备；而集群（如 InnoDB Cluster、MGR 或第三方方案如 Percona XtraDB Cluster）要求多个节点具备写能力，通过共识协议（如 Paxos、Raft）保证事务一致性，节点间实时同步状态。

• CHANGE MASTER TO 是主从复制的起点，但集群初始化必须用 dba.createCluster()（MGR）或 pxc_strict_mode 配置（PXC）
• 主从延迟常见于大事务、网络抖动或从库 IO 压力大；集群中若一个节点写入失败，可能触发整个事务回滚，错误信息类似 ER_GROUP_REPLICATION_appLIER_STOPPED
• 主从架构下应用需自行路由读写（如用 mysql-router 或中间件），集群则可配置为 multi-primary 模式，任意节点接受写请求

主从不解决单点写入瓶颈，集群试图消除写单点

主从复制无法提升写吞吐——所有写请求仍压在主库，只是把读请求分流出去；集群通过分布式事务协调，允许并发写入多个节点，但代价是更高的延迟和更严的事务限制（例如 MGR 要求表必须有主键，且不支持 select ... for UPDATE 在非本地节点生效）。

• 主从切换靠 STOP SLAVE; RESET SLAVE; 手动或借助 orchestrator 自动完成，存在秒级甚至分钟级不可写窗口
• MGR 集群故障转移由组通信层自动触发，新主选举后通常
• 主从适合报表、备份、读多写少场景；集群适合金融类强一致、高可用写场景，但对网络稳定性极度敏感——跨机房部署 MGR 很容易因 group_replication_member_expel_timeout 触发误驱逐

binlog 格式和 GTID 对主从影响大，对集群是强制前提

主从可以运行在 STATEMENT 模式下（不推荐），也能关闭 GTID；但 MGR 要求必须开启 GTID_MODE = ON 且 BINLOG_FORMAT = ROW，否则启动直接报错 ERROR 3092 (HY000): The server is not configured properly to be an active member of the group。

• SHOW BINLOG EVENTS IN 'mysql-bin.000001' 可查主从复制原始日志，但集群中 binlog 仅用于本地持久化，组内同步走的是 group_replication_applier 线程和专用的 group_replication_recovery 通道
• 主从中跳过错误可用 SET GLOBAL sql_slave_skip_counter = 1（已弃用）或 START SLAVE SQL_THREAD UNTIL ...；集群中不能跳过事务，只能停集群、清空 mysql.group_replication_groups 表并重搭
• GTID 开启后，主从切换更可靠，但要注意 gtid_purged 不匹配会导致 ERROR 1236 (HY000) —— 集群节点加入前必须确保其 gtid_executed 是其他节点的子集

监控指标完全不同：主从看 Seconds_Behind_Master，集群看 MEMBER_STATE

主从复制延迟用 SHOW SLAVE STATUSG 中的 Seconds_Behind_Master 判断，但该值在 IO 线程卡住时可能为 NULL 或长期为 0 却实际不同步；集群必须查 performance_schema.replication_group_members，关键字段是 MEMBER_STATE（ONLINE/RECOVERING/OFFLINE）和 MEMBER_ROLE（PRIMARY/SECONDARY）。

• 主从中 Slave_IO_Running: No 表示网络或主库权限问题；集群中 MEMBER_STATE: RECOVERING 持续超时，大概率是 group_replication_recovery 线程拉取 binlog 失败，需检查 auto_position=1 和主库 binlog_checksum 设置
• 主从延迟告警阈值设为 60 秒较合理；集群中只要出现 MEMBER_STATE != 'ONLINE' 就应立即介入，因为非 ONLINE 状态意味着该节点已脱离共识组，不再参与投票
• 不要依赖 SHOW PROCESSLIST 查集群同步线程——真正干活的是 plugin_group_replication 后台模块，它不暴露在线程列表里

复杂在于：主从是“能跑就行”的松散耦合，集群是“全有或全无”的紧密协同。一个参数配错、一次网络分区、甚至系统时间不同步（>1s），都可能导致集群反复震荡，而这些问题在主从中往往只是慢一点、延迟高一点。