MySQL 主从复制是现代数据库架构的基石，是读写分离、数据备份、高可用容灾的基础。几乎所有线上生产环境的 MySQL，都会部署至少一主一从的架构。但很多开发者对主从复制的理解，只停留在 "配置一下就能用" 的层面，对其底层原理和复制模式的差异一知半解。

面试时，面试官也不会问你 "怎么配置主从复制"，而是会追问：

• 主从复制的底层是怎么工作的？三个线程分别负责什么？
• 为什么主从复制会有延迟？
• 异步、半同步、全同步复制到底有什么区别？
• 线上生产环境应该用哪种复制模式？

这篇文章，我们就聚焦 MySQL 主从复制最核心的两个部分：底层实现原理和三种复制模式，带你彻底搞懂主从复制的本质。

一、主从复制的核心原理：基于 binlog 的异步复制

MySQL 主从复制的核心，是binlog（归档日志）。整个复制过程完全基于 binlog 实现，是 MySQL 原生支持的功能，不需要任何第三方中间件。

1. 为什么是 binlog？

binlog 是 MySQL Server 层的日志，记录了所有修改数据的 SQL 语句（查询语句不会记录）。它有两个核心特性，完美适配主从复制的需求：

• 顺序写入：binlog 是追加写的，写入性能极高；
• 幂等性：binlog 记录的是数据修改的完整过程，在从库上重放可以得到和主库完全一致的结果。

主从复制的本质，就是主库把自己的 binlog 发送给从库，从库在本地重放 binlog，从而实现数据的同步。

2. 三个核心线程

主从复制涉及三个核心线程，一个运行在主库，两个运行在从库：

线程	运行位置	核心职责
Dump 线程	主库	当从库连接到主库时，主库会为每个从库创建一个独立的 Dump 线程，负责读取本地的 binlog，按顺序发送给从库
IO 线程	从库	负责连接到主库，向主库发送 binlog 拉取请求，然后将收到的 binlog 写入本地的 relay log（中继日志）
SQL 线程	从库	负责读取本地的 relay log，解析并按顺序重放其中的 SQL 语句，将主库的修改同步到从库

这里有一个非常重要的细节：主库会为每个连接的从库创建一个独立的 Dump 线程。也就是说，如果有 10 个从库连接到主库，主库就会有 10 个 Dump 线程在运行。

3. 完整的复制流程

完整的主从复制流程分为三个环环相扣的步骤：

步骤 1：主库记录 binlog

主库执行完事务提交后，会将所有修改数据的操作，按照执行的先后顺序，记录到本地的 binlog 文件中。

注意：只有事务提交成功后，才会写入 binlog。如果事务回滚，不会写入 binlog，这保证了 binlog 中只包含有效的数据修改操作。

步骤 2：从库拉取 binlog

从库的 IO 线程会主动连接到主库，向主库发送一个 binlog 拉取请求，请求中会包含从库已经同步到的 binlog 文件名和偏移量。

主库的 Dump 线程收到请求后，会从指定的位置开始，读取本地的 binlog，按顺序发送给从库的 IO 线程。

从库的 IO 线程收到 binlog 后，会将其写入本地的 relay log 文件中，并更新自己的复制位置（binlog 文件名和偏移量），下次拉取时就从这个新的位置开始。

步骤 3：从库重放 binlog

从库的 SQL 线程会实时监控 relay log 文件，当发现有新的内容写入时，就会读取并解析其中的 SQL 语句，然后在从库上按顺序重放执行。

重放完成后，从库的数据就和主库保持一致了。

4. 关键特性：异步复制的本质

默认情况下，MySQL 主从复制是异步的。

也就是说，主库提交事务后，只需要将 binlog 写入本地磁盘，就可以立即返回客户端成功，不需要等待从库收到 binlog，更不需要等待从库重放完成。

这是主从复制性能高的根本原因 —— 主库的写入性能几乎不受从库数量的影响。但同时，这也是主从延迟产生的根本原因 —— 主库和从库之间存在天然的时间差。

二、主从复制的三种模式：性能与一致性的权衡

为了满足不同业务场景对数据一致性和性能的需求，MySQL 提供了三种主从复制模式：异步复制、半同步复制和全同步复制。

这三种模式的核心区别，在于主库提交事务后，返回客户端成功的时机不同。

1. 异步复制（Asynchronous Replication）

异步复制是 MySQL 最原始、也是默认的复制模式（MySQL 5.5 及之前）。

核心原理

主库提交事务后，立即将 binlog 写入本地磁盘，然后立即返回客户端成功。主库完全不关心从库是否收到了 binlog，也不关心从库是否重放完成。

主库和从库之间是完全异步的，主库的运行状态不受从库的任何影响。

优点

• 性能最高：主库的写入性能几乎和单库一样，不受从库数量和状态的影响；
• 实现简单：不需要额外的配置和依赖。

缺点

• 数据一致性最差：主库宕机时，可能有部分已经提交的 binlog 还没有发送到从库，导致数据丢失；
• 主从延迟不可控：从库的同步速度完全取决于自身的性能和负载。

适用场景

• 非核心业务，对数据一致性要求不高的场景；
• 日志统计、内容管理系统、历史数据查询等场景；
• 从库数量较多，对主库写入性能要求极高的场景。

2. 半同步复制（Semi-synchronous Replication）

