1.主从模式
正常情况下，只有Master处理写数据请求，同时Master与Slave通过主从复制技术保持数据一致。当Master发生故障宕机时，某个Slave会被提升为Master继续对外提供服务。
主从复制原理：
- 1、当Master数据发生改变时，Master将数据的变更日志写入二进制日志文件binlog
- 2、数据库Slave启动IO线程，并与Master建立网络连接，从Master的binlog中读取最新的数据变更日志
- 3、Slave的IO线程收到数据变更日志后，将其保存在中继日志文件relay log的尾部
- 4、Slave启动专门的SQL线程从relay log中获取日志，并在本地重新执行SQL语句将数据回放到数据库中，使Slave数据库与Master数据库保持数据一致
MySQL主从复制是异步的，Master提交完事务就直接返回了。会存在丢失数据的风险。
MySQL 5.5提供了半同步复制模式
- Master提交事务前，会等待Slave接收binlog，当至少有一个Slave确认接收binlog后（数据被写入relay log后，并不是执行完SQL语句），Master才提交事务。
复制风暴：
- Master会因为向过多的Slave复制数据而压力倍增。
- 解决方案：Slave向Slave复制数据
2.MHA（Master High Availability）
如何检测节点故障和执行主从切换。
组成部分：
- MHA Manager：MHA是决策层，负责自动检测Master的故障，检查主从复制状态，执行自动主从切换等。
- MHA Node：被部署在每台MySQL服务器上，主要负责修复主从数据的差异。
MHA故障转移流程
- MHA Manager会周期性地探测Master心跳，如果连续4次探测不到心跳，则认为Master宕机
- MHA Manager判断各个Slave的binlog，哪个Slave的binlog数据更接近Master数据，就将哪个Slave作为备选Master
- MHA Node试图通过SSH访问Master所在的服务器（网络可达，补齐数据；网络不可达，Slave之间对比relay log差异，补齐数据）
- MHA Manager构建新主从关系，将备选Master提升为Master，其他Slave向新的Master复制数据
3.MMM（Multi-Master Replication Manager for MySQL）
MMM是一个MySQL双主故障切换和双主管理的脚本组件，它有两个Master，并实现这两个Master的高可用。
MMM通过移动虚拟IP地址的方式切换Master。当Master 1宕机时，Master 2可以立即上任，MySQL业务使用方不会感知到主从切换的发生。不过，MMM这套解决方案比较古老，不支持MySQL GTID，且社区活跃度不够，目前MMM组件处于无人维护的状态。
4.MGR（MySQL Group Replication）
MGR基于Paxos协议，所以主从节点数据有很强的一致性，可以做到数据不丢失。此外，在一个拥有2N + 1个节点的复制组中，MGR可以容忍N个节点发生故障，所以这套方案容忍性很高。
不过，数据强一致性的代价是每个写请求都涉及与复制组内大多数节点的通信，所以MGR的写性能不及异步复制和半同步复制，MGR更适合要求数据强一致性，且写请求量不大的场景。
