如何看待MySQL发布的Group Replication
发布网友
发布时间：2022-05-01 19:46
共4个回答
懂视网
时间：2022-05-02 00:07
组复制可以在两种模式下运行。
1.在单主模式下，组复制具有自动选主功能，每次只有一个 server成员接受更新。
2.在多主模式下,所有的 server 成员都可以同时接受更新.
组复制与异步主从复制区别.
1.传统mysql主从复制,是在主节点执行和提交事务,然后把他们异步的发送到从节点,行复制的重新执行主节点的SQL语句,这是一个 shared-nothing 的系统，默认情况下所有 server 成员都有一个完整的数据副本。
2.半同步复制，它在协议中添加了一个同步步骤。 这意味着主节点在提交时需要等待从节点确认它已经接收到事务。只有这样，主节点才能继续提交操作。
3.MySQL 组复制实现了基于复制协议的多主更新。
1)复制组由多个 server成员构成，并且组中的每个 server 成员可以独立地执行事务。但所有读写（RW）事务只有在冲突检测成功后才会提交。只读（RO）事务不需要在冲突检测，可以立即提交。
2)换句话说，对于任何 RW 事务，提交操作并不是由始发 server 单向决定的，而是由组来决定是否提交。准确地说，在始发 server 上，当事务准备好提交时，该 server 会广播写入值（已改变的行）和对应的写入集（已更新的行的唯一标识符）。然后会为该事务建立一个全局的顺序。最终，这意味着所有 server 成员以相同的顺序接收同一组事务。因此，所有 server 成员以相同的顺序应用相同的更改，以确保组内一致。
3)组复制使您能够根据在一组 server 中复制系统的状态来创建具有冗余的容错系统。因此，只要它不是全部或多数 server 发生故障，即使有一些 server 故障，系统仍然可用，最多只是性能和可伸缩性降低，但它仍然可用。server 故障是孤立并且独立的。它们由组成员服务来监控，组成员服务依赖于分布式故障检测系统，其能够在任何 server 自愿地或由于意外停止而离开组时发出信号。
4)他们是由一个分布式恢复程序来确保当有 server 加入组时，它们会自动更新组信息到最新。并且多主更新确保了即使在单个服务器故障的情况下也不会阻止更新，不必进行 server故障转移。因此，MySQL 组复制保证数据库服务持续可用。
5)值得注意的一点是，尽管数据库服务可用，但当有一个 server 崩溃时，连接到它的客户端必须定向或故障转移到不同的 server。
这不是组复制要解决的问题。连接器，负载均衡器，路由器或其他形式的中间件更适合处理这个问题。
总之，MySQL 组复制提供了高可用性，高弹性，可靠的 MySQL 服务。
下面展示,Mysql组复制之多主模式
server* (33,44,55)
vim /etc/my.cnf
24 server_id=3
25 gtid_mode=ON
26 enforce_gtid_consistency=ON
27 master_info_repository=TABLE
28 relay_log_info_repository=TABLE
#此选项可以写FILE(明文存储在relay-log.info 不安全,推荐写TABLE,存储在mysql.slave_relay_log_info)
29 binlog_checksum=NONE #关闭binlog校验
30 log_slave_updates=ON
#当server为slave时,要记录数据改变到自己二进制日志中,换句话说,是否让他的slave同步其数据.
31 log_bin=binlog
32 binlog_format=ROW #组复制依赖基于行的复制格式
33
34 transaction_write_set_extraction = XXHASH64
#以便在server收集写集合的同时将其记录到二进制日志。写集合基于每行的主键，并且是行更改后的唯一标识此标识将用于检测冲突。
35 group_replication_start_on_boot = OFF #同下
36 group_replication_bootstrap_group = OFF
#为了避免每次启动自动引导具有相同名称的第二个组,所以设置为OFF。
37 group_replication_group_name = "b6ddfda0-d8bc-4272-a58f-4ea75acbbc79" #组的名字可以随便起,但不能用主机的GTID
38 group_replication_local_address = ‘172.25.88.33:23306‘ #写自己主机所在IP
39 group_replication_group_seeds = ‘172.25.88.33:23306,172.25.88.44:23306,172.25.88.55:2330‘
40 #41,42行是开启多主模式的参数
41 group_replication_single_primary_mode=FALSE
42 group_replication_enforce_update_everywhere_checks=TRUE
server*:
组内每台主机都需要先安装组复制插件.
mysql>INSTALL PLUGIN group_replication SONAME ‘group_replication.so‘;
server33:
mysql>SET GLOBAL group_replication_bootstrap_group=ON;
#这句只有server33,在第一次执行引导组的时候执行.
mysql> CREATE USER repl@‘%‘;
mysql> GRANT REPLICATION SLAVE ON *.* TO repl@‘%‘ IDENTIFIED BY ‘repl‘;
Query OK, 0 rows affected, 1 warning (0.00 sec)
mysql> CHANGE MASTER TO MASTER_USER=‘repl‘,MASTER_PASSWORD=‘repl‘ FOR CHANNEL ‘group_replication_recovery‘;
Query OK, 0 rows affected, 2 warnings (0.27 sec)
mysql> set global group_replication_ip_whitelist="127.0.0.1/32,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,172.25.88.0/24";
Query OK, 0 rows affected (0.00 sec)
mysql> START GROUP_REPLICATION; Query OK, 0 rows affected (1.32 sec)
mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+---------------------+-------------+--------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+---------------------+-------------+--------------+
| group_replication_applier | eb724b27-19b2-11e7-8c21-525400cef621 | server33.lalala.com | 3306 | ONLINE |
+---------------------------+--------------------------------------+---------------------+-------------+--------------+
1 row in set (0.00 sec)
配置 group_replication_recovery 通道的恢复凭据
server44,55:
mysql> CHANGE MASTER TO MASTER_USER=‘repl‘,MASTER_PASSWORD=‘repl‘ FOR CHANNEL ‘group_replication_recovery‘;
Query OK, 0 rows affected, 2 warnings (0.56 sec)
mysql> set global group_replication_ip_whitelist="127.0.0.1/32,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,172.25.88.0/24";
Query OK, 0 rows affected (0.01 sec)
mysql> START GROUP_REPLICATION;
Query OK, 0 rows affected (4.02 sec)
mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+---------------------+-------------+--------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+---------------------+-------------+--------------+
| group_replication_applier | 8d5b8fa6-19a1-11e7-9641-52540042c9d3 | server44.lalala.com | 3306 | ONLINE |
| group_replication_applier | c5070c7c-19a3-11e7-9c1d-5254008cd713 | server55.lalala.com | 3306 | ONLINE |
| group_replication_applier | eb724b27-19b2-11e7-8c21-525400cef621 | server33.lalala.com | 3306 | ONLINE |
+---------------------------+--------------------------------------+---------------------+-------------+--------------+
3 rows in set (0.00 sec)
检验
server33:
mysql> create database test;
Query OK, 1 row affected (0.15 sec)
mysql> use test;
Database changed
mysql> CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 TEXT NOT NULL);
Query OK, 0 rows affected (0.94 sec)
mysql> INSERT INTO t1 VALUES (1, ‘lalala‘);
Query OK, 1 row affected (0.46 sec)
mysql> select * from t1;
+----+--------+
| c1 | c2 |
+----+--------+
| 1 | lalala |
+----+--------+
1 row in set (0.00 sec)
在server44,55 可以看见组复制,同步过来的数据
可以在performance_schema中看见组成员
排错
没有设置白名单网段:需要添加自己所在网段.
报错:‘[GCS] The member is leaving a group without being on one.‘
解决:set global group_replication_ip_whitelist="127.0.0.1/32,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,172.25.88.0/24"; START GROUP_REPLICATION;
本文出自 “12049878” 博客，谢绝转载！
MGR——Mysql的组复制之多主模式
标签：mysql mgr 组复制 多主模式
热心网友
时间：2022-05-01 21:15
热心网友
时间：2022-05-01 22:33
Oracle有强大的资金来确保MySQL官方做这样的事情，也有生态的先发优势，国内很多企业可能会更容易接受MySQL的这个方案，但开源产品在大公司的业务场景里面，也不一定是最优的。
请参考*自己造的一个轮子 MyRocks存储引擎，给FB省了不少MySQL服务器。
热心网友
时间：2022-05-02 00:08
背景
为获得最佳兼容性和性能，组的所有成员为了 Group Replication，应运行相同版本的 MySQL Server。但是，在某些情况下，可能需要组内有不同版本的服务器运行共存。例如，在滚动升级期间。当组中存在不同的版本时，某些成员可能与其他成员不兼容，因为它们支持其他人没有或缺乏其他人所具有的功能。因此，组复制需实现兼容性策略以防止运行到不兼容的版本组合方案。在 MySQL 8.0.17 中，组复制为组中的成员版本实现的兼容性策略考虑了成员的 MySQL Server 版本的补丁版本。
以前，只考虑过主要版本。使用维护版本（8.0.17）意味着组复制可以在组重新配置和升级过程中更好地维护混合版本组的复制安全性。
内容大纲
1. 主成员选项
A.主成员选举算法
具有 8.0.17 或更高版本成员的组
具有至少一个 8.0.16 或更低成员版本的组
B.用户触发主切换
具有 8.0.17 或更高版本成员的组
具有至少一个 8.0.16 或更低成员版本的组
2. 写版本兼容性3. 最低版本兼容性4. 捐赠者版本兼容性5. 升级6. 结论
主成员选项选择新的主节点时的参数之一是用于复制安全性的成员版本。从 8.0.17 开始，在选择新主时也考虑补丁级别。因此，基于组配置的下一个主要内容存在细微差别。
主成员选举算法
在主成员的故障转移期间，基于以下算法选择新的主成员：
具有 8.0.17 或更高版本成员的组该组中的所有成员都具有 8.0.17 或更高版本。1. 该组的最低成员版本，包括补丁级别2. 根据步骤-1，该组中版本最低成员的成员权重较高3. 服务器 uuid 的词法排序在相同成员权重的组内是最低的
例子例1：主成员退出后的小组：8.0.19 / 8.0.20 / 8.0.208.0.19 将因其最低版本，开始被选为主服务器。例2：主成员退出后的小组：8.0.19 权重：90 / 8.0.19 权重：50 / 8.0.20 权重：90 / 8.0.20 权重：95“版本 8.0.19 权重：90”的服务器将被选为主要服务器，因为它是组内的最低版本且有较高的权重。例3：主成员退出后的小组：
8.0.19 权重：90 uuid：5a5d0f6e-6ad1-11e7-9aee-f48c5048ab0c
8.0.19 权重：90 uuid：5a67adc9-6ad1-11e7-9b1f-f48c5048ab0c
8.0.19 权重：50 uuid：5a6e5078-6ad1-11e7-9bce-f48c5048ab0c
“8.0.19 权重：90 uuid：5a5d0f6e-6ad1-11e7-9aee-f48c5048ab0c”的服务器将被选为主，因为其具有较高成员权重和最低服务器 uuid。具有至少一个 8.0.16 或更低成员版本的组
该组中至少有 1 名成员，版本低于 8.0.17。
1. 考虑主要版本的该组的最低成员版本
2. 根据步骤-1，该组中最低成员的成员权重较高
3. 服务器 uuid 的词法排序在相同成员权重的组内是最低的例子
例1：主成员退出后的小组：
5.7.22 / 8.0.20 / 8.0.20
5.7.22 版本的服务器将从其最低版本的组中被选为主服务器。
用户触发主切换
如果主成员被修改为使用UDF，group_replication_set_as_primary（server_uuid）或 group_replication_switch_to_single_primary_mode（[server_uuid]），则还会采取一些预防措施以确保所有成员兼容并可以执行所需的更改。算法如下：
具有 8.0.17 或更高版本成员的组
该组中的所有成员都具有 8.0.17 或更高版本。
1. 如果提供了 server_uuid，则该服务器将成为主成员，如果其版本在组中最低（考虑补丁级别），否则将引发错误。
2. 如果未提供 server_uuid，则考虑组成员版本直到补丁级别进行选举。例子例1：多主模式到单主模式切换时的组成员：
8.0.19 权重：50 / 8.0.20 权重：90 / 8.0.20 权重：95
“版本 8.0.19 权重：50”的服务器将被选为主服务器，因为它的补丁是该组的最低版本。具有至少一个 8.0.16 或更低成员版本的组
该组中至少有 1 名成员，版本低于8.0.17。
1. 如果组中的任何成员的版本为 5.7 或版本低于 8.0.13，则该函数不会对主成员进行任何更改。
2. 如果主要版本 8 提供的 server_uuid，那么该服务器将成为主成员，否则将抛出错误。
3. 如果未提供 server_uuid，则考虑到组成员版本的唯一主版本，将进行选举。
注意：对于 UDF group_replication_set_as_primary，server_uuid 是必需的。如果未提供 server_uuid，UDF 将失败。
例子
例1：多主模式到单主模式切换时的组成员：
8.0.14 权重：90 / 8.0.20 权重：50 / 8.0.20 权重：90 / 8.0.20 权重：95
“版本 8.0.20 权重：95”的服务器将被选为主服务器，因为该组的最低主要版本（由于组中存在 8.0.14 而忽略了维护版本）。
写版本兼容性
从 8.0.17 开始，如果新成员版本高于组的最低成员版本（考虑补丁级别），则新成员将处于只读模式。
如果该组通过执行 UDF group_replication_switch_to_multi_primary_mode 进入多主模式，则该组的最低成员版本将是可写的，而其他成员将处于只读状态。
版本为 8.0.16 或更低版本的成员，如果组中的任何成员具有 5.7 版本，则以只读模式加入组。版本 5.7 的成员始终可写，因为 5.7 仅考虑主要版本。在 MySQL 5.7 和 8.0 中，直到补丁级别 16，当低版本成员离开组时，用户必须手动重新配置只读模式。
注意：这仅适用于多主模式。例子
例1：多主模式的组成员：
8.0.19 / 8.0.20
版本 8.0.19 的服务器将是可写的，而 8.0.20 将是只读的。
例2：组成员在单主模式到多主模式切换期间：
8.0.19（主）/ 8.0.19（副）/ 8.0.20（副）/ 8.0.21（副）
版本 8.0.19 的服务器将是可写的，而 8.0.20 和 8.0.21 将是只读的多主模式开关。
例3：多主模式的组成员：
5.7.21 / 8.0.15
版本为 5.7.21 的服务器是可写的，而 8.0.15 将是只读的。
例4：组成员在单主模式到多主模式切换期间：8.0.14（副）/ 8.0.15（副）/ 8.0.20（副）/ 8.0.21（主）
版本 8.0.14 和 8.0.15 的服务器是可写的（旧版本），而 8.0.20 和 8.0.21 将是只读的。Server 8.0.21 将启用只读模式。
最低版本兼容性
从 8.0.17 开始，如果新成员版本低于该组的最低成员版本（考虑补丁级别），则新成员将不加入该组。
版本 5.7 的成员无法加入仅包含 8.0+ 成员的组。8.0.16 或更低版本的成员可以加入任何组，因为它只考虑主要版本。例子
例1：小组成员：
8.0.19 / 8.0.20 / 8.0.20
版本为 8.0.17 或 8.0.18 的服务器将无法加入该组。
例2：小组成员：
8.0.15 / 8.0.16
版本为 5.7.27 的服务器将无法加入该组。
捐赠者版本兼容性
从 8.0.17 开始，在形成可能的捐赠者组列表的同时，具有与新成员相同或更低版本的 ONLINE 成员被视为有效捐赠者。但是，如果设置了 allow_local_lower_version_join，则该组的所有 ONLINE 成员都可以充当有效的捐赠者，因为没有相同或更低版本的成员。
5.7 级别或 MySQL 8.0 至 8.0.16 的组复制版本将所有 ONLINE 成员视为恢复的主动捐助者。例子
例1：组成员：
5.7.22 / 8.0.20 / 8.0.21
新成员 8.0.20 可以使用 5.7.22 或 8.0.20 作为捐赠者。
例2：组成员：
5.7.22 / 8.0.20 / 8.0.21
新成员 5.7.22 可以使用 5.7.22, 8.0.20 或 8.0.20 作为捐赠者。
升级
对于单主升级，用户可以先更新每个副成员，然后再更新主成员。
以后的用户可以使用 UDF group_replication_set_as_primary 使所需的成员成为主成员。或者用户可以将更高的成员权重分配给所需的成员和升级组，首先升级所需的主成员。
对于多主升级，可以按任何顺序升级成员。在完成组升级的过程中，由于版本较高，升级后的成员将处于只读模式。一旦该组的所有成员升级到相同的补丁级别，所有成员都将变为可写。
关于不期望升级的一些注意事项：
如果其版本低于该组的最低成员版本，则成员将不会加入该组（考虑补丁级别）
∘ 如果升级后，版本不会是相同的补丁级别，则应首先启动新的最低成员版本。
如果组中的所有成员的版本都大于 8.0.16，则只有当成员是组中的最低版本（包括修补程序级别）时，才允许该成员成为主要成员。
∘ 如果主要升级后必须保持相同的升级，则主要升级（包括补丁级别）可能不会通过此 WL。应将组的辅助成员升级到高于或等于主要成员版本的版本。例子
例1（单主升级）
M1：8.0.20（旧主）/ M2：8.0.20（新主）/ M3：8.0.20
1. DBA 希望将所有组成员升级到 8.0.21
2. 在 M2 上设置更高的成员权重并升级 M2
3. 立即升级 M3 和 M1
4. M1 和 M3 升级后， M2 将成为主要
例2（单主升级）
M1：8.0.20（主）/ M2：8.0.20 / M3：8.0.20
1. DBA 希望将所有组成员升级到 8.0.21
2. 将 M2 和 M3 升级到 8.0.21 或更高版本
3. 在 M2 和 M3 升级后，M1 可以升级到 8.0.21
4. 使用 UDF group_replication_set_as_primary M1 可以成为主
例3：（多主升级）
M1：8.0.20 / M2：8.0.20
1. DBA 希望将所有组成员升级到 8.0.21
2. 升级 M1
3. M1 升级后，M1 将是只读的，直到 M2 升级到 8.0.21
4. 一旦 M2 升级到 8.0.21，M1 将变为可写
结论
MySQL 8.0.17 是公开可用的，随之而来的是对组复制的改进。现在，组复制可以增加安全性，并确保成员生成的事务与组中的每个成员兼容。
