主从复制是单向异步日志同步，集群是多节点协同的强一致系统；前者依赖binlog与i/o、sql线程异步回放，存在秒级延迟，后者要求多数节点落盘才提交，rpo=0但写入延迟高。
主从复制是单向异步日志同步，集群是多节点协同的强一致系统
主从复制本质是「主库写完就返回，从库慢慢追」——靠 binlog + I/O Thread + SQL Thread 三段式异步拉取回放，延迟从几十毫秒到数秒不等。集群（如 mysql Cluster 或 Galera）则要求事务在多数节点落盘后才提交，靠 ndbd（数据节点）或 wsrep（Galera 插件）实现同步/准同步确认，RPO=0，但写入延迟明显上升。
常见错误现象：SHOW SLAVE STATUSG 显示 Seconds_Behind_Master 持续增长；而集群中某个 ndb_mgmd 管理节点宕机，ndb_mgm -e "show" 仍显示全部数据节点 Started，业务无感知。
- 主从适合读多写少、能容忍秒级延迟的场景，比如 CMS、后台报表
- 集群必须部署在低延迟局域网（
- 主从用社区版 MySQL 即可，集群必须用专用版本（如
mysql-cluster-community-server），不兼容外键、大事务、复杂 JOIN
主从只支持单点写入，集群默认多主可写
主从架构里 read-only=ON 是硬性约束，一旦从库误执行 INSERT，就会导致 GTID 冲突或主从数据错位；而集群（如 Galera）所有节点都开放写权限，应用可直连任意节点，负载天然均衡，无需中间件做路由。
但这也带来新问题：集群写冲突无法靠数据库自动解决。例如两个节点同时更新同一行，会触发 WSREP: Conflict detected，其中一个事务被强制回滚——这和 InnoDB 行锁逻辑不同，是基于全局事务序号（seqno）的乐观并发控制。
- 主从切换需人工干预或依赖
MHA/Orchestrator，切换期间写服务中断 - 集群故障转移是自动的：
ndb_mgmd检测到数据节点失联，1–2 秒内重平衡分片，剩余节点继续提供读写 - 主从加从库只能扩展读能力；集群加数据节点可线性提升写吞吐（前提是分片键设计合理）
主从每台机器存全量数据，集群自动分片、节点只存部分数据
主从复制下，每个从库都是完整副本，扩容靠堆机器，磁盘和内存开销线性增长；MySQL Cluster 是 shared-nothing 架构，表按主键哈希自动切分，ndbd 节点只存自己负责的那部分数据，整体容量和并发能力可水平扩展。
这意味着：主从做备份只需 mysqldump 或 xtrabackup 备一份；而集群备份必须用 ndb_mgm -e "START BACKUP"，否则只备份 SQL 节点会丢数据——因为数据根本不在 mysqld 进程里。
- 主从不支持自动分片，想分库分表得靠应用层或中间件（如
ShardingSphere） - 集群分片逻辑对应用透明，但跨分片
JOIN或ORDER BY性能极差，必须避免 - 主从重建从库：
mysqldump导出 +CHANGE MASTER TO；集群重建节点：停掉ndbd→ 清空数据目录 →ndbd --initial→ 自动同步
配置和运维复杂度差异极大，别拿主从经验套集群
主从配置几行 my.cnf + 一条 CHANGE MASTER TO 就能跑起来；集群要协调管理节点（ndb_mgmd）、数据节点（ndbd）、SQL 节点（mysqld）三类角色，网络、内存、磁盘、时钟同步全都要调优。
最容易被忽略的是：集群对系统资源极其敏感。比如 ndbd 默认使用 8GB 内存，但若实际数据只有 2GB，却未调小 DataMemory 和 IndexMemory，会导致内存浪费甚至 OOM；而主从即使 innodb_buffer_pool_size 配大了，顶多是缓存冗余。
- 主从监控看
Seconds_Behind_Master和Slave_IO_Running/Slave_SQL_Running - 集群监控必须盯住
ndb_mgm -e "show"中的Connected状态、MaxNoOfConcurrentOperations是否打满、以及各节点MemoryUsage百分比 - 主从升级可滚动重启；集群升级必须停全部
ndbd节点，且要求版本严格一致，否则ndb_mgmd拒绝加入
主从和集群不是“升级关系”，而是两种不同设计哲学的产物：一个求稳、易控、成本低；一个求极致可用与扩展，但代价是复杂度陡增、事务能力受限、运维门槛高。选错方案比没做高可用更危险。