《亿级流量系统架构设计与实战》MySQL高可用架构

主从模式

一台MySQL服务器作为Master（主节点）, 若干MySQL服务器作为Slave （从节点）。在正常情况下，只有Master处理写数据请求， 同时Master与Slave通过主从复制技术保持数据一致。当Master发生故障宕机时，某个 Slave会被提升为Master继续对外提供服务。

主从复制技术：

1. 当Master数据发生变更(包括新增、删除、修改等操作)时，Master将数据的变更日志写入二进制日志文件(binlog )。
2. 数据库Slave启动I/O线程并与Master建立网络连接，从Master的binlog中读取最新的数据变更日志。
3. Slave的I/O线程收到数据变更日志后，将其保存在中继日志文件(relay log)的尾部。
4. Slave启动专门的SQL线程从relay log中获取日志，并在本地重新执行SQL语句将数据回放到数据库中，使Slave数据库与Master数据库保持数据一致。

Master提交事务不需要经过Slave的确认，也不管Slave是否已接收binlog, Slave写relay log失败、重新执行SQL语句失败等异常情况并不会被Master感知,所以MySQL主从复制是异步的，Master提交完事务就直接返回了。

异步方式的主从复制有一个潜在隐患：如果Master在提交事务成功后，但尚未发送 binlog给Slave时就出现异常宕机了，那么对MySQL执行主从切换就会造成事务数据的丢失，因为被提升为新Master的Slave并未复制这个事务。为了解决数据丢失的问题， MySQL 5.5版本提供了半同步复制模式：Master在提交事务前，会等待Slave接收binlog, 当至少有一个Slave确认接收了 binlog后，Master才提交事务。具体来说，Slave在收到 binlog并将其写入relay log后，会向Master发送ACK响应；Master在收到ACK响应后， 认为响应发送方Slave已经在relay log中保存了事务，这时才进行事务的提交。

需要注意的是，在半同步复制模式下，Slave向Master发送ACK响应的时机并不是重新执行SQL语句后，而是事务数据被写入relay log后。这样一方面可以缩短Master等待响应的时间；另一方面，事务数据已经被持久化，不会发生丢失数据的情况。 半同步复制可以提高主从数据的一致性，但是Master提交事务要等待Slave的确认， 所以写性能会受到一定的影响。半同步复制适合对数据一致性要求较高的业务场景。 Master会因为向过多的Slave复制数据而压力倍增，这个问题被称为“复制风暴”。所 以实际的主从模式架构可能是一些Slave向Slave复制数据，以减轻Master的复制压力，

MHA(Master High Availability)

MHA用来检测节点故障和执行自动切换，它通常可以在10 ~ 30s内完成MySQL主从集群的自动 故障检测和自动主从切换，并且在主从切换过程中，它可以最大程度地保证主从数据的一 致性，以帮助MySQL主从模式达到真正意义的高可用。

MHA由两部分组成：MHA Manager (管理节点)和MHA Node (数据节点)。

• MHA Manager： MHA的“决策层”，负责自动检测Master的故障，检查主从复制 状态，执行自动主从切换等。MHA Manager可以管理多个MySQL主从集群，通 常被部署在单独的服务器上。
• MHA Node：被部署在每台MySQL服务器上，主要负责修复主从数据的差异。

MHA会实时监测每个MySQL主从集群的Master状态，如果某个Master宕机，MHA 则会自动选择数据最接近Master数据的Slave作为新的Master,然后将其他Slave重新指 向新的Master,整个故障转移过程自动化，且对业务方完全透明。

1. MHA Manager周期性地探测Master心跳，如果连续4次探测不到心跳，则认为 Master 宕机。
2. MHA Manager 判断各个 Slave 的 binlog,哪个 Slave 的 binlog 数据更接近 Master数据，就将哪个Slave作为备选Master。
3. MHANode试图通过SSH访问Master所在的服务器：
   • 如果网络可达，那么MHA Node可以获取到Master的binlog数据。MHA Node对 比Slave与Master的binlog数据，如果发现Slave数据与Master的binlog数据 有差异，则会将差异数据主动复制到Slave,以保持主从数据一致。
   • 如果网络不可达，那么MHA Node对比各个Slave的relay log差异，并做差异数 据补齐。
4. MHA Manager构建新主从关系，将备选Master提升为Master,其他Slave向新 的Master复制数据。

MHA选择数据最新的Slave作为新的MasterA Slave主动从Master binlog中补齐未复 制的数据、Slave之间互补数据等策略，都是为了最大程度地保证主从切换后不丢失数据。 如果将MHA和半同步复制模式一起使用，则可以更进一步大幅降低数据丢失的风险。因 为在半同步复制模式下有一个Slave的数据和Master数据一致，而MHA正好会选择这个 Slave作为新的Master。

MMM(Multi-Master Replication Manager for MySQL)

