Mysql主从复制有哪些方式

MySQL 主从复制主要有以下几种方式，根据不同的分类标准（如同步机制、数据复制格式、拓扑结构等）可以分为：

---

一、按同步机制分类

1. 异步复制 (Asynchronous Replication)

• 原理：主库提交事务后，立即返回给客户端成功，无需等待从库确认。
• 特点：
  • 性能高，但数据一致性较弱（主从可能存在延迟）。
  • 主库崩溃时，未同步的数据可能丢失。
• 适用场景：对性能要求高、允许短暂数据不一致的场景（如读写分离、数据分析从库）。

2. 半同步复制 (Semi-Synchronous Replication)

• 原理：主库提交事务后，至少等待一个从库接收并写入 relay log 后才返回客户端确认。
• 特点：
  • 平衡了性能和数据一致性。
  • 若从库无响应，主库会退化为异步复制。
• 配置：需启用插件（如 rpl_semi_sync_master 和 rpl_semi_sync_slave）。
• 适用场景：要求较高数据一致性的场景（如金融业务）。

3. 全同步复制 (Fully Synchronous Replication)

• 原理：主库提交事务后，必须等待所有从库都提交事务后才返回成功。
• 特点：
  • 数据一致性最强，但性能影响大（延迟高）。
  • MySQL 原生不支持，需通过第三方工具（如 Galera Cluster）或组复制（Group Replication）实现。
• 适用场景：强一致性要求的分布式系统（如 MySQL Group Replication）。

---

二、按数据复制格式分类

1. 基于语句的复制 (Statement-Based Replication, SBR)

• 原理：主库将执行的 SQL 语句记录到二进制日志（binlog），从库重放这些语句。
• 优点：日志量小，节省存储和带宽。
• 缺点：
  • 不确定性语句（如 NOW(), RAND()）可能导致主从不一致。
  • 对存储过程、触发器的处理复杂。
• 配置：binlog_format = STATEMENT

2. 基于行的复制 (Row-Based Replication, RBR)

• 原理：主库将每行数据的变更记录到 binlog（如更新前后的整行数据）。
• 优点：
  • 数据一致性高，避免不确定性语句问题。
  • 适合批量数据变更场景。
• 缺点：日志量大（尤其是大表更新）。
• 配置：binlog_format = ROW

3. 混合模式复制 (Mixed-Based Replication, MBR)

• 原理：根据操作类型自动选择 SBR 或 RBR。
• 优点：兼顾性能和数据一致性。
• 配置：binlog_format = MIXED

---

三、按拓扑结构分类

1. 传统主从复制 (Master-Slave)

• 单主库，多个从库，从库只读。

2. 链式复制 (Master-Slave Chain)

• 从库作为其他从库的主库（级联复制），缓解主库压力。

3. 多源复制 (Multi-Source Replication)

• 一个从库同时从多个主库同步数据（MySQL 5.7+ 支持）。

4. 组复制 (Group Replication)

• 基于 Paxos 协议的多主同步集群（MySQL 5.7+ 的 InnoDB Cluster），支持自动故障转移。

---

四、其他特殊复制方式

1. 延迟复制 (Delayed Replication)

• 从库故意延迟一定时间再应用主库的 binlog（用于误操作恢复）。
• 配置：CHANGE REPLICATION SOURCE TO SOURCE_DELAY = N;（单位：秒）

2. GTID 复制 (Global Transaction Identifier)

• 通过全局唯一事务 ID 管理复制位置，简化主从切换。
• 配置：gtid_mode = ON

3. 并行复制 (Parallel Replication)

• 从库多线程应用 binlog，提升同步速度（需配置 slave_parallel_workers）。

---

总结

• 异步复制是默认方式，适合大多数场景。
• 半同步复制适合对数据一致性要求较高的业务。
• 组复制/全同步复制适合分布式强一致性需求。
• RBR 是推荐的数据复制格式（尤其 MySQL 8.0 默认）。

根据业务需求选择合适的方式，并结合监控工具（如 SHOW SLAVE STATUS）确保复制健康。