基于传统异步复制和半同步复制的缺陷——数据的一致性问题无法保证,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,监控等...
阅读 1346·2023-01-11 13:20
阅读 1684·2023-01-11 13:20
阅读 1132·2023-01-11 13:20
阅读 1858·2023-01-11 13:20
阅读 4100·2023-01-11 13:20
阅读 2704·2023-01-11 13:20
阅读 1385·2023-01-11 13:20
阅读 3597·2023-01-11 13:20