一 简介:今天咱们来聊聊mgr的具体实现细节
二 关于多点写入的锁冲突问题以及处理:
certify模块主要负责检查事务是否允许提交，是否与其它事务存在冲突，如两个事务可能修改同一行数据。在单机系统中，两个事务的冲突可以通过*来避免，但在多主模式下，不同节点间没有分布式锁，所以无法使用*来避免。为提高性能，Group Replication乐观地来对待不同事务间的冲突，乐观的认为多数事务在执行时是没有并发冲突的。事务分别在不同节点上执行，直到准备提交时才去判断事务之间是否存在冲突
乐观锁通过使用数据版本（Version）记录机制实现 数据每更新一次，对此version值加一。
1 当我们提交更新的时候，判断数据库表对应记录的当前版本信息与第一次取出来的version值进行比对，如果数据库表当前版本号与第一次取出来的version值相等，则予以更新
2 版本号是共享且唯一的。
3 mgr对冲突事务的处理是回滚
三 关于MGR 如何选择新主的问题
1 当主节点宕掉，自动会根据服务器的server_uuid变量和group_replication_member_weight变量值，选择下一个slave谁作为主节点，group_replication_member_weight的值最高的成员被选为新的主节点，
2 在group_replication_member_weight值相同的情况下，group根据数据字典中 server_uuid排序，排序在最前的被选择为主节点
3 如果原主需要下线进行维护,那么可以直接stop复制,如果有目标新主,预先调整好权重即可.新主会进行识别
四 消息压缩（Message Compression）
这个压缩主要是指MySQL的bin-log压缩，所使用的压缩算法是LZ4。当网络带宽是瓶颈时，消息压缩可以在组通信级别提供高达30-40％的吞吐量改进，这在网络传输压力比较大的组中是尤为重要的。LZ4能很好的支持多线程环境，获得更高的压缩和解压速度。
经过压缩的binlog在传输到节点后会进行解压缩
默认情况下启用压缩，阈值为1000000字节（1MB）。压缩阈值（以字节为单位）可以设置为大于默认值。在这种情况下，只有具有大于阈值的有效负载的事务被压缩。下面是如何设置压缩阈值的示例。
压缩参数group_replication_compression_threshold= 2097152;
注意:修改此参数需要重启组复制,所以推荐在搭建时候预先设置好
六 关于日志
1 因为组复制同步还是基于二进制日志来进行同步的，清理某个节点bin-log时，必须判定这个日志文件是否还在使用，如果在使用，则绝对不能删除，如果删除，则整个集群直接ERROR。
2 expire_logs_days默认是0,就是不删除任何binlog日志,可以在每个节点进行自定义设置
3 在单模式下,主只写binlog,其他节点会写relay和本地binlog2种文件 在多主模式下,所有节点都会写relay和本地binlog
七 关于组复制的延迟问题
组复制的延迟对集群是有影响的，一旦出现延迟（默认延迟25000个事务），则启动流量控制（Flow Control），每个周期性能衰减当前的10%,直到集群不可用（但集群节点状态为online），单个节点慢整个集群全慢。
九 关于故障转移的问题
无论部署模式如何，组复制不处理客户端故障切换，它必须由应用程序本身、连接器或中间件框架（如代理或路由器）等处理。
十 高可用
1 一旦集群故障的节点超过阈值,整个集群变会被挂起,成为只读的状态,比如 3个节点,一旦挂掉2个 就会导致集群只读
计算方式 2n+1=total, n为故障节点的阈值
2 单个节点的状态只有到ERROR时才会被认为是不可用,踢出集群,视图发生变更
3 网络抖动问题可能导致集群的性能问题,所以要设置事务压缩和限制事务大小
十一 写集合
1 主键在MGR中主键是有着极其重要的地位，是判断是否冲突的重要依据,所以规定表必须有主键
2 写集合信息会封装进Transaction_context_log_event，同其他binlog event信息一起发送给其他节点
3 生成写集合的是在Innodb层完成更改操作，MySQL层写入binlog event之前。
十二 过程
0 MGR 在主节点执行,形成binglog_event+写集合
1 MGR 是先发送 写集合+binlog_event 到各个节点
2 从节点进行验证,验证通过后主节点写入binlog
3 binlog复制到从节点的relay-log,从节点读取relay-log进行应用 写到本地binlog 最后提交
4 整个事务顺利完成
十三 MGR 本身限制
1 不支持XA事务,外键和串行化操作
2 表需要有主键
3 只支持IPV4的网络
4 网络性能对于集群影响很大 ,需要低延迟,高带宽
5 现在限制最多9个节点
6 集群性能取决于最差的硬件机器,所以推荐所有硬件统一配置
7 官方推荐RC隔离级别,不过我觉得单主模式下RR是没有问题的
8 多主条件下的限制
1 针对同一对象但是不同实例的并发DML操作,在DDL操作执行完前,是有风险的,会存在 未检测到不同实例执行冲突的DDL语句风险
2 不支持同一对象但是不同实例的并发DDL操作
十四 关于多主的设计架构
1 采用轮训方式 haproxy+mgr多写,对于后端的三个节点随机进行读写
2 采用不同库不同节点进行读写,这样能减少多写模式下锁冲突的产生
3 多机房的架设,一部分在第一机房提供服务 另一部分在另一积分提供服务,但是需要考虑网络问题