mgr未同步 mysql_MySQL复制(十八) 官方的分布式解决方案MGR！

最新推荐文章于 2022-01-19 17:30:00 发布

weixin_39642622

最新推荐文章于 2022-01-19 17:30:00 发布

阅读量99

点赞数

文章标签： mgr未同步 mysql

本文链接：https://blog.csdn.net/weixin_39642622/article/details/112150652

版权

“
MySQL从5.7.17通过引入组复制^[1]的架构，通过在MySQL 8.0的不断优化，提高了MGR的可用性，很多企业或团队都已经在项目中使用(可参考：MySQL Group Replication性能测试，星辰大海还是前路茫茫？^[2]，Galera将死——MySQL Group Replication正式发布^[3])。
”

组复制实现

MGR是MySQL原生的高可用和可扩展解决方案，以插件的方式实现分布式下数据最终一致性，主要特点：

一致性和容错性
- 使用分布式协议(类Paxos)实现容错和多节点协调
- 自动检测节点状态，能自动选举
扩展性
- 支持节点的新增和删除，并能实现数据同步
- 支持单个Primary和多个Primary模式(单节点写或多节点写)

MGR架构：对写的事务，需要组内进行验证是否有冲突，投票决定能否提交。

多组模式下故障切换：可以结合MySQL Router中间件实现故障的屏蔽。

配置组复制

复制相关配置

server_id=1 #每个成员唯一
gtid_mode=ON
enforce_gtid_consistency=ON
master_info_repository=TABLE
relay_log_info_repository=TABLE
binlog_checksum=NONE #8.0.21 支持CRC32
log_slave_updates=ON
log_bin=binlog
binlog_format=ROW

组复制相关配置(8.0.16+)

transaction_write_set_extraction=XXHASH64 # 对每个事务的写集，使用XXHASH64算法进行编码
loose-group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa" #集群组名称
loose-group_replication_start_on_boot=off #是否随服务开启自动组复制
loose-group_replication_local_address= "10.xx.xx.1:24901" #集群本地端口，跟其他成员通信
loose-group_replication_group_seeds= "10.xx.xx.1:24901,10.xx.xx.2:24901,10.xx.xx.3:24901" #需要加入复制组的成员列表
loose-group_replication_bootstrap_group= off #节点是否为主节点，一个复制组只能有一个
group_replication_message_cache_size=1073741824
group_replication_autorejoin_tries=3
group_replication_member_expel_timeout=5

复制账号

组复制使用异步复制协议完成分布式恢复，在加入组时，需要先进行恢复，每个成员都需要创建。

SET SQL_LOG_BIN=0;
CREATE USER rpl_user@'%';
GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%' IDENTIFIED BY 'xx';
SET SQL_LOG_BIN=1;
CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='xx' FOR CHANNEL 'group_replication_recovery';

启动组复制

-- `安装插件`
INSTALL PLUGIN group_replication SONAME 'group_replication.so';

-- `开启组复制，bootstrap仅仅在单台服务器做一次`
SET GLOBAL group_replication_bootstrap_group=ON;
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group=OFF;

-- `查看复制组状态`
SELECT * FROM performance_schema.replication_group_members;

往组里面添加成员

监控组复制

组复制维护

多主和单主模式
- 默认为单主模式
- 不管哪种模式，MGR不处理客户端侧的fail-over
- 当在多主模式下，事务隔离级别不能为SERIALIZABLE，表不能有外键，选项 group_replication_enforce_update_everywhere_checks控制是否开启检查
- 当单主模式下，需关闭 group_replication_enforce_update_everywhere_checks
单主模式下
- bootstrap的节点为读写模式，其他节点自动设置为read_only，包括super_read_only
- 查找当前primary
  - SELECT VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME= 'group_replication_primary_member';

组复制限制和要求^[4]

要求
- 必须使用Innodb存储引擎，事务在提交时检查冲突，如果出现冲突，其他事务需要回滚，需要支持事务的存储引擎
- 主键，在进行事务冲突检查时用于标识每个事务修改的行
- 启用二进制日志(binlog)
- slave记录binlog(log_slave_updates)，需要用于恢复等
- 使用row格式的binlog，从日志中提取信息进行冲突检测
- 开启GTID，以标识事务唯一性
- 存储复制信息到TABLE(master_info_repository=TABLE,relay_log_info_repository=TABLE)
- 提取事务写集(transaction_write_set_extraction=XXHASH64)，用于检测冲突
限制
- MGR跟复制事件checksum不兼容(binlog_checksum=NONE)，8.0.21开始支持CRC32
- 不支持GAP锁，除非使用RR隔离级别，GR推荐使用RC事务隔离级别
- 不支持表锁(LOCK TABLES)和GET_LOCK()
- 不支持保存点，链式事务
- 多PRIMARY组复制环境，不支持SERIALIZABLE事务隔离级别
- 在不同服务器执行同一个对象的DDL语句，将不能检测到冲突
- 在多PRIMARY环境，不支持级联约束外键，因为不能确定冲突检查，在多PRIMARY环境，使用参数group_replication_enforce_update_everywhere_checks=ON避免未检测到的冲突
- 一个组最多9台server