主从复制是单向异步数据同步，仅主库可写；集群支持多节点并发写入，通过共识协议保证一致性。主从用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 在非本地节点生效）。
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 主从切换靠
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 STATUS\G 中的 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后台模块，它不暴露在线程列表里
