主从复制是单向异步数据同步，仅主库可写；集群支持多节点并发写入，通过共识协议保证一致性。主从用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。
