mysql高可用之组复制 (MGR)

已于 2024-08-24 19:31:56 修改
阅读量447 收藏 6
点赞数 5
分类专栏： 云原生 MySQL 文章标签： mysql 数据库 运维 linux 服务器
于 2024-08-24 19:31:39 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_68398469/article/details/141502236
版权

目录

1 MySQL的主从复制介绍

2 组复制流程

3 组复制单主和多主模式

3.1 single-primary mode(单写或单主模式)

3.2 multi-primary mode(多写或多主模式)

4 实现mysql组复制

4.1 MASTER 1

4.2 MASTER 2

4.3 MASTER 3

4.4 MASTER 1 检验

1 MySQL的主从复制介绍

MySQL Group Replication(简称 MGR )是 MySQL 官方于 2016 年 12 月推出的一个全新的高可用与高扩 展的解决方案

组复制是 MySQL 5.7.17 版本出现的新特性，它提供了高可用、高扩展、高可靠的 MySQL 集群服务

MySQL 组复制分单主模式和多主模式，传统的mysql复制技术仅解决了数据同步的问题，

MGR 对属于同一组的服务器自动进行协调。对于要提交的事务，组成员必须就全局事务序列中给定事务的顺序达成一致

提交或回滚事务由每个服务器单独完成，但所有服务器都必须做出相同的决定

如果存在网络分区，导致成员无法达成事先定义的分割策略，则在解决此问题之前系统不会继续进行，这是一种内置的自动裂脑保护机制

MGR由组通信系统( Group Communication System ，GCS ) 协议支持

该系统提供故障检测机制、组成员服务以及安全且有序的消息传递

2 组复制流程

首先我们将多个节点共同组成一个复制组，在执行读写（RW）事务的时候，需要通过一致性协议层 （Consensus 层）的同意，也就是读写事务想要进行提交，必须要经过组里“大多数人”（对应 Node 节点）的同意，大多数指的是同意的节点数量需要大于 （N/2+1），这样才可以进行提交，而不是原发起方一个说了算。而针对只读（RO）事务则不需要经过组内同意，直接 提交 即可

节点数量不能超过 9 台

3 组复制单主和多主模式

3.1 single-primary mode(单写或单主模式)

单写模式 group 内只有一台节点可写可读，其他节点只可以读。当主服务器失败时，会自动选择新的主服务器

3.2 multi-primary mode(多写或多主模式)

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

4 实现mysql组复制

为了避免出错，在所有节点中从新生成数据库数据

编辑主配置文件：

4.1 MASTER 1

[root@mysql-01 ~]# vim /etc/my.cnf
[mysqld]
datadir=/data/mysql
socket=/data/mysql/mysql.sock
symbolic-links=0
server_id=10
gtid_mode=ON
enforce-gtid-consistency=ON
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"

# 将主从复制的信息存储在表中  提高性能很重要
master_info_repository=TABLE
relay_log_info_repository=TABLE

# 禁止对二进制日志校验
binlog_checksum=NONE

# 开启从服务器的日志更新记录
log_slave_updates=ON

# 二进制日志文件名
log_bin=binlog

# 二进制日志格式
binlog_format=ROW

# 加载 Group Replication 插件
plugin_load_add='group_replication.so'

transaction_write_set_extraction=XXHASH64

# 设置 Group Replication 的集群名称
group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"

# 控制 MySQL 服务启动时是否自动启动 Group Replication
group_replication_start_on_boot=off

# 指定本地实例的地址和端口，用于 Group Replication
group_replication_local_address="192.168.239.210:33061"

# 指定集群种子成员列表，用于新成员加入集群
group_replication_group_seeds="192.168.239.210:33061,192.168.239.220:33061,192.168.239.230:33061"

# 设置允许连接到 Group Replication 的 IP 白名单
group_replication_ip_whitelist="192.168.239.0/24,127.0.0.1/8"

