主从复制是单向异步日志同步，集群是多节点协同的强一致系统
主从复制本质是「主库写完就返回，从库慢慢追」——靠
binlog+
I/O Thread+
SQL Thread三段式异步拉取回放，延迟从几十毫秒到数秒不等。集群（如 MySQL Cluster 或 Galera）则要求事务在多数节点落盘后才提交，靠
ndbd（数据节点）或
wsrep（Galera 插件）实现同步/准同步确认，RPO=0，但写入延迟明显上升。
常见错误现象：
SHOW SLAVE STATUS\G显示
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拒绝加入 主从和集群不是“升级关系”，而是两种不同设计哲学的产物：一个求稳、易控、成本低；一个求极致可用与扩展，但代价是复杂度陡增、事务能力受限、运维门槛高。选错方案比没做高可用更危险。
