我的编程空间,编程开发者的网络收藏夹
学习永远不晚

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

短信预约 -IT技能 免费直播动态提醒
省份

北京

  • 北京
  • 上海
  • 天津
  • 重庆
  • 河北
  • 山东
  • 辽宁
  • 黑龙江
  • 吉林
  • 甘肃
  • 青海
  • 河南
  • 江苏
  • 湖北
  • 湖南
  • 江西
  • 浙江
  • 广东
  • 云南
  • 福建
  • 海南
  • 山西
  • 四川
  • 陕西
  • 贵州
  • 安徽
  • 广西
  • 内蒙
  • 西藏
  • 新疆
  • 宁夏
  • 兵团
手机号立即预约

请填写图片验证码后获取短信验证码

看不清楚,换张图片

免费获取短信验证码

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

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
sonsul简介
微服务架构中非常重的一个模块,提供服务注册、服务发现等,常用的服务发现模块有,zookeeper、enreka、etcd、cunsul等。
MySQL MGR+ Consul之数据库高可用方案最佳实践
cousul是分布式、高可用、可横向发展的中间键,其特性如下:
1、service discovery:通过dns或者http接口提供服务注册和发现
2、health checking:自带健康检查,可提供服务故障时的转移
3、key/value storage:可存储动态配置的系统,提供http接口,
4、multi-datacenter:可以支持多数据中心

环境说明:
10.88.128.163 consul server 目前只部署了一个server,可部署集群模式
10.88.6.251 mysql server  mnode1、consul client
10.88.6.252 mysql server  mnode2、consul client
10.88.6.253 mysql server  mnode3、consul client
系统版本:centos 7.4
Mysql version:5.7.25
consul version:1.2.3

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"

mnode1:
登陆mysql
创建mysql账号,执行如下命令,创建账号关闭binglog
mysql> SET SQL_LOG_BIN=0;
Query OK, 0 rows affected (0.00 sec)

mysql> GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%' IDENTIFIED BY ‘pan@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';

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';

mysql> INSTALL PLUGIN group_replication SONAME 'group_replication.so';
Query OK, 0 rows affected (0.16 sec)

set global group_replication_allow_local_disjoint_gtids_join=ON;
Query OK, 0 rows affected (0.00 sec) mysql> START GROUP_REPLICATION;
Query OK, 0 rows affected (44,88 sec) mysql> SELECT * FROM performance_schema.replication_group_members\G;
*************************** 1. row ***************************
CHANNEL_NAME: group_replication_applier
   MEMBER_ID: 3c68303c-391b-11e9-b5b5-08002788ba6b
 MEMBER_HOST: mnode3
 MEMBER_PORT: 3309
MEMBER_STATE: ONLINE
*************************** 2. row ***************************
CHANNEL_NAME: group_replication_applier
   MEMBER_ID: a7495a32-398b-11e9-bec1-080027857522
 MEMBER_HOST: mnode1
 MEMBER_PORT: 3309
MEMBER_STATE: ONLINE
*************************** 3. row ***************************
CHANNEL_NAME: group_replication_applier
   MEMBER_ID: b8ff481f-39d6-11e9-9208-0800278c8292
 MEMBER_HOST: mnode2
 MEMBER_PORT: 3309
MEMBER_STATE: ONLINE
3 rows in set (0.00 sec)

到此为止MGR集群已经搭建完毕、在启动集群的同时可以同时观察其成员的加入的整个过程
说几点注意事项:
1、保证集群的端口互通
2、保证performance_schema = 1 否则库里查不动成员
Check MGR集群
在primary上,创建库、表、以及增删改查信息,其集群内其它的节点都会有相应的操作,确认其集群可以正常提供服务
搭建consul 使其mysql-primary和mysql-slave 注册到服务发现上

consul-server:10.88.128.163
consul-client:10.88.6.251、10.88.6.252、10.88.6.253
consul安装so easy
在官网:https://www.consul.io/downloads.html下载对应的版本,解压后copy consul 到/usr/local/bin/下即可

分别在4台机器上安装然后运行
mkdir -pv /etc/consul.d/  && mkdir -pv /data/consul/
mkdir -pv /data/consul/shell

在consul server 10.88.128.163上 编写配置文件
vim /etc/consul.d/server.json
{
  "data_dir": "/data/consul",
  "datacenter": "dc1",
  "log_level": "INFO",
  "server": true,
  "advertise_addr":"10.88.128.163",
  "bootstrap_expect": 3,
  "bind_addr": "10.88.128.163",
  "client_addr": "10.88.128.163",
  "ui":true
}