# 控制是否将当前实例作为集群的第一个成员启动
group_replication_bootstrap_group=off

# 控制是否启用单主模式  禁用单主那就是多主
group_replication_single_primary_mode=OFF

# 强制执行跨所有实例的更新检查
group_replication_enforce_update_everywhere_checks=ON

# 允许具有不连续 GTID 的实例加入集群
group_replication_allow_local_disjoint_gtids_join=1
mysql> alter user root@'localhost' identified by 'Openlab123!';

-- 禁用二进制日志记录，以避免在创建用户时记录日志
mysql> set sql_log_bin=0;
mysql> create user shuyan@'%' identified by 'Openlab123!';

-- 授予 shuyan 用户复制从属权限，允许其从任何主机连接
mysql> grant replication slave on *.* to shuyan@'%';
mysql> flush privileges;

-- 重新启用二进制日志记录
mysql> set sql_log_bin=1;

-- 设置复制源（Master）的用户名和密码，用于 Group Replication 的恢复过程
mysql> change master to 
    -> master_user='shuyan',
    -> master_password='Openlab123!'
    -> for channel 'group_replication_recovery';

-- 允许当前实例作为集群的第一个成员启动 Group Replication
mysql> set global group_replication_bootstrap_group=on;

-- 启动 Group Replicatio
mysql> start group_replication;

-- 禁止当前实例作为集群的第一个成员启动 Group Replication
mysql> set global group_replication_bootstrap_group=off;
mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| group_replication_applier | 14ffce7c-61e9-11ef-bec7-000c29a51779 | mysql-01    |        3306 | ONLINE       |
+---------------------------+--------------------------------------+-------------+-------------+--------------+

4.2 MASTER 2

[root@mysql-02 ~]# vim /etc/my.cnf
[mysqld]
datadir=/data/mysql
socket=/data/mysql/mysql.sock
symbolic-links=0
server_id=20
gtid_mode=ON
enforce-gtid-consistency=ON
#禁用指定存储引擎
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
master_info_repository=TABLE
relay_log_info_repository=TABLE
binlog_checksum=NONE
# 打开数据库中继
log_slave_updates=ON
log_bin=binlog
binlog_format=ROW
# 加载组复制插件
plugin_load_add='group_replication.so'
transaction_write_set_extraction=XXHASH64 #把每个事件编码为加密散列
group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
group_replication_start_on_boot=off
group_replication_local_address="192.168.239.220:33061"
group_replication_group_seeds="192.168.239.210:33061,192.168.239.220:33061,192.168.239.230:33061"
group_replication_ip_whitelist="192.168.239.0/24,127.0.0.1/8"
group_replication_bootstrap_group=off
group_replication_single_primary_mode=OFF
group_replication_enforce_update_everywhere_checks=ON
group_replication_allow_local_disjoint_gtids_join=1
mysql> alter user 'root'@'localhost' identified by 'Openlab123';
mysql> set sql_log_bin=0;
mysql> create user shuyan@'%' identified by 'Openlab123!';
mysql> grant replication slave on *.* to shuyan@'%';
mysql> flush privileges;
mysql> set sql_log_bin=1;
mysql> change master to 
    -> master_user='shuyan',
    -> master_password='Openlab123!'
    -> for channel 'group_replication_recovery';

mysql> start group_replication;
mysql> select * from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| group_replication_applier | 14ffce7c-61e9-11ef-bec7-000c29a51779 | mysql-01    |        3306 | ONLINE       |
| group_replication_applier | 51a6613a-61eb-11ef-bdb3-000c299efdf0 | mysql-02    |        3306 | ONLINE       |
+---------------------------+--------------------------------------+-------------+-------------+--------------+

4.3 MASTER 3

