基于传统异步复制和半同步复制的缺陷——数据的一致性问题无法保证，MySQL官方在5.7.17版本正式推出组复制（MySQLGroupReplication，简称MGR），以插件形式提供，实现了分布式下数据的最终一致性,提供了高可用、高扩展、高可靠的MySQL集群服务。
MGR是一种可用于实现容错系统的技术。复制组是一个通过消息传递相互交互的Server集群，由多个Server成员组成，如上图的Master1、Master2、Master3，所有成员独立完成各自的事务。
当客户端发起一个更新事务时，该事务先在本地执行，执行完成之后就要发起对事务的提交操作。在还没有真正提交之前，需要将产生的复制写集(WRITESET)广播出去，复制到其它成员。如果冲突检测成功，组内决定该事务可以提交，其它成员可以应用，否则就回滚。
最终，所有组内成员以相同的顺序接收同一组事务。因此组内成员以相同的顺序应用相同的修改，保证组内数据强一致性。从MGR复制原理上看，当主节点事务提交时，辅助节点上可能还未重放该事务对应的BINLOG，因此MGR仍属于异步复制。
本次仅配置MGR的单主模式，采用了三台linux虚机：
IP | SERVER_ID | 服务端口 | 通信端口 |
192.168.100.110 | 1 | 3306 | 10086 |
192.168.100.111 | 2 | 3306 | 10086 |
192.168.100.112 | 3 | 3306 | 10086 |
编辑mysql参数文件，3个节点除了server_id、loose-group_replication_local_address参数不一样外，其他保持一致，因为仅演示，参数仅配置需要的参数。
192.168.100.110：
[mysqld] datadir=/data/data3306 socket=/data/data3306/mysql3306.sock user=mysql log-bin=mysql-bin server-id = 1 port=3306 pid-file=/data/data3306/pid3306.pid innodb-buffer-pool-size=300m basedir=/opt/mysql log-error=/data/data3306/3306.err.log sync_binlog = 1 auto-increment-increment = 2 auto-increment-offset = 1 slave-skip-errors = all explicit_defaults_for_timestamp=ON gtid_mode=ON enforce_gtid_consistency=ON master_info_repository=TABLE relay_log_info_repository=TABLE binlog_checksum=NONE log_slave_updates=ON log_bin=binlog binlog_format=ROW #super_read_only=ON slave_parallel_type=logical_clock slave_parallel_workers=16 slave_preserve_commit_order=ON transaction_write_set_extraction=XXHASH64 loose-group_replication_single_primary_mode = true loose-group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa" loose-group_replication_start_on_boot=off loose-group_replication_local_address= "mysql-master:10086" loose-group_replication_group_seeds= "mysql-master:10086,mysql-slave:10086,Oracle19c:10086" loose-group_replication_bootstrap_group= off loose-group_replication_enforce_update_everywhere_checks = false |
192.168.100.111：
server-id = 2 loose-group_replication_local_address= "mysql-slave:10086" |
192.168.100.110：
server-id = 3 loose-group_replication_local_address= "Oracle19c:10086"——无视乱入的主机名。。。 |
关于GTID及日志信息记录相关参数：
gtid_mode=on打开GTID特性
enforce-gtid-consistency=on
master_info_repository=TABLE
relay_log_info_repository=TABLE
binlog_format=ROW 必须使用基于行的格式
binlog_checksum=NONE 禁用二进制日志事件校验和
关于MGR相关参数说明：
transaction_write_set_extraction #记录事务的算法
group_replication_start_on_boot#是否随服务器启动而自动启动组复制
group_replication_bootstrap_group#引导组成员的组，这个用于第一次搭建MGR跟重新搭建MGR的时候使用
group_replication_group_name #此GROUP的名字，必须是一个有效的UUID，以此来区分整个内网里边的各个不同的GROUP
group_replication_local_address#本地的IP地址字符串，host:port
group_replication_group_seeds #需要接受本实例的信息服务器IP地址字符串
group_replication_single_primary_mode#是否启动单主模式，如果启动，则本实例是主库，提供读写，其他实例仅提供读
group_replication_enforce_update_everywhere_checks#多主模式下，强制检查每一个实例是否允许该操作
mysql>INSTALL PLUGIN group_replication SONAME group_replication.so; |
SET SQL_LOG_BIN=0; CREATE USER repl@% IDENTIFIED BY 123; GRANT REPLICATION SLAVE ON *.* TO repl@%; FLUSH PRIVILEGES; SET SQL_LOG_BIN=1; CHANGE MASTER TO MASTER_USER=repl, MASTER_PASSWORD=123 FOR CHANNEL group_replication_recovery; |
SET GLOBAL group_replication_bootstrap_group=ON; START GROUP_REPLICATION; SET GLOBAL group_replication_bootstrap_group=OFF; |
START GROUP_REPLICATION; |
*设置复制账号时，应全部操作不写bin_log，即可不需要使用“setglobal group_replication_allow_local_disjoint_gtids_join=ON;”
可以看到，一个单主模式的MGR已经配置成功。下面来做一些同步验证。
主库（192.168.100.111）建库建表，并插入数据：
192.168.100.112：
192.168.100.110：
可以看到，在主库执行的操作均在组内其他节点得以回放，验证成功。
篇幅有限，关于MGR的简单介绍只能到这里，更多关于MGR特性的演示，只能后续再给大家呈现了，希望有兴趣的小伙伴一起交流学习。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/130114.html
摘要：对于该故障的分析，我们要从主从实例相同，但是事务不同的原因入手，该问题猜测与相关，我们针对同步事务的时序做如下分析。接受者被动接收提议者的提议，并记录和反馈，或学习达成共识的提议。节点将的提案信息发送至组内，仍收到了大多数成员返回。 本文是由爱可生运维团队出品的「MySQL专栏」系列文章，内容来自于运维团队一线实战经验，涵盖MySQL各种特性的实践，优化案例，数据库架构，HA，监控等...
阅读 1028·2023-01-11 13:20
阅读 1304·2023-01-11 13:20
阅读 815·2023-01-11 13:20
阅读 1401·2023-01-11 13:20
阅读 3712·2023-01-11 13:20
阅读 2096·2023-01-11 13:20
阅读 1084·2023-01-11 13:20
阅读 3141·2023-01-11 13:20