在consul client 10.88.6.251、10.88.6.252、10.88.6.253上编写配置文件,三台服务器的上bind_addr 修改为响应IP即可
vim cat /etc/consul.d/client.json
{
  "data_dir": "/data/consul",
  "enable_script_checks": true,
  "bind_addr": "10.88.6.252",
  "retry_join": ["10.88.128.163"],
  "retry_interval": "30s",
  "rejoin_after_leave": true,
  "start_join": ["10.88.128.163"]
}
 
启动consul server 在10.88.128.163上
nohup consul agent -config-dir=/etc/consul.d > /data/consul/consul.log &

启动consul client 在10.88.6.251、10.88.6.252、10.88.6.253
nohup consul agent -config-dir=/etc/consul.d > /data/consul/consul.log &
观察consul server的log日志3个client自动注册到了consul上了

查看consul成员


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

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

访问consulserver的web页面 http://10.88.128.163:8500/ui/

MySQL MGR+ Consul之数据库高可用方案最佳实践 到此为止consul 集群已经搭建成功了

下面我们继续为实现mysql的高可用集群 MGR+Consul高可用实现

检测MGR集群状态
MySQL MGR+ Consul之数据库高可用方案最佳实践
查看那个是主节点

MySQL MGR+ Consul之数据库高可用方案最佳实践 分别在三台mysql server的主机上
检测primay 脚本
vim /data/consul/shell/check_mysql_mgr_master.sh
#!/bin/bash
port=3309
user="root"
passwod="123"

comm="/usr/local/mysql/bin/mysql -u$user -h 127.0.0.1 -P $port -p$passwod"
value=`$comm -Nse "select 1"`
primary_member=`$comm -Nse "select variable_value from performance_schema.global_status WHERE VARIABLE_NAME= 'group_replication_primary_member'"`
server_uuid=`$comm -Nse "select variable_value from performance_schema.global_variables where VARIABLE_NAME='server_uuid';"` # 判断mysql是否存活
if [ -z $value ]
then
   echo "mysql $port is down....."
   exit 2
fi # 判断节点状态
node_state=`$comm -Nse "select MEMBER_STATE from performance_schema.replication_group_members where MEMBER_ID='$server_uuid'"`
if [ $node_state != "ONLINE" ]
then
   echo "MySQL $port state is not online...."
   exit 2
fi # 判断是不是主节点
if [[ $server_uuid == $primary_member ]]
then
   echo "MySQL $port  Instance is master ........"
   exit 0
else
   echo "MySQL $port  Instance is slave ........"
   exit 2
fi

检测slave脚本
vim /data/consul/shell/check_mysql_mgr_slave.sh

#!/bin/bash
port=3309
user="root"
passwod="123"

comm="/usr/local/mysql/bin/mysql -u$user -h 127.0.0.1 -P $port -p$passwod"
value=`$comm -Nse "select 1"`
primary_member=`$comm -Nse "select variable_value from performance_schema.global_status WHERE VARIABLE_NAME= 'group_replication_primary_member'"`
server_uuid=`$comm -Nse "select variable_value from performance_schema.global_variables where VARIABLE_NAME='server_uuid';"` # 判断mysql是否存活
if [ -z $value ]
then
   echo "mysql $port is down....."
   exit 2
fi

# 判断节点状态
node_state=`$comm -Nse "select MEMBER_STATE from performance_schema.replication_group_members where MEMBER_ID='$server_uuid'"`
if [ $node_state != "ONLINE" ]
then
   echo "MySQL $port state is not online...."
   exit 2
fi # 判断是不是主节点
if [[ $server_uuid != $primary_member ]]
then
   echo "MySQL $port  Instance is slave ........"
   exit 0
else
   node_num=`$comm -Nse "select count(*) from  performance_schema.replication_group_members"`
   # 判断如果没有任何从节点,主节点也注册从角色服务。
   if [ $node_num -eq 1 ]
   then
       echo "MySQL $port  Instance is slave ........"
       exit 0
   else
       echo "MySQL $port  Instance is master ........"
       exit 2
   fi
fi

consul client端接服务发现的json脚本