[root@mysql-03 ~]# vim /etc/my.cnf
[mysqld]
datadir=/data/mysql
socket=/data/mysql/mysql.sock
symbolic-links=0
server-id=30
gtid_mode=ON
enforce-gtid-consistency=ON
#禁用指定存储引擎
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
master_info_repository=TABLE
relay_log_info_repository=TABLE
binlog_checksum=NONE
# 打开数据库中继
log_slave_updates=ON
log_bin=binlog
binlog_format=ROW
# 加载组复制插件
plugin_load_add='group_replication.so'
transaction_write_set_extraction=XXHASH64 #把每个事件编码为加密散列
group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
group_replication_start_on_boot=off
group_replication_local_address="192.168.239.230:33061"
group_replication_group_seeds="192.168.239.210:33061,192.168.239.220:33061,192.168.239.230:33061"
group_replication_ip_whitelist="192.168.239.0/24,127.0.0.1/8"
group_replication_bootstrap_group=off
group_replication_single_primary_mode=OFF
group_replication_enforce_update_everywhere_checks=ON
group_replication_allow_local_disjoint_gtids_join=1
mysql> set sql_log_bin=0;
mysql> create user 'shuyan'@'%' identified by 'Openlab123!';
mysql> grant replication slave on *.* to shuyan@'%';
mysql> flush privileges;
mysql> set sql_log_bin=1;
mysql> change master to
    -> master_user='shuyan',
    -> master_password='Openlab123!'
    -> for channel 'group_replication_recovery';

mysql> start group_replication;

4.4 MASTER 1 检验

[root@mysql-01 ~]# mysql -uroot -pOpenlab123! -e "select * from performance_schema.replication_group_members;"
mysql: [Warning] Using a password on the command line interface can be insecure.
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| group_replication_applier | 14ffce7c-61e9-11ef-bec7-000c29a51779 | mysql-01    |        3306 | ONLINE       |
| group_replication_applier | 51a6613a-61eb-11ef-bdb3-000c299efdf0 | mysql-02    |        3306 | ONLINE       |
| group_replication_applier | 6d1255c0-61ec-11ef-99d9-000c298f2a8a | mysql-03    |        3306 | ONLINE       |
+---------------------------+--------------------------------------+-------------+-------------+--------------+

