1 Mysql主从复制工作原理
1.Master 数据库只要发生变化，立马记录到Binary log 日志文件中
2.Slave数据库启动一个I/O thread连接Master数据库，请求Master变化的二进制日志
3.Slave I/O获取到的二进制日志，保存到自己的Relay log 日志文件中。
4.Slave 有一个 SQL thread定时检查Realy log是否变化，变化那么就更新数据
2 Mysql主从复制方式
（1）主库刷盘策略
为了保证Binlog的安全，MySQL引入sync_binlog参数来控制BINLOG刷新到磁盘的频率。
sync_binlog=1，表示事务提交之前，MySQL都需要先把BINLOG刷新到磁盘，这样的话，即使出现数据库主机操作系统崩溃或者主机突然掉电的情况，系统最多损失prepared状态的事务
sync_binlog=0，表示MySQL不控制binlog的刷新，由文件系统自己控制文件缓存的刷新
sync_binlog=N，如果N不等于0或者1，刷新方式同sync_binlog=1类似，只不过此时会延长刷新频率至N次binlog提交组之后
（2）异步复制
MySQL主从异步复制是最常见的复制场景。数据的完整性依赖于主库BINLOG的不丢失，只要主库的BINLOG不丢失，那么就算主库宕机了，我们还可以通过BINLOG把丢失的部分数据通过手工同步到从库上去。
异步复制模式下，主库和从库的数据之间会存在一定的延迟。这样存在一个隐患：
如上图，当在主库上写入一个事务并提交成功，而从库尚未得到主库的BINLOG日志时，主库由于磁盘损坏、内存故障、断电等原因意外宕机，导致主从不一致。
（3）半同步复制
为了保证主库上的每一个BINLOG都能够被可靠地复制到从库上，MySQL引入了半同步复制。
传统半同步
传统半同步的处理流程是，主库在每次事务成功提交时，并不及时反馈给前端应用用户，而是等待至少一个从库接收到BINLOG事务并成功写入中继日志后，主库才返回Commit操作成功给客户端。
传统半同步复制保证了事务成功提交后，至少有两份日志记录，一份在主库的BINLOG日志上，另一份在至少一个从库的中继日志Relay Log上，从而更进一步保证了数据的完整性。
然而在传统的半同步复制中，主库写数据到BINLOG，且执行Commit操作后，会一直等待从库的ACK，即从库写入Relay Log后，并将数据落盘，返回给主库消息，通知主库可以返回前端应用操作成功，这样会出现一个问题，就是实际上主库已经将该事务Commit到了事务引擎层，应用已经可以可以看到数据发生了变化，只是在等待返回而已，如果此时主库宕机，有可能从库还没能写入Relay Log，就会发生主从库不一致。
增强半同步
增强半同步复制就是为了解决上面的问题，做了微调，即主库写数据到BINLOG后，就开始等待从库的应答ACK，直到至少一个从库写入Relay Log后，并将数据落盘，然后返回给主库消息，通知主库可以执行Commit操作，然后主库开始提交到事务引擎层，应用此时可以看到数据发生了变化。增强半同步复制的大致流程如下图所示。
从上图可以看出，增强半同步也并不完美。加入Master在接受到ACK之前发生宕机，此时BINLOG可能已经到达Slave，也可能没有到达Slave，想做到主从完全一致，仍然很困难。不过由于Master在接受到ACK之前，并不会给客户端应答，所以还是有机会做到强一致的，此处不展开讨论。
2.3 组复制（MGR）
2.3.1 定义
MGR 是一个新的高可用与高扩展的方案，集群中的任何节点数据都是一样的，可以实现任何节点都可以写入，实现了真正意义上的多主。
2.3.2 架构
API层：负责完成和MySQL Server的交互，得到Server状态，完成事务的管理。
组件层：主要包括3个特定组件
Capture负责收集事务执行的相关信息
Applier负责应用集群事务到本地
Recovery负责节点的数据恢复。
复制层：负责冲突验证，接收和应用集群事务。
集群通信层：基于Paxos协议的集群通信引擎，以及和上层组件的交互接口。
2.3.3 复制过程
事务在引擎层完成Prepare，写Binlog之前会被MySQL预设的钩子（Hook）before_commit拦截
在MGR层，事务执行相关的信息打包，通过Paxos一致性协议（Consensus）进行全局排序后发送给MGR各个节点
当超过半数（N/2+1）的节点（包括它自己）回应后，发送消息告诉所有节点，这个数据包同步成功
各节点独自进行认证（Certify）
若认证通过，本地节点写Binlog完成提交
异地节点写Relay Log（常规主从同步使用的relaylog不是同一组），由建立的复制通道（Replication Channel）group_replication_applier完成事务并行回放
若认证不通过，就会进行回滚（Rollback）
2.3.4 模式
单主模式
在此模式下，组有一个设置为读写模式的单主server。 组中的所有其他成员被自动设置为只读模式（超级只读模式）。主服务器通常是用于引导组的第一个server，所有其他加入的server自动从主服务器同步并设置为只读。
多主模式
在多主模式下，没有单主模式的概念。没有必要使用选主程序，因为不同server成员之间没有 什么特殊的差异。
3.总结
即使目前MySQL的高可用和数据一致性有很多方案，但是我们还不能完全兼顾可用性和一致性，所以我们选择方案时要根据我们业务需求，合理选择
