Mysql5.7基于组复制(MySQLGroupReplication)-精华版_my-011735

Mysql

2星需积分: 15 163 浏览量更新于2023-03-16 评论收藏 165KB DOCX 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

资源详情

资源评论

资源推荐

一、组复制 (MGR)介绍

MySQL Group Replication（简称 MGR）是 MySQL 官方于 2016 年 12 月推出的一个全新的高可

用与高扩展的解决方案。组复制是 MySQL5.7 版本出现的新特性，它提供了高可用、高扩展、高

可靠的 MySQL 集群服务。MySQL 组复制分单主模式和多主模式，mysql 的复制技术仅解决了数

据同步的问题，如果 master 宕机，意味着数据库管理员需要介入，应用系统可能需要修改数据库

连接地址或者重启才能实现。（这里也可以使用数据库中间件产品来避免应用系统数据库连接的问

题，例如 mycat 和 atlas 等产品）。组复制在数据库层面上做到了，只要集群中大多数主机可用，

则服务可用，也就是说 3 台服务器的集群，允许其中 1 台宕机。

1.1 组复制的两种模式

- 在单主模式下, 组复制具有自动选主功能，每次只有一个 server 成员接受更新;

- 在多主模式下, 所有的 server 成员都可以同时接受更新;

1.2 组复制原理

组复制是一种可用于实现容错系统的技术。复制组是一个通过消息传递相互交互的 server 集群。

通信层提供了原子消息(atomic message)和完全有序信息交互等保障机制，实现了基于复制协议

的多主更新。复制组由多个 server 成员构成,并且组中的每个 server 成员可以独立地执行事务。但

所有读写(RW)事务只有在冲突检测成功后才会提交。只读(RO)事务不需要在冲突检测,可以立即提

交。句话说,对于任何 RW 事务,提交操作并不是由始发 server 单向决定的,而是由组来决定是否提

交。准确地说,在始发 server 上,当事务准备好提交时,该 server 会广播写入值(已改变的行)和对应

的写入集(已更新的行的唯一标识符)。然后会为该事务建立一个全局的顺序。最终,这意味着所有

server 成员以相同的顺序接收同一组事务。因此,所有 server 成员以相同的顺序应用相同的更改,

以确保组内一致。

MySQL 组复制协议:

图，新成员 server 的加入离开，无论是自愿还是被迫的离开，该组都会动态地重新规划其配置,并

触发视图更新。

1.5 组复制的限制

- 存储引擎必须为 Innodb，即仅支持 InnoDB 表，并且每张表一定要有一个主键，用于做 write

set 的冲突检测;

- 每个表必须提供主键;

- 只支持 ipv4，网络需求较高;

-必须打开 GTID 特性，二进制日志格式必须设置为 ROW，用于选主与 write set;

- COMMIT 可能会导致失败，类似于快照事务隔离级别的失败场景;

-目前一个 MGR 集群组最多支持 9 个节点;

- 不支持外键于 save point 特性，无法做全局间的约束检测与部分部分回滚;

- 二进制日志 binlog 不支持 Replication event checksums;

- 多主模式(也就是多写模式) 不支持 SERIALIZABLE 事务隔离级别;

- 多主模式不能完全支持级联外键约束;

- 多主模式不支持在不同节点上对同一个数据库对象并发执行 DDL(在不同节点上对同一行并发进行

RW 事务，后发起的事务会失败);

二、组复制技术实现

2.1 组复制与传统复制的区别和大幅改进

传统复制

主-从复制: 有一个主和不等数量的从。主节点执行的事务会异步发送给从节点，在从节点重新执行。

（异步和半同步；半同步相对异步 Master 会确认 Slave 是否接到数据，更加安全）

并行复制: 复制->广播->正式复制

组复制相比传统复制的优势在于:

- 弹性复制（高扩展性）: server 动态添加移除;

- 高可用分片（高扩展性）: 分片实现写扩展，每个分片是一个复制组;

- 替代主从复制（高扩展性）: 整组写入，避免单点争用;

- 自动化系统: 自动化部署 Mysql 复制到已有复制协议的自动化系统;

- 故障检测与容错: 自动检测，若服务 faild,组内成员大多数达成认为该服务已不正常，则自动隔离;

在 MySQL 组复制环境中，组内成员会构成一个视图，组内成员主动加入或离开（主动或被动），

都会更新组配置，更新视图。成员自愿离开，先更新组配置，然后采用大多数成员（不包含主动脱

离的成员）意见是否确认该成员离开更新视图。如果是故障要排除，则需大多数服务确认（包括故

障成员意见），然后才会更新组配置和视图。

特别注意：组复制最大允许即时故障数：f=(n-1)/2,多数正常则正常

2.2 组复制优点小结

1) 在 master-slave 之间实现了强一致性；

对于只读事务，组间实例无需进行通讯，就可以处理事务；对于读写(RW)事务，组内所有节点必须

经过通讯，共同决定事务提交与否。

2) 事务冲突处理

在高并发的多写模式下，节点间事务的提交可能会产生冲突，比如，两个不同的事务在两个节点上

操作了同一行数据，这个时候就会产生冲突。首先，Group Replication（GR）能够识别到这个冲

突，然后对此的处理是，依赖事务提交的时间先后顺序，先发起提交的节点能够正确提交，而后面

的提交，会失败

3) 故障检测

MGR 自带故障检测机制，可以识别组内成员是否挂掉(组内节点心跳检测)。当一个节点失效，将由

