MySQL MGR架构

一、简介

MGR全称MySQL Group Replication（Mysql组复制），是MySQL官方于2016年12月推出的一个全新的高可用与高扩展的解决方案。MGR提供了高可用、高扩展、高可靠的MySQL集群服务。在MGR出现之前，用户常见的MySQL高可用方式，无论怎么变化架构，本质就是Master-Slave架构。MySQL 5.7版本开始支持无损半同步复制（lossless semi-syncreplication），从而进一步提示数据复制的强一致性。

MySQL Group Replication（MGR）是MySQL官方在5.7.17版本引进的一个数据库高可用与高扩展的解决方案，以插件形式提供。MGR基于分布式paxos协议，实现组复制，保证数据一致性。内置故障检测和自动选主功能，只要不是集群中的大多数节点都宕机，就可以继续正常工作。提供单主模式与多主模式，多主模式支持多点写入。

 

二、原理

2.1异步复制

master事务的提交不需要经过slave的确认，slave是否接收到master的binlog，master并不care。slave接收到master binlog后先写relay log，最后异步地去执行relay log中的sql应用到自身。由于master的提交不需要确保slave relay log是否被正确接受，当slave接受master binlog失败或者relay log应用失败，master无法感知。

假设master发生宕机并且binlog还没来得及被slave接收，而切换程序将slave提升为新的master，就会出现数据不一致的情况！另外，在高并发的情况下，传统的主从复制，从节点可能会与主产生较大的延迟（当然mysql后续版本陆续做了优化，推出了并行复制，以此降低异步复制的延迟）

2.2半同步复制

基于传统异步存在的缺陷，mysql在5.5版本推出半同步复制。可以说半同步复制是传统异步复制的改进，在master事务的commit之前，必须确保一个slave收到relay log并且响应给master以后，才能进行事务的commit。但是slave对于relay log的应用仍然是异步进行的，原理如下图所示:

2.3组复制

基于传统异步复制和半同步复制的缺陷——数据的一致性问题无法保证，MySQL官方在5.7.17版本正式推出组复制（MySQL Group Replication，简称MGR）。

由若干个节点共同组成一个复制组，一个事务的提交，必须经过组内大多数节点（N / 2 + 1）决议并通过，才能得以提交。如上图所示，由3个节点组成一个复制组，Consensus层为一致性协议层，在事务提交过程中，发生组间通讯，由2个节点决议(certify)通过这个事务，事务才能够最终得以提交并响应。

引入组复制，主要是为了解决传统异步复制和半同步复制可能产生数据不一致的问题。组复制依靠分布式一致性协议(Paxos协议的变体)，实现了分布式下数据的最终一致性，提供了真正的数据高可用方案(是否真正高可用还有待商榷)。其提供的多写方案，给我们实现多活方案带来了希望。

一个复制组由若干个节点(数据库实例)组成，组内各个节点维护各自的数据副本(Share Nothing)，通过一致性协议实现原子消息和全局有序消息，来实现组内实例数据的一致。

 

2.3.1单主模式

• 可以使用group_replication_set_as_primary()指定特定成员作为新的主数据库（MySQL 8.0.13或 更高版本）
• 如果自动选举，考虑的第一个因素是哪个或哪些成员运行最低的MySQL Server版本；
• 考虑的第二个因素是每个成员的成员权重，具体由group_replication_member_weight 系统变量 指定；
• 考虑的第三个因素是每个成员所生成的服务器UUID的字典顺序，由server_uuid系统变量指定，服 务器UUID最低的成员被选为主服务器

2.3.2多主模式

在mysql多主模式下,在组复制中通过Group Replication Protocol协议及Paxos协议，形成的整体高可用 解决方案 同时增加了certify的概念，负责检查事务是否允许提交，是否与其它事务存在冲突,Group Replication是由多个节点共同组成一个数据库集群，每个节点都可以单独执行事务，但是readwrite（rw）的操作只有在组内验证后才可以commit，Read-only (RO)事务是不需要验证可以立即执 行，当一个事务在一个节点上提交之前，会在组内自动进行原子性的广播，告知其他节点变更了什么内 容/执行了什么事务，然后为该事务建立一个全局的排序，最终，这意味着所有的服务器都以相同的顺 序接收相同的事务集。因此，所有服务器都按照相同的顺序应用相同的变更集，因此它们在组中保持一 致。

在多主模式下，该组的所有成员都设置为读写模式，在多主模式下，不支持SERIALIZABLE事务隔 离级别，且不能完全支持级联外键约束。

 

参考：

https://www.cnblogs.com/luoahong/articles/8043035.html

https://zhuanlan.zhihu.com/p/111668741 

 

三、MGR特点

高一致性。基于原生复制及paxos协议的组复制技术，并以插件的方式提供，提供一致数据安全保证；

