mysql-MGR高可用集群

1.MySQL Group Replication（MGR）

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

MySQL Group Replication（MGR）是MySQL官方在5.7.17版本引进的一个数据库高可用与高扩展的解决方案，以插件形式提供，实现了分布式下数据的最终一致性，总结MGR特点如下：
    高一致性：基于原生复制以及分布式paxos协议实现组复制，并已插件的方式提供，保证数据一致性(paxos协议:解决多节点写入的问题)；
    高容错性：自动检测机制，只要不是大多数节点都宕机就可以继续工作，有自动检测机制，当不同节点产生资源竞争时，不会出现错误，按照先到先优先的原则进行处理，内置自动化防脑裂保护机制；
    高扩展性：节点的增加与移除会自动更新组成员信息，新节点加入后，自动从其他节点同步增量数据，直到与其他节点数据一致，如果某个节点被移除了，其他节点会自动更新组信息，自动维护新的组信息。
    高灵活性：提供单主模式和多主模式，单主模式在主库宕机后能够自动选主，所有写入都在主节点进行，多主模式支持多节点写入。

2.MGR使用限制

限制一：仅支持innodb存储引擎

MGR集群中，只支持innodb存储引擎，能够创建非innodb引擎的表，但是无法写入数据，向非innodb表写数据直接报错。因为事物支持在commit时对各节点进行冲突检查
要求：
    节点必须开启binlog且为row模式
    必须开启gtid
    且主从状态信息存于表中
        --master-info-repository=TABLE
        --realy-log-info-repository=TABLE
        --log-slave-updates打开，级联更新)
    一致性检测设置 --transaction-write-extraction=XXHASH64

  限制二：表必须有主见或者非NULL的唯一值

MGR集群中，只支持innodb引擎的表，并且该表必须有显式的主键，或者非Null的唯一键，否则即使能够创建表，也无法向表中写入数据。

限制三：网络限制

MGR 组通信引擎目前仅支持IPv4网络，并且对节点间的网络性能要求较高，低延迟、高带宽的网络是部署MGR集群的基础。

限制四：MGR忽略表锁和命名锁

在MGR中lock tables、unlock tables、get_lock、release_lock等这些表锁和命名锁将被忽略。

其他限制

1.RP和普通复制binlog校验不能共存，需设置--binlog-checksum=none;
2.不支持gap lock(间隙锁)，隔离级别需设置为read committed;
3.MGR多主模式中，默认不支持 SERIALIZABLE 隔离级别。
4.多主模式下，对同一个对象进行并发的有冲突的ddl和dml操作导致这种冲突在部分成员节点中无法检测到，最终可能导致数据不一致。
5.多主模式下，不支持级联约束的外键，可能造成有冲突的操作无法检测。
6.不支持超大事务。
7.多主模式下可能导致死锁，比如select ...for update在不同节点执行，由于多节点锁无法共享，很容易导致死锁。
8.不支持复制过滤，如果有节点设置了复制过滤，将影响节点间决议的达成。
9.MGR最多支持9个节点，大于9个节点，将拒绝新节点的加入。

 3.集群搭建(官方建议:都是奇数台)

1. MGR简介

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

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

引入组复制，主要是为了解决传统异步复制和半同步复制可能产生数据不一致的问题。组复制依靠分布式一致性协议(Paxos协议的变体)，实现了分布式下数据的最终一致性，提供了真正的数据高可用方案

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

2. MGR架构

MGR是一个MySQL Plugin（插件），简单来说，Plugin是MySQL官方提供的一套扩展机制，在MySQL实现事务处理、Binlog传输和持久化等操作时，在代码逻辑中预埋了一些（Hook）钩子，Plugin可以在钩子上注册处理函数，增加Plugin专有的功能实现。

Plugin提供了包括事务处理（Trans_observer）、服务器状态变化（Server_state_observer）、Binlog存储（Binlog_storage_observer）、Binlog发送（Binlog_transmit_observer）和Binlog回放（Binlog_relay_IO_observer）等不同功能模块的钩子集合。

举个栗子，比如事务处理钩子集包括了before_dml，before_commit，before_rollback，after_commit，after_rollback等五个钩子，分别用于在事务执行DML操作前，在事务提交前，在事务回滚前，在事务提交后，在事务回滚后进行特定的操作。

MGR作为一个官方插件，同样实现了这些钩子，其中事务处理集合的before_dml和before_commit是MGR中2个与事务处理相关的最主要钩子，注册函数分别为group_replication_trans_before_dml和group_replication_trans_before_commit，前者用于在执行DML前进行事务操作的合法性检查，包括所操作的表是否显式定义了主键，是否使用了InnoDB存储引擎等；后者是本文要重点介绍的MGR事务处理入口，它将MySQL中已经进入提交阶段的事务拦截下来，进入MGR处理流程，由MGR决定该事务应该提交还是回滚后，在返回MySQL通用代码进行后续处理。下图为作为Plugin的MGR整体框图。

3. MGR的解决方案现在具备的特性

        数据一致性保障：确保集群中大部分节点收到日志

        多节点写入支持：多写模式下支持集群中的所有节点都可以写入

        Fault Tolerance: 确保系统发生故障（包括脑裂）依然可用，双写对系统无影响

4. MGR使用限制

1. 仅支持innodb存储引擎
   MGR集群中，只支持innodb存储引擎，能够创建非innodb引擎的表，但是无法写入数据，向非innodb表写数据直接报错。
2. 表必须有主键，或者非Null的唯一键
   MGR集群中，只支持innodb引擎的表，并且该表必须有显式的主键，或者非Null的唯一键，否则即使能够创建表，也无法向表中写入数据。
3. 网络限制
   MGR 组通信引擎目前仅支持IPv4网络，并且对节点间的网络性能要求较高，低延迟、高带宽的网络是部署MGR集群的基础。
4. MGR忽略表锁和命名锁，在MGR中lock tables、unlock tables、get_lock、release_lock等这些表锁和命名锁将被忽略。
5. MGR多主模式中，默认不支持 SERIALIZABLE 隔离级别。
6. 多主模式下，对同一个对象进行并发的有冲突的ddl和dml操作导致这种冲突在部分成员节点中无法检测到，最终可能导致数据不一致。
7. 多主模式下，不支持级联约束的外键，可能造成有冲突的操作无法检测。
8. 不支持超大事务。
9. 多主模式下可能导致死锁，比如select ...for update在不同节点执行，由于多节点锁无法共享，很容易导致死锁。
10. 不支持复制过滤，如果有节点设置了复制过滤，将影响节点间决议的达成。
11. MGR最多支持9个节点，大于9个节点，将拒绝新节点的加入。