MMM是一个 MySQL 双主故障切换 和双主管理的脚本组件，从字面上理解，它有两个Master,并实现了这两个Master的高可用。

• Master 1:真正的Master,负责处理写请求。
• Master 2 (备用)：当Master 1宕机时，Master 2接替它作为新的Master处理写请 求Master 2与Master 1相互复制数据，一般采用半同步复制模式。
• Slave (若干):向Master 1复制数据，并且为了不影响Master 1的性能，采用异 步复制模式。
• mmm-monitor: monitor角色，与各mmm-agent通信以检测MySQL服务器的健康 状况，并决策是否主从切换。
• mmm-agent：被部署在每台MySQL服务器上，作为节点代理与monitor通信，一 方面监控本机MySQL状态，另一方面执行monitor下发的指令。
• write vip： MySQL对外提供写数据服务的虚拟IP地址，只与Master 1和Master 2 其中一个节点绑定。
• read vid： MySQL对外提供读数据服务的虚拟IP地址，主要与Slave绑定。

mmm故障转移过程：

1. agent检测到Master 1宕机，或者monitor与Master 1 agent在一段时间内通信失 败，monitor认为Master不可用。
2. monitor请求 Master 1 agent,要求 Master 1 移除 write vipo 如果 Master 1 所在的 机器无法访问，则跳过这一步。
3. monitor 请求 Master 2 agent,要求 Master 2 绑定 write vip,绑定成功后，Master 2 成为Master对外提供服务。
4. monitor 请求 Slave agent,要求 Slave 向 Master 2 复制数据。

MMM通过移动虚拟IP地址(write vip)的方式切换Mastero当Master 1宕机时， Master 2可以立即“上任”，MySQL业务使用方不会感知到主从切换的发生。不过，MMM 这套解决方案比较古老，不支持MySQL GTID,且社区活跃度不够，目前MMM组件处于 无人维护的状态。

MGR(MySQL Group Replication, MySQL 组复制)

特性：

• 一致性高：数据复制基于分布式共识算法Paxos,可以保证多个节点数据的一致性。
• 容错性高：只要不是超过一半的节点宕机，就可以继续对外提供服务。
• 灵活性强：MGR支持单主模式和多主模式。在单主模式下会自动选举Master,在多 主模式下每个MySQL节点都可以同时处理写请求。

至少由3个MySQL节点组成一个复制组，一个事务必须经过复制组内超过一半的节点决议通过后才能提交。3个节点组成一个复制组,Consensus层为Paxos 一致性协议层，在事务提交过程中组内节点进行决议(certify),至少有2个节点决议通过， 这个事务才能够提交。

如果在不同的MySQL节点上执行不同的写操作发生了事务冲突，那么先提交的事务先执行，后提交的事务被回滚。在多主模式下，由于每个MySQL节点都可以执行写请求， 在写请求高并发的场景下发生事务冲突的概率较大，会造成大量的事务回滚，所以官方更推荐单主模式。 在单主模式下，MGR会自动为复制组选择一个Master负责写请求。如果复制组内超 过一半的节点与Master通信失败，则认为Master宕机，MGR自动根据各节点的权重和ID标识重新选主，并很容易在各Slave之间达成共识。 由于MGR基于Paxos协议，所以主从节点数据有很强的一致性，可以做到数据不丢 失。此外，在一个拥有2N+1个节点的复制组中，MGR可以容忍N个节点发生故障，所以这套方案的容错性也很高。 不过，数据强一致性的代价是每个写请求都涉及与复制组内大多数节点的通信，所以 MGR的写性能不及异步复制和半同步复制，MGR更适合要求数据强一致性，且写请求量不大的场景。

---

阶段	代表方案	特点	解决的问题	局限性
1. 基础主从复制	异步主从复制	- Master 写，Slave 读 - 异步复制（Binlog → Relay Log → SQL线程回放）	读写分离、负载均衡	数据可能丢失（Master 宕机前未同步 Binlog）
2. 增强数据一致性	半同步复制	- Master 提交事务需等待 ≥1 Slave 确认收到 Binlog	降低数据丢失风险	写性能下降（需等待 Slave ACK）
3. 自动化故障切换	MHA	- 自动检测 Master 故障 - 选择数据最新的 Slave 提升为新 Master - 补齐差异数据	快速切换（10~30s）、最大程度保证数据一致性	需额外部署 Manager/Node 节点、配置复杂
4. 双主架构探索	MMM	- 双 Master 互备（Active-Standby） - 虚拟 IP 漂移（Write VIP）	避免单点故障、切换更平滑	已淘汰（社区停止维护）、不支持 GTID、脑裂风险高
5. 原生强一致性方案	MGR	- 基于 Paxos 协议分布式共识 - 单主/多主模式 - 事务需多数节点认证后提交	数据强一致性、高容错（容忍 N/2 节点故障）、无需外部工具	写性能较低（多节点通信开销）、冲突事务回滚（多主模式）