MySQL MGR+ Consul之数据库高可用方案最棒实践

2022-07-31 18:43:28

字体：大中小

来源：转载

供稿：网友

MySQL MGR+ Consul之数据库高可用方案最佳实践
背景说明：
基于目前存在很多MySQL数据库单点故障,传统的MHA，PXC等方案用VIP或者DNS切换的方式可以实现、基于数据库的数据强一致性考虑，采用MGR集群，采用consul服务注册发现实现应用端通过动态DNS 访问MGR集群，实现数据库高可用，自动化切换的方案
MGR简介
MySQL Group Replication（MGR）是MySQL官方在5.7.17版本引进的一个数据库高可用与高扩展的解决方案，以插件形式提供，实现了分布式下数据的最终一致性，总结MGR特点如下：
高一致性：基于分布式paxos协议实现组复制，保证数据一致性；
高容错性：自动检测机制，只要不是大多数节点都宕机就可以继续工作，内置防脑裂保护机制；
高扩展性：节点的增加与移除会自动更新组成员信息，新节点加入后，自动从其他节点同步增量数据，直到与其他节点数据一致；
高灵活性：提供单主模式和多主模式，单主模式在主库宕机后能够自动选主，所有写入都在主节点进行，多主模式支持多节点写入。
MGR原理说明：
组复制是一种可用于实现容错系统的技术。复制组是一个通过消息传递相互交互的 server 集群。通信层提供了原子消息(atomic message)和完全有序信息交互等保障机制
实现了基于复制协议的多主更新
复制组由多个 server成员构成,并且组中的每个 server 成员可以独立地执行事务。但所有读写(RW)事务只有在冲突检测成功后才会提交。只读(RO)事务不需要在冲突检测,可以立即提交。句话说,对于任何 RW 事务,提交操作并不是由始发 server 单向决定的,而是由组来决定是否提交。准确地说,在始发 server 上,当事务准备好提交时,该 server 会广播写入值(已改变的行)和对应的写入集(已更新的行的唯一标识符)。然后会为该事务建立一个全局的顺序。最终,这意味着所有 server 成员以相同的顺序接收同一组事务。因此,所有 server 成员以相同的顺序应用相同的更改,以确保组内一致。组复制是一种 share-nothing 复制方案,其中每个 server 成员都有自己的完整数据副本。
MGR的局限性：
仅支持InnodDB存储引擎的表，并且每个表必须有主键ID, 用做wirte set的冲突检测
必须启用GTID特性，binlog日志格式必须为row模式
目前一个MGR集群最多支持9个节点
不支持外健的save point特性，无法做全局间的约束检测和部分回滚
二进制日志不支持binlog event checksum

MGR集群环境搭建
mysql的安装这里就做详细说明(有需要的话，我把自动化安装脚本放在博客上)
三台mysql server 主机都安装mysql服务并初始化密码
修改配置文件，保证三台mysql server的配置一样(serverid、IP不一致)
vim /etc/my.cnf
##gtid配置
server_id = 1 ## 保证三台主机的serverid 不一致，这里配置为1，11，111
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
innodb_buffer_pool_instances=4
innodb_buffer_pool_size=1G
innodb_flush_log_at_trx_commit=2
sync_binlog=0
#for parallel apply binlog
slave-parallel-type=LOGICAL_CLOCK
slave-parallel-workers=4
slave_preserve_commit_order=on
##mgr配置
transaction_write_set_extraction=XXHASH64
##表示将加入或者创建的复制组命名为8053c671-0622-11e8-a300-525400b9c5e8，可以自己指定
loose-group_replication_group_name=“8053c671-0622-11e8-a300-525400b9c5e8”
#设置server启动时不自动启动组复制
loose-group_replication_start_on_boot=off
#设置组复制的端口，并保证其集群可以正常访问
loose-group_replication_local_address= “10.88.6.251:33091"
#当加入组时应该连接到这些服务器上进行配置
loose-group_replication_group_seeds=“10.88.6.251:33091,10.88.6.252:33091,10.88.6.253:33091"
loose-group_replication_bootstrap_group= off
loose-group_replication_single_primary_mode=ON ##开启单主模式
#关闭多主模式
loose-group_replication_enforce_update_everywhere_checks=FALSE
#配置集群白名单
loose-group_replication_ip_whitelist="10.88.6.0/24"

mysql> INSTALL PLUGIN group_replication SONAME 'group_replication.so';
Query OK, 0 rows affected (0.16 sec)
#此引导应仅由单个 sever 独立完成,该 server 启动组并且只启动一次。这就是为什么引导配置选项的值不保存在配置文件中的原因。如果将其保存在配置文件中,则在重新启动时,server 会自动引导具有相同名称的第二
个组。这将导致两个不同的组具有相同的名称 mysql> SET GLOBAL group_replication_bootstrap_group=ON; Query OK, 0 rows affected (0.00 sec)
mysql> START GROUP_REPLICATION;
Query OK, 0 rows affected (1.78 sec)

mysql> SET GLOBAL group_replication_bootstrap_group=OFF;
Query OK, 0 rows affected (0.00 sec)

mysql>SELECT * FROM performance_schema.replication_group_members/G;
CHANNEL_NAME: group_replication_applier
MEMBER_ID: a7495a32-398b-11e9-bec1-080027857522
MEMBER_HOST: mnode1
MEMBER_PORT: 3309
MEMBER_STATE: ONLINE

Server mnode2、server mnode3

mysql> SET SQL_LOG_BIN=0;
Query OK, 0 rows affected (0.00 sec)

mysql> GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%' IDENTIFIED BY 'Workhard@345';

mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)

mysql> SET SQL_LOG_BIN=1;
Query OK, 0 rows affected (0.00 sec)

mysql> CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='pan@345' FOR CHANNEL 'group_replication_recovery';

到此为止MGR集群已经搭建完毕、在启动集群的同时可以同时观察其成员的加入的整个过程。

（编辑：错新网）

上一篇：mysql的功能优化工具

下一篇：1000行MySQL学习笔记，人手一份，提议收藏！