检测master
[root@mnode1 consul.d]# cat /etc/consul.d/master.json
{
  "services": [
    {
      "name": "write-mysql-primary",
      "tags": [
        "master-write"
      ],
      "address": "10.88.6.251",
      "port": 3309,
      "checks": [
        {
           "Args":["/data/consul/shell/check_mysql_mgr_master.sh"],
          "Shell": "/bin/bash",
          "interval": "15s"
        }
      ]
    }
  ]
}
检测slave
 cat /etc/consul.d/slave.json
{
  "services": [
    {
      "name": "read-mysql-slave",
      "tags": [
        "slave-read"
      ],
      "address": "10.88.6.251",
      "port": 3309,
      "checks": [
        {
           "Args":["/data/consul/shell/check_mysql_mgr_slave.sh"],
           "Shell": "/bin/bash",
           "interval": "15s"
        }
      ]
    }
  ]

基于不同consul版本配置可能不太一样,三台机器都需要相应的json脚本检测mysql是否为主或从,配置文件修改相应的IP即可使用

查看consul server ui界面即可看到三台mysql的mgr集群已经注册到consul服务上了

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

注意:由于每台mysql server 上都有master、slave 检测脚本、而mysql server 只能是master 或者slave、所以存在失败的检测,master检测只有一个成功,slave检测只有一个失败

consul dns配置
查看dns信息

MySQL MGR+ Consul之数据库高可用方案最佳实践 App端配置域名服务器IP来解析consul后缀的域名,DNS解析及跳转, 有三个方案:
1. 原内网dns服务器,做域名转发,consul后缀的,都转到consul server上,目前采用的这种方式
2. dns全部跳到consul DNS服务器上,非consul后缀的,使用 recursors 属性跳转到原DNS服务器上
3. dnsmaq 转: server=/consul/10.16.X.X#8600 解析consul后缀的
我们内网dns是用的bind,对于bind的如何做域名转发consul官网也有栗子:https://www.consul.io/docs/guides/forwarding.html check下MGR 切换master 解析的IP是否转换

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

切换mgr primary

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

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




参考:https://www.consul.io
           https://www.jianshu.com/p/ca1af156f656
           https://blog.csdn.net/sinat_36888624/article/details/79215233
           https://www.cnblogs.com/gomysql/p/8985774.html
           http://www.cnblogs.com/gomysql/p/8010552.html
    
    
    

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

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

下载Word文档到电脑,方便收藏和打印~

下载Word文档

猜你喜欢

数据库事务隔离级别最佳实践:打造高可用、高一致性的数据库系统

数据库事务隔离级别是保证数据库并发操作数据完整性和一致性的关键,选择合适的隔离级别对于保障数据库的可用性和一致性至关重要。本文将探讨数据库事务隔离级别的不同级别,并提供最佳实践建议,帮助您打造高可用、高一致性的数据库系统。
数据库事务隔离级别最佳实践:打造高可用、高一致性的数据库系统
2024-02-10

MySQL INSERT锁与数据库高可用方案

MySQL INSERT锁是指在向数据库中插入新数据时,会对相关表进行加锁操作,防止其他操作对该表进行修改或插入操作。这种锁可以保证数据的一致性和完整性,但有可能会导致性能下降,特别是在高并发的情况下。对于数据库高可用方案,可以考虑以下几
MySQL INSERT锁与数据库高可用方案
2024-08-18

阿里云数据库高可用方案实现稳定可靠的数据管理

随着云计算和大数据时代的到来,数据库成为企业存储和处理海量数据的重要工具。然而,数据库的高可用性一直是企业关注的重点,因为数据库宕机可能导致业务中断、数据丢失等问题。阿里云数据库高可用方案提供了一种稳定可靠的解决方案,帮助企业实现数据库的高可用性。详细说明:1.主备架构阿里云数据库高可用方案的核心是主备架构,通过
阿里云数据库高可用方案实现稳定可靠的数据管理
2023-12-27

如何在Oracle数据库中实施容灾和高可用性解决方案

在Oracle数据库中实施容灾和高可用性解决方案通常使用以下方法:数据库备份和恢复:定期备份数据库,并确保备份数据可恢复。可以使用Oracle的RMAN工具来管理数据库备份和恢复。数据库复制:使用Oracle的数据复制功能来将数据库数据复制
如何在Oracle数据库中实施容灾和高可用性解决方案
2024-03-02

阿里云数据库代理服务——实现高可用性和高性能的数据库连接解决方案

阿里云数据库代理服务是一种用于实现数据库高可用性和高性能的解决方案。它通过在客户端和数据库之间建立一个代理服务器,将客户端请求转发到后端数据库,并处理请求并返回结果给客户端。本文将详细介绍阿里云数据库代理服务的功能、优势以及应用场景。详细说明:功能介绍阿里云数据库代理服务(DatabaseProxyService
阿里云数据库代理服务——实现高可用性和高性能的数据库连接解决方案
2024-01-17

编程热搜

目录