MySQL 主从复制（Replication）是构建高可用与高性能数据库架构的核心技术之一，它通过在多台数据库实例间同步数据，来实现读写分离、负载均衡和数据备份。
根据主库确认从库接收并应用事务的方式，MySQL的复制主要分为三种模式：异步复制、半同步复制与全同步复制。
MySQL异步复制
异步复制是MySQL默认且最传统的复制方式。
在此模式下，主库在事务提交后立即返回结果给客户端，而不会等待任何一个从库接收或应用该事务。从库通过其I/O线程异步地从主库的二进制日志（binlog）中读取事件，然后由SQL线程在本地执行这些事件，从而实现数据同步。
优点：
- 延迟极低：主库提交速度最快，完全不受从库性能和网络状况的影响。
- 实现简单，开销小：对主库性能影响最小，非常适合写操作密集型的应用场景。
缺点：
- 存在数据丢失风险：若主库发生故障，那些已提交但尚未复制到任何从库的事务将会永久丢失。
- 无法保证数据的强一致性，只能达到最终一致性。
适用场景：对写入延迟敏感，且可以容忍在极端故障下少量数据丢失的系统。这是大多数OLTP（在线事务处理）应用进行读扩展时采用的常规方案。
MySQL半同步复制
半同步复制对异步复制进行了增强。主库在事务提交后，会至少等待一个从库确认已接收到该事务的binlog事件（即事件已写入从库的中继日志或内存缓冲区），然后才向客户端返回成功响应。但它并不等待从库将事务完全执行（应用）完毕。
优点：
- 显著降低数据丢失风险：至少保证了binlog传输到了一个从库，在主库崩溃时，可以从此从库恢复绝大部分已提交的数据。
- 在可接受的性能开销内，提供了比异步复制更强的一致性保证。
缺点：
- 增加了主库提交的延迟：提交时间会受到网络状况和所等待从库响应速度的影响。
- 配置不当可能引发问题：如果被指定为同步的从库发生故障或网络中断，可能导致主库写操作阻塞或性能下降（取决于具体配置参数）。
适用场景：对数据可靠性有较高要求，但又无法完全承担全同步复制带来的性能开销的业务系统。例如金融领域的非核心交易系统，或对关键写操作需要更强保障的应用。
MySQL全同步复制
全同步复制要求最为严格。主库在事务提交前，必须等待所有（或指定数量）的从库确认已接收 并 应用了该事务，确保多个节点间实现严格的同步提交，以此达到强一致性。
优点：
- 提供强一致性保障：多个节点间的数据保持实时同步，主节点故障时几乎可以实现零数据丢失。
- 便于实现自动故障切换与集群管理（具体依赖于集群管理组件的实现）。
缺点：
- 性能开销巨大：同步等待所有从库执行完毕会显著增加写操作的延迟，网络拓扑和从库性能的影响被放大。
- 实现与运维复杂：通常需要依赖额外的集群组件（如Group Replication），配置和运维成本高，在高延迟网络环境下扩展性受限。
适用场景：对数据一致性与零丢失有强制性要求的关键核心业务。例如金融核心交易系统、支付清算系统或任何要求主备节点数据必须严格一致的应用。
理解这三种复制模式的原理与差异，是设计稳定可靠的数据库架构的基础。希望本文的梳理能帮助你根据自身业务对一致性、可用性和性能的需求，做出合适的技术选型。更多关于数据库与分布式架构的深度讨论，欢迎在云栈社区与大家交流。 | 
发表于 18 小时前
|
查看: 4|
回复: 0