其他节点决定是否将这个失效的节点从 group 里面剔除。

4) 组成员管理

MGR 需要维护组内节点的状态(ONLINE,RECOVERING,OFFLINE)，对于失效的节点，由其他节点

决定是否剔除。对于新加入的节点，需要维护它的视图与其他节点的视图保持一致。

5) 容错能力

MGR 基于分布式一致性算法实现，一个组允许部分节点挂掉，只要保证大多数节点仍然存活并且之

间的通讯是没有问题的，那么这个组对外仍然能够提供服务！假设一个 MGR 由 2n+1 个节点，那

么允许 n 个节点失效，这个 MGR 仍然能够对外提供服务。比如有 3 个节点组成的一个 GR，可允许

1 个节点失效，这个 GR 仍然能够提供服务。

6) 部署方便简单。

7) 最后结论

对比之前的 5.6 的双主模式，5.7 的组复制模式不管从部署还是管理都要方便很多。

2.3 组复制模式介绍

MGR 提供了 single-primary 和 multi-primary 两种模式。其中，single-primary mode(单写模

式) 组内只有一个节点负责写入，读可以从任意一个节点读取，组内数据保持最终一致；multi-

primary mode(多写模式)，即写会下发到组内所有节点，组内所有节点同时可读，也是能够保证

组内数据最终一致性。尤其要注意：一个 MGR 的所有节点必须配置使用同一种模式，不可混用！

1) 单写模式

单写模式 group 内只有一台节点可写可读，其他节点只可以读。

对于 group 的部署，需要先跑起 primary 节点（即那个可写可读的节点，read_only = 0）然后再

跑起其他的节点，并把这些节点一一加进 group。其他的节点就会自动同步 primary 节点上面的变

化，然后将自己设置为只读模式（read_only = 1）。当 primary 节点意外宕机或者下线，在满足

大多数节点存活的情况下，group 内部发起选举，选出下一个可用的读节点，提升为 primary 节点。

primary 选举根据 group 内剩下存活节点的 UUID 按字典序升序来选择，即剩余存活的节点按

UUID 字典序排列，然后选择排在最前的节点作为新的 primary 节点。

单写模式部署(单机多实例)

在一个节点上运行三个 MySQL 实例，然后把其中一个实例部署为主，其他两个节点部署为从；主

写，从读；这种模式适用于实验和自己练习。

特别重要：在切换 primary 期间，mysql group 不会处理应用重连接到新的主，这需要应用层自

己或者由另外的中间件层（proxy or router）去保证！

2) 多写模式

group 内的所有机器都是 primary 节点，同时可以进行读写操作，并且数据是最终一致的。

该模式不好的地方在于: 非 rpm 包安装，目前使用 rpm 方式没有配置成功；启动还是处于手动方式，

可以编写 sys V 方式启动脚本；性能上面没有做压测。

多机单写部署

在三个节点上分别部署 MySQL 实例，然后把其中一个实例部署为主节点，其他两个节点部署为从

节点；主写，从读; 当主节点 OFFLINE(下线)时，两个从节点会选举出一个注节点，但是在应用中

的连接 IP 是不会随着更换的，需要重新进行配置。这种模式在节点故障率比较高的场景不适用，会

导致应用找不到数据库。

多机多写部署

在三个节点上分别部署 MySQL 实例，每个节点都接收写请求；额外可以加入一个节点，测试节点

的动态增加。

                    三、基于 GTID 的组复制分布式

集群的环境部署记录

需要清楚知道：MySQL 复制组能够以一种自动优先选择的单主模式运行，在某个时间只有一个服务

器接受更新。但是对于更高优先级的用户，组能够以多主模式部署，所有的服务器都能够接受更新，

即使它们是同时发生的。组复制中存在着一种内建的组成员关系服务用来保持组的视图一致，并且

在任意时间对于组中的所有的服务器都可用。MySQL 服务器能够退出或者加入组中，而且视图也会

相应的更新。有时服务器可能会意外的退出组（故障），在这种情况下失败检测机制检测这种情况

并且告知复制组视图发生了变化，这所有的一切都是自动实现的。

3.1 实验环境

[root@MGR-node1 ~]# cat /etc/redhat-release

CentOS Linux release 7.5.1804 (Core)

剩余29页未读，继续阅读

zyfmkxz

2020-11-30

什么鬼，没什么用

kevin_grace

粉丝: 7
资源: 75

会员权益专享

Mysql 5.7 基于组复制(MySQL Group Replication) - 精华版

评论1

会员权益专享

最新资源

Mysql 5.7 基于组复制(MySQL Group Replication) - 精华版

评论1

MySQL Group Replication 详细搭建部署过程

MySQL Group Replication官方文档中文版

宋利兵-MySQL-5.7GA中的复制和集群管理

mysql5.7可以主从多进程复制吗

mysql 5.7 数据源配置

MySQL Group Replication

mysql 怎么做高可用

mysqlmgr安装部署

MGR集群搭建详细步骤

mysql mgr群集

mysql的发展趋势

mysql 57 mgr 数据不一致

Mysql MGR 流控制的作用

mysql5.7.11安装教程详细

深入理解MySQL Group Replication

多图表实现员工满意度调查数据分析python

2020届软件工程本科毕业生毕业设计项目.zip

基于stm32平衡小车

c语言火车票订票管理源码.rar

施耐德PLC例程源码四台水泵的轮换

会员权益专享

最新资源