。
早期MySQL保证数据一致性的方案，核心是基于二进制日志（binlog）的主从复制，并围绕它构建了读写分离和双机热备等架构。在保障数据一致性方面存在明显的缺陷，做运维的人都深有体会。
这是当时最基础的架构，所有高级方案都建立在此之上。
基本原理 ：主库（Master）将所有数据变更写入
binlog；从库（Slave）的I/O线程拉取这些日志并写入本地relay log，随后SQL线程重放日志中的SQL语句，从而实现数据同步。整个过程默认是异步的。读写分离 ：基于此架构，将写操作 指向主库，读操作分散到多个从库，以此提升系统整体的吞吐能力
早期增强一致性的辅助手段
为了改善数据一致性，当时也有一些辅助实践：
-
半同步复制（Semi-Synchronous Replication） ：MySQL 5.5引入。主库需等待至少一个从库 确认收到
binlog后，才向客户端返回成功。这降低了数据丢失风险，但可能增加写入延迟，且仍有退化回异步复制的可能。 -
行级复制（Row-Based Replication, RBR） ：MySQL 5.1引入。
binlog记录的是数据行的实际变更 （如某行某字段从A变为B），解决了基于语句复制（SBR）在使用NOW()等非确定性函数时的数据不一致问题。 -
第三方工具 ：如MHA（Master High Availability），可在主库故障时，自动将数据最接近的从库提升为新主库，并尝试补录差异数据，尽量减少数据丢失。
方案的局限性
受限于当时技术，这些方案普遍存在以下痛点：
-
数据丢失风险：异步复制下，主库崩溃时，尚未同步到从库的事务可能永久丢失。
-
主从延迟：从库同步必然存在延迟，在读写分离场景下会导致用户读到旧数据。
-
切换复杂且有风险：早期缺乏自动化高可用工具，故障转移常需人工介入，过程复杂且易出错。
-
复制中断与不一致：网络问题或从库执行出错可能导致复制中断；而基于语句的复制（SBR）本身就存在导致主从数据不一致的隐患。
总的来说，这些早期方案是MySQL在高可用和数据一致性探索上的重要阶段，为后续更成熟的GTID 、增强半同步 和**MGR（MySQL Group Replication）**等技术的诞生奠定了基础
| 特性 | GTID | 增强半同步 | MGR (组复制) |
|---|---|---|---|
| 核心思想 | 为事务提供全局唯一ID | 主库等待从库确认接收binlog | 基于共识协议的集群决策 |
| 主要解决的问题 | 简化主从切换和复制管理 | 防止 主库故障时的数据丢失 | 提供数据强一致性 和自动高可用 |
| 数据一致性 | 高 (基于事务) | 较高 (无损复制) | 最高 (基于Paxos的强一致) |
| 性能影响 | 低 | 中等 (取决于网络和从库性能) | 较高 (多数节点确认带来延迟) |
| 复杂度 | 低 | 中等 | 高 |
| 适用场景 | 需要自动化运维 和简化故障切换的场景 | 对数据安全有较高要求的大多数核心业务 | 金融、支付 等对数据一致性要求极高的核心系统 |
当今最主流的方案归纳为四大范式，根据业务对"一致性"和"可用性"来权衡。
范式一：经典自治架构（业界绝对主流）
核心组合 ：GTID + 增强半同步复制（AFTER_SYNC）+ Orchestrator（或MHA）
定位 ：大多数互联网业务的"黄金标准"，在性能、一致性和运维成本间取得最佳平衡。
-
怎么玩 ：采用一主多从，所有事务必须等待至少一个从库确认Binlog落盘 后才提交（保证无损）。搭配
Orchestrator这类工具，它能实时探测拓扑，在主库宕机时自动计算各从库的Binlog差异，选出数据最完整的从库一键提升为新主。 -
杀手锏 ：相比老旧的MHA，
Orchestrator支持拓扑可视化 和故障后自动恢复，且能优雅处理网络分区（避免错误切换）。 -
隐患：仍是"单点写"，且极端情况下（所有从库都来不及同步时）仍有极小概率丢数据，但已满足99.9%的场景。
范式二：官方原生集群架构（未来演进方向）
核心组合 ：MySQL InnoDB Cluster（MGR组复制 + MySQL Router）
定位 ：MySQL官方钦定的"下一代"高可用方案，解决脑裂和手工切换的痛点。
-
怎么玩 ：底层基于MGR（组复制） 的Paxos共识协议，事务需集群多数派节点（>N/2） 投票通过才提交，天然保证数据强一致。上层配套
MySQL Shell提供一键部署脚本，MySQL Router作为轻量级中间件，自动感知集群主节点变化并将写流量路由到正确节点。 -
杀手锏 ：内置自动化防脑裂机制 （成员自动驱逐），且支持单主/多主模式切换（虽官方建议生产用单主）。
-
代价 ：对网络延迟极其敏感（建议<10ms内网），且性能损耗高于异步复制，适合金融级核心交易系统。
范式三：同步多写架构（严苛一致性场景）
核心组合 ：Galera Cluster for MySQL 或 Percona XtraDB Cluster (PXC)
定位 ："几乎零延迟"的同步复制，适合需要任意节点读写且不允许丢数据的极端场景。
-
怎么玩 ：基于Certification-Based Replication（基于认证的复制） ，事务在本地执行后需广播给所有节点进行全局冲突认证，所有节点同时提交或同时回滚。它提供真正的"多主写入"，且节点加入集群时通过State Snapshot Transfer（SST）自动同步数据。
-
杀手锏：读性能极佳（本地读），且故障节点恢复后能自动增量同步（IST）。
-
致命伤 ：写入性能受限于集群中最慢的节点；且在大事务或网络抖动时，极易引发整个集群的"流控"（Flow Control），导致TPS骤降。
范式四：云原生解耦架构（未来的形态）
核心组合 ：AWS Aurora / 阿里云PolarDB 的 共享存储（Shared-Storage） 架构
定位 ：重新定义"主从"，将计算与存储分离，从底层物理日志层面解决复制延迟。
-
怎么玩 ：主从节点不再通过传输
Binlog重放SQL来同步，而是将Redo Log 写入共享的分布式存储卷（如云盘）。从库（称为"Replica"）直接读取存储卷上最新的数据页，省去了SQL回放过程，从物理层面实现极低延迟（毫秒级）。 -
杀手锏 ：支持**"快照回滚"** 和**"秒级添加只读节点"** ，且由于日志是持久化到共享存储的，主库宕机时无需"补录Binlog"，新的主库瞬间就能在存储层拿到完整数据，数据零丢失（RPO=0）。
-
门槛：深度绑定特定云厂商，存在技术锁定，且成本较高。
终极选型速查
如果非要给一个当下的"标准答案"：
-
初创或常规业务 ：直接采用云厂商的RDS托管服务（本质是范式一的封装），让平台替你做自动备份和HA切换。
-
自建机房且不想太折腾 ：采用 范式一（GTID + 增强半同步 + Orchestrator），这是目前社区生态最成熟、踩坑最少的路子。
-
交易、支付等高要求的核心链路 ：优先考虑 范式二（InnoDB Cluster），因为它有官方的标准化支持，且能彻底解决困扰DBA多年的"主从切换后数据错乱"问题。
-
对多机房容灾有要求 ：可以结合 半同步 + 跨机房专线，或直接使用云原生的跨AZ部署方案（范式四）。
下期将详细介绍每种范式的实操过程