为了解决异步复制数据丢失的问题，MySQL 5.5 引入了半同步复制，MySQL 5.7 对其进行了大幅优化，成为了目前线上生产环境的标准配置。

核心原理

主库提交事务后，不会立即返回客户端成功，而是等待至少一个从库收到 binlog 并写入 relay log 后，才返回客户端成功。

注意：半同步复制只需要等待从库收到binlog，不需要等待从库重放完成。只要从库将 binlog 写入了本地的 relay log，主库就可以返回成功。

MySQL 5.7 的重要改进

MySQL 5.5 的半同步复制有一个严重的缺陷：主库在等待从库响应时，会阻塞在提交阶段，导致其他事务也无法提交。

MySQL 5.7 引入了无损半同步复制（Lossless Semi-synchronous Replication），将等待时机从 "提交后" 提前到 "提交前"，解决了这个问题，同时保证了数据不会丢失。

优点

• 数据一致性较好：主库宕机时，至少有一个从库已经收到了所有提交的 binlog，不会丢失数据；
• 性能损失可控：性能比异步复制低 10%-20%，对于大多数业务来说完全可以接受。

缺点

• 性能比异步复制低：主库需要等待从库的响应，写入性能会有所下降；
• 主库会被从库阻塞：如果所有从库都宕机或网络延迟很高，主库会一直等待，直到超时（默认 10 秒），然后自动降级为异步复制。

适用场景

• 核心业务，对数据一致性要求较高的场景；
• 电商订单、金融支付、用户账户等不能丢失数据的场景；
• 绝大多数线上生产环境的标准配置。

3. 全同步复制（Synchronous Replication）

全同步复制是一致性最高的复制模式，也是性能最差的模式。

核心原理

主库提交事务后，需要等待所有从库都收到 binlog 并重放完成后，才返回客户端成功。

也就是说，只有当所有从库的数据都和主库完全一致时，主库才会告诉客户端事务提交成功。

优点

• 数据一致性最好：所有从库的数据和主库完全一致，不存在任何延迟；
• 读请求可以打到任意一个从库，永远不会读到旧数据。

缺点

• 性能极差：主库的写入性能会被最慢的那个从库拖垮；
• 可用性极差：任何一个从库宕机或网络延迟，都会导致主库无法提交事务，整个系统不可用。

适用场景

• 几乎没有线上业务使用；
• 只适用于对数据一致性要求极致严格、几乎没有并发写入的场景。

复制模式	主库返回时机	数据一致性	性能损失	可用性	适用场景
异步复制	写完本地 binlog 立即返回	最差，可能丢失数据	0%	最高	非核心业务、日志统计
半同步复制	至少一个从库收到 binlog 后返回	较好，不会丢失数据	10%-20%	较高	核心业务、电商、金融
全同步复制	所有从库重放完成后返回	最好，完全一致	50% 以上	最差	几乎不用

三、常见误区纠正

1. 误区：半同步复制是强一致性的。纠正：半同步复制只能保证数据不丢失，不能保证主从数据实时一致。从库还是会有延迟，只是不会丢失数据。

2. 误区：半同步复制需要等待所有从库响应。纠正：半同步复制只需要等待至少一个从库响应，不需要等待所有从库。

3. 误区：全同步复制和半同步复制是一回事。纠正：完全不同。半同步复制只需要等待从库收到 binlog，全同步复制需要等待所有从库重放完成。

4. 误区：MySQL 默认使用半同步复制。纠正：MySQL 5.5 及之前默认是异步复制，MySQL 5.7 及以后虽然支持半同步复制，但默认还是异步复制，需要手动开启。

四、高频面试题解答

1. 问：MySQL 主从复制的原理是什么？答：主从复制基于 binlog 实现，涉及三个核心线程：主库的 Dump 线程、从库的 IO 线程和 SQL 线程。完整流程分为三步：主库将修改操作记录到 binlog；从库的 IO 线程拉取 binlog 并写入本地 relay log；从库的 SQL 线程重放 relay log，同步数据到从库。

2. 问：主从复制为什么是异步的？答：为了保证主库的写入性能。如果是同步的，主库需要等待从库同步完成才能返回，写入性能会大幅下降。

3. 问：异步复制和半同步复制的核心区别是什么？答：主库返回客户端成功的时机不同。异步复制写完本地 binlog 就返回，可能丢失数据；半同步复制等待至少一个从库收到 binlog 后返回，不会丢失数据。

4. 问：半同步复制有什么优点和缺点？答：优点是数据不会丢失，一致性较好；缺点是性能比异步复制低 10%-20%，主库会被从库阻塞。

5. 问：线上生产环境应该用哪种复制模式？答：优先使用 MySQL 5.7 及以上版本的无损半同步复制，这是性能和一致性的最佳折中。

五、总结

MySQL 主从复制的本质，是基于 binlog 的异步数据同步。它通过三个核心线程的协作，实现了主库到从库的数据复制。

三种复制模式，本质上是在数据一致性和写入性能之间做不同的权衡：

• 异步复制追求极致性能，牺牲了数据一致性；
• 半同步复制在性能和一致性之间取得了最佳平衡，是线上生产环境的首选；
• 全同步复制追求极致的一致性，牺牲了性能和可用性，几乎没有实际应用。

理解了主从复制的原理和三种模式的差异，你就能根据自己的业务场景，选择最合适的复制模式，设计出稳定、可靠的数据库架构。