妍妍的宝贝
关注
专栏目录
详解mysql数据库官方高可用方案——MGR理论篇
m0_69804655的博客
03-08 1585
一个服务器被怀疑意味这该服务器无响应(mute)，当服务器A在一段时间内为收到服务器B的信息，一个超时异常发生并且服务器B会被标记为 suspicion状态，这意味着，组内其他的成员服务器会协调将其踢出复制组，如果一个服务器无法和其余的服务器通信，则他会怀疑其他服务器都故障了.由于其服务器和组内其他服务器达成一致，它自身的怀疑是没有结果的，这时他无法执行任何本地事务。重新配置过程中需要大多数节点同意，即组内故障服务器低于大多数，否则视图无法更新且会阻塞事务的执行以防止脑裂的发生，这时就需要人为的干预了。
MySQL 8.0 高可用之MGR（组复制）介绍
个人公众号：Alen的数据库学习笔记
01-07 5222
作者公众号，欢迎一起交流。 1 背景 MySQL Group Replication（简称MGR）是MySQL官方于2016年12月12日推出的一款高可用与高扩展的解决方案，它提供了高可用、高扩展、高可靠的MySQL集群服务，具有以下特点： 强一致性：基于原生复制和paxos协议，保证数据传输的一致性和原子性 高容错性：只要大多数节点没有出现故障，集群就可对外提供服务 高扩展性：节点的加入和移除都是自动的，不需要人为过多干预 高灵活性：具有单主模式和多主模式，单主模式在主宕机后自动选主，多主
MySQL MGR
summer_fish的专栏
11-08 3931
ProxySQL 介绍 ProxySQL 是基于 MySQL 的一款开源的中间件的产品，是一个灵活的 MySQL 代理层，可以实现读写分离，支持 Query 路由功能，支持动态指定某个 SQL 进行缓存，支持动态加载（无需重启 ProxySQL 服务），故障切换和一些 SQL 的过滤功能。 MGR 单主 + VIP MGR MGR （MySQL Group Replication）是MySQL自带的一个插件，可以灵活部署。MySQL ...
Mysql—高可用之组复制 (MGR)
最新发布
恭喜你发现了我！！！！
09-28 907
MySQL Group Replication(简称 MGR )是 MySQL 官方于 2016 年 12 月推出的一个全新的高可用与高扩 展的解决方案组复制是 MySQL 5.7.17 版本出现的新特性，它提供了高可用、高扩展、高可靠的 MySQL 集群服务MySQL 组复制分单主模式和多主模式，传统的mysql复制技术仅解决了数据同步的问题， MGR 对属于同一组的服务器自动进行协调。
万字详解 MySQL MGR 高可用集群搭建
保持学习
06-01 3792
MGR（MySQL Group Replication）是MySQL 5.7.17版本诞生的，是MySQL自带的一个插件，可以灵活部署。保证数据一致性又可以自动切换，具备故障检测功能、支持多节点写入。集群是多个MySQL Server节点共同组成的分布式集群，每个Server都有完整的副本，它是基于ROW格式的二进制日志文件和GTID特性。在单主模式下, 组复制具有自动选主功能，每次只有一个 server成员可以作为主节点。单主模式 group 内只有一台节点可写可读，其他节点只可以读。
MySQL8.0 MGR介绍
sinat_36757755的博客
05-02 4363
常见的数据库高可用是通过创建计算数据节点冗余来确保数据库的节点宕机不会影响系统的运行，但这会导致数据库的架构复杂，运维成本提升，此外，还需要解决分布式可能所带来的脑裂，数据一致性问题。 MySQL MGR插件基于分布式Paxos算法，协调多个数据库节点进行数据复制，事务一致性检验，故障自动检测选主，节点添加删除，MGR有两种模式，单主模式以及多主模式。
MySQL 高可用之 MGR
weixin_30632899的博客
08-15 353
MGR整体架构及特点 　　single-master 　　　　只有一个节点写入，都可以读取 　　multi-master 　　　　每个节点都可以写入和读取 　　涉及到的概念： 　　　　group communication system (GCS) 　　　　writeset 　　　　membership 　　　　cerification info 　　　　...
mysql高可用集群MGR组复制集群介绍及搭建说明
05-27
### MySQL高可用集群MGR组复制集群介绍及搭建说明 #### 一、资源概述 本文档旨在为用户提供一份详尽的MySQL高可用集群MGR（组复制）集群介绍及搭建指南。MySQL组复制（MySQL Group Replication, MGR）是一项基于...
【MySQL高可用】MySQL高可用之MGR部署
10-15 995
高可用 MGR
MySQL MGR组复制技术集群高可用实战视频教程
06-17
MySQL MGR组复制技术是MySQL数据库提供的一种高可用性解决方案，它通过在多个节点之间同步数据，确保在任何单个节点出现故障时，集群能够自动切换到其他健康节点，从而保持服务的连续性和数据的一致性。这个"MySQL ...
mysql高可用集群MGR组复制的介绍、部署及配置说明
唯有热爱 可抵万难
05-10 1124
MGR组复制mysql高可用集群搭建部署及测试
数据库系列之MySQL组复制MGR技术
牧羊人的方向
06-24 3039
MGR组复制是MySQL的一种高可用复制技术，用于构建高可用、高扩展和高容错的拓扑架构中。本文简要介绍MGR复制技术的原理，并配置多主模式进行测试。
【MySQL】MGR集群相关简介
weixin_33912445的博客
01-28 294
1.MGR简介 MySQL Group Replication（MGR）是MySQL官方在5.7.17版本引进的一个数据库高可用与高扩展的解决方案，以插件形式提供。MGR基于分布式paxos协议，实现组复制，保证数据一致性。内置故障检测和自动选主功能，只要不是集群中的大多数节点都宕机，就可以继续正常工作。提供单主模式与多主模式，多主模式支持多点写入。 2.原理简单介绍 组复制是一种可用于实现容...
MYSQL--架构--MGR--部署--01--单主模式
zhou920786312的博客
06-01 1314
| 角色 | IP | 主机名 |server_id |mysql版本 | 备注 | | :------- | :------- | :------- |:------- |:------- | | master | 192.168.187.177 | mysql01 | 1 | 8.0.22 | 主服务器,提供读写操作 | | slave | 192.168.187.178 | mysql02 | 2 | 8.0.22 | 从服务器,提供读操作 | | slave
mysql mgr 集群部署 单主模式和多主模式
qq_2382495516的博客
09-06 1134
MGR介绍MySQL Group Replication（MGR：mysql组复制技术）是MySQL官方在5.7.17版本引进的一个数据库高可用与高扩展的解决方案，以插件形式提供。 **MGR基于分布式paxos协议，实现组复制，在分布式中保证数据一致性和原子性，且具有容错率的一致性算法。**内置故障检测和自动选主功能，只要不是集群中的大多数节点都宕机，就可以继续正常工作。 提供单主模式与多主模式，多主模式支持多点写入。 MySQL Group Replication（MGR）是MySQL官方在5.7.17
mysql--MGR
qq_42764351的博客
10-06 305
组复制的两种模式 单主模式下：组复制具有自动选主功能，每次只有一个 server成员接受更新。 在多主模式：所有的 server 成员都可以同时接受更新. 组复制与异步主从复制区别 传统mysql主从复制： 是在主节点执行和提交事务,然后把他们异步的发送到从节点,行复制的重新执行主节点的SQL语句,这是一个 shared-nothing 的系统，默认情况下所有 server 成员都有一个完...
MYSQL高可用管理-MGR（MGR网络抖动问题分析和group_replication_unreachable_majority_timeout等参数分析）
oradbm的博客
07-31 1310
如果group_replication_autorejoin_tries为 0 或重试失败，则会执行 group_replication_exit_state_action 指定的操作。本文主要从测试的角度来阐明group_replication_unreachable_majority_timeout和group_replication_member_expel_timeout参数对集群网络分区的影响，首先这里放一张大图，为多年前学习MGR的时候留下的，也就是这两个参数对集群的影响，也是本文测试重点。
深入解析MySQL MGR原理
专注于数据库技术分享，包含但不限于Oracle，MySQL，PostgreSQL，ElasticSearch及国产数据库等
04-14 1359
它能够在多节点间保持数据的一致性，自动处理故障转移和数据修复，适应多种工作模式，并提供了一系列性能优化手段，适用于对数据一致性和服务可用性有严格要求的场景。Paxos引擎在此基础上实现分布式一致性算法，确保在任何给定时刻，组内只有一个节点能提交某个事务，并确保所有节点最终对事务的执行达成一致。：节点定期或在事件触发时向组内其他节点报告自己的状态，包括事务执行进度、健康状况等，以便其他节点了解整个组的全局状态。：在部分节点发生故障时，剩余健康节点能够继续服务，并在故障节点恢复后协助其追赶上组的最新状态。
Mysql MGR搭建
qq_41270538的博客
02-06 1489
也就是说，虽然系统分配了大量的内存给mysqld，但其实际上并不需要用到那么多内存，内存可能产生了碎片，内存没有及时GC。它是一个通用的malloc 实现，侧重于减少内存碎片和提升高并发场景下内存的分配效率，其目标是能够替代malloc。系统中查看mysqld已用内存量远远超出了innodb_buffer_pool_size配置的数倍之多。另外在问题发生时，查看mysqld中的连接数仅500多，且大部分连接为sleep状态。所以，尝试将mysqld的内存管理器改为使用 jemalloc 来提升内存效能。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

妍妍的宝贝

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值