MGR-单主模式搭建步骤-介绍篇

数据库服务器规划
序号	IP地址	主机名	数据库	端口号	ServerID	操作系统
1	192.168.1.2	baba1	mysql-5.7.25	3306	63	Centos7.6
2	192.168.1.3	baba2	mysql-5.7.25	3306	64	Centos7.6
3	192.168.1.4	baba3	mysql-5.7.25	3306	65	Centos7.6

　　一.　MGR介绍

MySQL Group Replication（MGR：mysql 组复制技术）是 MySQL 官方在 5.7.17 版本引进的一个数据库高可用与高扩展的解决方案，以插件形式提供。

MGR 基于分布式 paxos 协议，实现组复制，在分布式中保证数据一致性和原子性，且具有容错率的一致性算法。内置故障检测和自动选主功能，只要不是集群中的大多数节点都宕机，就可以继续正常工

作。

提供单主模式与多主模式，多主模式支持多点写入。

　　二. MGR特点

　　What's Group Replication（什么是组复制？）

　　先说主从复制，一主多从，主库提供读写功能，从库提供读功能。当一个事务在 master 提交成功时，会把 binlog 文件同步到从库服务器上为 relay log 给 slave 端执行，这个过程主库是不考虑从库是否有接收到 binlog 文件，有可能出现这种情况，当主库 commit 一个事务后，数据库发生宕机，刚好它的 binlog 还没来得及传送到 slave 端，这个时候选任何一个 slave 端都会丢失这个事务，造成数据不一致情况。原理图如下：

　　

 

　　为了避免出现主从数据不一致的情况，MySQL 引入了半同步复制，添加多了一个从库反馈机制，这个有两种方式设置：

　　主库执行完事务后，同步 binlog 给从库，从库 ack 反馈接收到 binlog，主库才会提交 commit，反馈给客户端，释放会话；

　　主库执行完事务后，主库提交 commit，同步 binlog 给从库，从库 ack 反馈接收到 binlog，反馈给客户端，释放会话；

　　但是，问题来了，虽然满足了一主多从，读写分离，数据一致，但是，依旧有两个弊端：　

　　写操作集中在 MASTER 服务器上；

　　MASTER 宕机后，需要人为选择新主并重新给其他的 slave 端执行 change master，于是官方发布了 MySQL Group Replication

那么，MySQL Group Replication 可以提供哪些功能呢？

　　1. 多主，在同一个 group 里边的所有实例，每一个实例可以执行写操作，也就是每个实例都执行Read-Write，需要注意的是，多主情况下，当执行一个事务时，需要确保同个组内的每个实例都认可这个事务无冲突异常，才可以 commit，如果设置的是单主，其他实例 ReadOnly，则不需要进行上面的判断多主情况下，事务并发冲突问题就凸显出来了，如何避免呢？数据库内部有一个认证程序，当不同实例并发对同一行发起修改，在同个组内广播认可时，会出现并发冲突，那么会按照先执行的提交，后执行的回滚

　　2. 弹性，同个 Group Replication 中，节点的加入或者移除都是自动调整；如果新加入一个节点，该节点会自动从 Group 的其他节点同步数据，直到与其他节点一致；如果移除一个节点，那么剩下的实例会自动更新，不再向这个节点广播事务操作，当然，这里要注意，假设一个 Group 的节点有 n 个（max(n)=9，同个 Group 最多节点数为 9），移除或者宕机的节点数应该小于等于 floor((n-

1)/2) ，注意是向下取整；如果是单主模式，宕机的是单主，则人为选择新主后，其他节点也会自动从新主同步数据。

　　3. 更高性能的同步机制

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

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

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

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

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

　　MGR 是 MySQL 数据库未来发展的一个重要方向。

　　三.  MGR 基础结构要求

　　1）引擎必须为 innodb，因为需要事务支持在 commit 时对各节点进行冲突检查

　　2）每个表必须有主键，在进行事务冲突检测时需要利用主键值对比

　　3）必须开启 binlog 且为 row 格式 --binlog-format=row（组复制依赖于基于行格式的二进制日志，以便在组中传播所发生的更改能保持一致性。而且，在探测组中不同节点间发生的并发事务是否冲突时，需要从行格式的日志中提取一些内容来做比较。 ）

　　4）开启 GTID，--gtid-mode=ON

　　什么是 GTID？

　　GTID(Global Transaction ID)是对于一个已提交事务的编号，并且是一个全局唯一的编号。GTID 实际上是由 UUID+TID 组成的。其中 UUID 是一个 MySQL 实例的唯一标识。TID 代表了该

实例上已经提交的事务数量，并且随着事务提交单递增。下面是一个 GTID 的具体形式

　　3E11FA47-71CA-11E1-9E33-C80AA9429562:23    UUID:TID

　　组复制使用 GTID(全局事务 ID)来精确跟踪每个节点上已经提交了哪些事务。也因此可以推断出某节点上要执行的事务是否和已执行的事务(每个节点上都有副本)冲突。换句话说，GTID 是整个组复制判断事务是否冲突的基础。）

　　5）主从状态信息存于表中 --master-info-repository=TABLE 、--relay-log-info-repository=TABLE（需要将 master 和 relay log 的元数据信息写入到系统表

　　slave_master_info 和 mysql.slave_relay_log_info 中。这保证了组复制插件具有一致性恢复的能力和复制的元数据事务管理能力。 ）

　　6）开启--log-slave-updates 副本更新记录，节点需要记录已应用的日志。组中的每个节点都需要记录它们所接收到并应用的所有事务，这是必须的，因为恢复过程是依赖于组中参与者的二进制日志来进行的。因此，组中每个成员都必须保留每个事务的副本，即使某事务不是在该节点上开始的。

　　7）一致性检测设置--transaction-write-set-extraction=XXHASH64(设置后以便将行写入到二进制日志中时，节点也收集写集。写集基于每行的主键，是唯一标识被更改行的标签的简化形式，该标签后续会用于探测事务冲突性。)