高容错性。只要不是大多数节点坏掉就可以继续工作，有自动检测机制，当不同节点产生资源争用冲突时，不会出现错误，按照先到者优先原则进行处理，并且内置了自动化脑裂防护机制；

高扩展性。节点的新增和移除都是自动的，新节点加入后，会自动从其他节点上同步状态，直到新节点和其他节点保持一致，如果某节点被移除了，其他节点自动更新组信息，自动维护新的组信息；

高灵活性。有单主模式和多主模式，单主模式下，会自动选主，所有更新操作都在主上进行；多主模式下，所有server都可以同时处理更新操作。

 

四、使用限制

（1） 仅支持innodb引擎

​为什么需要使用innodb引擎呢？在MySQL Group Replication中，事务以乐观形式执行，但是在提交时检查冲突，如果存在冲突，则会在某些实例上回滚事务，保持各个实例的数据一致性，那么，这就需要使用到事务存储引擎，同事Innodb提供一些额外的功能，可以更好的管理和处理冲突，所以建议 业务使用表格使用inndb存储引擎，类似于系统表格mysql.user使用MyISAM引擎的表格，因为极少修改及添加，极少出现冲突情况。

（2）主键

​每个需要复制的表格都必须定义一个显式主键，注意跟隐式主键区分（使用Innodb引擎的表格，如果没有指定主键，默认选择第一个非空的唯一索引作为主键，如果没有，则自动创建一个6个字节的rowid隐式主键）。这个主键能在冲突发生时启动极其重要的作用，同时，能够有效提高relay log的执行效率。

（3）隔离级别

​官网建议使用READ COMMITTED级别，除非应用程序依赖于REPLEATABLE

READ，RC模式下没有GAP LOCK，比较好支持Innodb本身的冲突检测机制何组复制的内部分布式检测机制一起协同工作。不支持SERIALIZABLE隔离级别。

（4）外键

​不建议使用级联外键，如果旧库本身有外键，业务上无法去除并且使用的是多主模式，那么，请配置group_replication_enforce_update_everywhere_check ，强制检查每个组成员的级联检查，避免多主模式下执行级联操作造成的检测不到的冲突。

五、参数规范

因前期创建实例大多采取默认配置 导致开发，测试，生产等环境间数据库参数不同 对程序运行有一定的影响。 以后创建实例将会参数规范化 对已有的实例后续也会慢慢修正。

下面简单解释下几个改动的参数

sql_mode 去除了ONLY_FULL_GROUP_BY, STRICT_TRANS_TABLES,NO_ZERO_IN_DATE, NO_ZERO_DATE等限制 采取了较为宽松的模式

lower_case_table_names 统一设置为1 即不区分大小写 有些实例还没更改 大家建表建库的时候不要大写

character-set-server 统一设置为utf8 不要用latin1字符集

wait_timeout和interactive_timeout参数控制空闲连接的时长 当连接空闲时间超过此参数则会被断开 以后会统一设置为1800s即30分钟

transaction_isolation 事务隔离级别 MySQL官方默认是可重复读（repeatable-read）目前单实例及主从架构的mysql采用了此级别，MGR集群将采取读已提交（read-committed）级别。Oracle默认是读已提交 。

 

六、两地三中心应用

随着互联网业务快速发展，多IDC的业务支撑能力和要求也逐步提升，行业内的“两地三中心”方案较为流行。其中两地是指同城、异地；三中心是指生产中心、同城容灾中心、异地容灾中心。

两地三中心方案中，基于设定的短期目标可以明确同城双活和异地容灾的方案组合。设计重点为同城双活，即在同城的数据中心之间，一般通过高速光纤相连，在网络带宽有保障的前提下，网络延迟一般在可接受范围内，两个机房之间可以认为在同一个局域网内。

在设计上可以和应用层结合起来，有两种部署模式：分为应用层双活和数据库双活，应用层双活和数据库单活。

（1）MGR集群多活架构

基于MGR的多活特性，数据的写入可以在多个节点之间进行复制，实现数据强一致性需求，并且在节点间通信出现延迟的情况下，会自动实现服务降级。对于此类方案，我们可以采用同机房多写，同城异机房只读的方案。

 

（2）双主模式的多活

两个节点均可以写入数据，可以实现跨机房的数据复制，延迟较低，在业务层需要做隔离，在故障发生时能够快速切换到同机房的Slave节点。此方案对于两个IDC机房的场景中较为实用，但是机房多活的场景不适合。

 

（3）业务交叉的双活方案

此种方案是双活技术的变通实现，即存在两类业务A和B,数据存储在database级别（schema层级），分别在不通的IDC节点完成数据写入，比如业务A在IDC1完成写入，业务B在IDC2完成写入，两个节点之间存在跨机房的复制节点，在出现问题时，能够通过域名的方式切换到指定的IDC节点。此种方案对于业务的依赖性较高，不适合机房多活的场景。