这是学习笔记的第 1770篇文章

今天来简单理一下MGR和consul的组合方案,前期的准备和步骤还是比较多的,晚上完成了基础的调试,来来回回切换了好多次,还算有点意思。

首先要部署的就是consul服务,consul服务其实可以分为 consul server和consul agent, consul server的部署是分布式架构,所以最少需要3台服务器,而对于consul agent基于agent模式,部署起来也很便捷。

所以如果要完整的模拟一套consul+MGR的完整环境,我们可能需要配置如下的服务器:

6台服务器,其中3台作为consul server,另外3台作为MySQL服务器,单主模式,三个数据库实例节点的方式。其中consul server的3台服务器不是MGR集群独有,可以对接更多的业务,所以属于全局的需求,不是为了MGR特意定制。

第一阶段  consul服务部署

使用consul的方式查看集群的信息如下,可以看到是3个consul server,3台作为MGR节点。

[root@MySQL6 data]# consul members

Node             Address            Status  Type    Build  Protocol  DC          Segment

tkconsulserver1  192.168.56.3:8301  alive   server  1.2.1  2         company-b1  <all>

tkconsulserver2  192.168.56.4:8301  alive   server  1.2.1  2         company-b1  <all>

tkconsulserver3  192.168.56.5:8301  alive   server  1.2.1  2         company-b1  <all>

tkconsulclient4  192.168.56.6:8301  alive   client  1.2.1  2         company-b1  <default>

tkconsulclient5  192.168.56.7:8301  alive   client  1.2.1  2         company-b1  <default>

tkconsulclient6  192.168.56.8:8301  alive   client  1.2.1  2         company-b1  <default>

consul server是这三台服务器:

192.168.56.3

192.168.56.4

192.168.56.5

主要的server的配置就需要一个server.json,这里有一个重要概念就是domain,这里是tk,也就是我们所属的一个域,通过域的方式来提供访问。

对于每台机器来说,advertise_addr是根据每台的实际IP来的,这里是192.168.56.3的服务器的配置,56.4,56.5的配置就可以按照类似的方式来做。

[root@MySQL3 consul]# cat server.json

{

"addresses": {

"http": "0.0.0.0",

"dns": "0.0.0.0"

},

"bind_addr": "0.0.0.0",

"advertise_addr": "192.168.56.3",

"bootstrap_expect": 3,

"datacenter": "company-b1",

"data_dir": "/data/consul",

"dns_config": {

"allow_stale": true,

"max_stale": "87600h",

"node_ttl": "0s",

"service_ttl": {

"*": "0s"

}

},

  "domain": "tk",

"enable_syslog": false,

"leave_on_terminate": false,

"log_level": "info",

"node_name": "tkconsulserver1",

"node_meta": {

"location": "B1 in test"

},

"performance": {

"raft_multiplier": 1

},

"ports": {

"http": 8500,

"dns": 53

},

"reconnect_timeout": "72h",

"recursors": [

"192.168.56.4",

"192.168.56.5"

],

"retry_join": [

"192.168.56.4",

"192.168.56.5"

],

"retry_interval": "10s",

"server": true,

"skip_leave_on_interrupt": true,

"ui": true

}

对于客户端来说,需要的是一个client.json,这里就需要配置所有的consul server

[root@MySQL8 consul]#  cat client.json

{

"addresses": {

"http": "0.0.0.0",

"dns": "0.0.0.0"

},

"bind_addr": "0.0.0.0",

"advertise_addr": "192.168.56.8",

"datacenter": "company-b1",

"data_dir": "/data/consul",

"enable_script_checks": true,

"enable_syslog": false,

"leave_on_terminate": true,

"log_level": "info",

"node_name": "tkconsulclient6",

"node_meta": {

"location": "B1 in test"

},

"ports": {

"dns": 8600,

"http": 8500

},

"rejoin_after_leave": true,

"retry_join": [

"192.168.56.3",

"192.168.56.4",

"192.168.56.5"

],

"retry_interval": "10s",

"skip_leave_on_interrupt": false

}

值得一提的是,客户端怎么去识别consul server发布的服务呢,这个是consul支持的域名服务来解决的,所以对于客户端来说,我们需要配置一下域名设置,把它们都指向consul server集群即可。

[root@MySQL6 data]# cat /etc/resolv.conf

; generated by /sbin/dhclient-script

nameserver 192.168.56.3

nameserver 192.168.56.4

nameserver 192.168.56.5

有了这种方式,我们就不用配置/etc/hosts来做本地域名解析了。

consul服务可以使用如下的命令来重启,或者可以使用supervisor来做。

/etc/init.d/consul_agent restart

第二阶段  MySQL集群MGR服务部署

部署MGR的部分完全可以做到自动化部署来快捷实现,如果本地要测试MGR,可以参考我之前写的一个开源脚本。

我们来简单说明下手工在多台服务器上部署的细节。

我们预期的架构是三个节点,单主模式

192.168.56.7  Primary        端口:24801  内部端口:24901

192.168.56.6  Secondary   端口:24801  内部端口:24901

192.168.56.8  Secondary   端口:24801  内部端口:24901

MGR的版本相对来说是越新越好,我们选择的是MySQL 5.7.23

安装的数据目录在/data/mgr/s1下面。

使用如下的方式来初始化:

/usr/local/mysql_5.7.23/bin/mysqld --no-defaults --basedir=/usr/local/mysql_5.7.23 --datadir=/data/mgr/s1 --explicit_defaults_for_timestamp   --initialize-insecure

然后配置参数文件,这是一个模板,里面需要注意的就是loose-group_replication_local_address是本地的IP,loose-group_replication_group_seeds是一个子集,不包含自己,为了方便测试,我们把参数文件放到数据目录下面。

参数文件内容如下:

[mysqld]

# server configuration

datadir=/data/mgr/s1

basedir=/usr/local/mysql_5.7.23

port=24801

socket=/data/mgr/s1/s1.sock

server_id=24803

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

transaction_write_set_extraction=XXHASH64

loose-group_replication_group_name="1bb1b861-f776-11e6-be42-782bcb377193"

loose-group_replication_start_on_boot=off

loose-group_replication_local_address= "192.168.56.8:24901"

loose-group_replication_group_seeds= "192.168.56.6:24901,192.168.56.7:24901"

loose-group_replication_bootstrap_group= off

我们需要配置数据目录的属主是mysql.mysql

chown -R mysql.mysql /data/mgr/s1

然后使用如下的方式来启动MySQL服务。

/usr/local/mysql_5.7.23/bin/mysqld_safe --defaults-file=/data/mgr/s1/s1.cnf  &

节点1创建复制用户:

create user rpl_user@'%';

grant replication slave on *.* to rpl_user@'%' identified by 'rpl_pass';

三个节点都执行如下的步骤,安装复制插件,配置复制关系。

INSTALL PLUGIN group_replication SONAME 'group_replication.so';

show plugins;

change master to master_user='rpl_user',master_password='rpl_pass' for channel 'group_replication_recovery';

节点1开启group replication的步骤如下:

SET GLOBAL group_replication_bootstrap_group = ON;

START GROUP_REPLICATION;

SELECT * FROM performance_schema.replication_group_members;

节点2和节点3的操作如下:

set global group_replication_allow_local_disjoint_gtids_join=ON;

START GROUP_REPLICATION;

按照这种方式启动集群基本上还是比较顺畅的。

在这个基础上,我们队集群做一些验证测试。

第三阶段  MySQL集群MGR和consul结合

MGR集群在可用的前提下,接入consul实现平滑的切换是本次测试的重中之重。根据consul的机制,我们需要提供相应的健康检查脚本。

参考了网上的一些脚本,自己稍作改进:

Primary节点的健康检查脚本如下,角色完全可以基于MGR自己的数据字典来完成。

[root@MySQL6 data]# cat /data/consul/scripts/check_mgr_primary.sh

#!/bin/bash

port=$1

user="root"

comm="/usr/local/mysql_5.7.23/bin/mysql -u$user -h 127.0.0.1 -P $port "

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

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

Secondary节点的健康检查脚本如下:

[root@MySQL6 data]# cat  /data/consul/scripts/check_mgr_secondary.sh

#!/bin/bash

port=$1

user="root"

comm="/usr/local/mysql_5.7.23/bin/mysql -u$user -h 127.0.0.1 -P $port "

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

这里的重点是需要配置文件,我们可以归类为两类,一类是读请求,是只能对接到Primary节点,还有两个读节点,可以通过consul域名的方式实现负载均衡。所以我们根据这个需求可以定制两个json模板。

写节点的json配置

[root@MySQL8 consul]# cat

{

"services": [

{

"id": "mysql_mgr_w",

"name": "test24801-mysql_w",

"address": "",

"port": 24801,

"enable_tag_override": false,

"checks": [

{

"id": "mysql_mgr_w-check-01",

"name": "MySQL Write Check",

"args": ["/data/consul/scripts/check_mgr_primary.sh","24801"],

"interval": "15s",

"timeout": "1s",

"service_id": "mysql_mgr_w"

}

]

}

]

}

读节点的json配置:

[root@MySQL8 consul]# cat test_mgr_read.db.json

{

"services": [

{

"id": "mysql_mgr_r",

"name": "test24801-mysql_r",

"address": "",

"port": 24801,

"enable_tag_override": false,

"checks": [

{

"id": "mysql_mgr_r-check-02",

"name": "MySQL Write Check",

"args": ["/data/consul/scripts/check_mgr_secondary.sh","24801"],

"interval": "15s",

"timeout": "1s",

"service_id": "mysql_mgr_r"

}

]

}

]

}

使用如下的域名方式可以解析得到写节点的IP:

ping test24801-mysql_w.service.tk

PING test24801-mysql_w.service.tk (192.168.56.7) 56(84) bytes of data.

64 bytes from MySQL7 (192.168.56.7): icmp_seq=1 ttl=64 time=0.299 ms

64 bytes from MySQL7 (192.168.56.7): icmp_seq=2 ttl=64 time=0.340 ms

而对于读节点来说,可以通过负载均衡来对接两个读节点

我们可以使用这种方式来解析对应的DNS

[root@MySQL8 consul]# ping test24801-mysql_r.service.tk

PING test24801-mysql_r.service.tk (192.168.56.6) 56(84) bytes of data.

64 bytes from MySQL6 (192.168.56.6): icmp_seq=1 ttl=64 time=0.281 ms

^C

--- test24801-mysql_r.service.tk ping statistics ---

1 packets transmitted, 1 received, 0% packet loss, time 862ms

rtt min/avg/max/mdev = 0.281/0.281/0.281/0.000 ms

.....

[root@MySQL8 consul]# ping test24801-mysql_r.service.tk

PING test24801-mysql_r.service.tk (192.168.56.8) 56(84) bytes of data.

64 bytes from MySQL8 (192.168.56.8): icmp_seq=1 ttl=64 time=0.008 ms

64 bytes from MySQL8 (192.168.56.8): icmp_seq=2 ttl=64 time=0.029 ms

到了这个阶段开始,基本的任务就完成了。可以kill掉56.7节点上的MySQL实例进程,然后集群会依次切换,会有56.8的节点来接管,作为新的Primary。consul服务会在这个过程中完成服务的注销和自动发现,这也就是配置脚本test_mgr_read.db.json 和  test_mgr_write.db.json 来对接的。

后续根据大家的反馈来不断的细化和完善。

MySQL高可用方案MGR+consul组合测试相关推荐

  1. 【MySQL高可用】MySQL高可用之MGR部署

    [MySQL高可用]MySQL高可用之MGR部署 参考:https://www.xmmup.com/dbbao45mysqlgaokeyongzhimgrconsuljiagoubushu.html ...

  2. MySQL高可用方案-PXC(Percona XtraDB Cluster)环境部署详解

    MySQL高可用方案-PXC(Percona XtraDB Cluster)环境部署详解 Percona XtraDB Cluster简称PXC.Percona Xtradb Cluster的实现是在 ...

  3. MySQL高可用方案-PXC环境部署记录

    之前梳理了Mysql+Keepalived双主热备高可用操作记录,对于mysql高可用方案,经常用到的的主要有下面三种: 一.基于主从复制的高可用方案:双节点主从 + keepalived 一般来说, ...

  4. MYSQL(高可用方案)

    本次专题是 MySQL高可用方案选型,这个专题想必有很多同学感兴趣. 高可用的意义以及各种不同高可用等级相应的停机时间我就不必多说了,直接进入主题. 可选MySQL高可用方案 MySQL的各种高可用方 ...

  5. 带你玩转Mysql高可用方案--PXC

    目录 理论篇 基于Galere协议的高可用方案:pxc PXC介绍 PXC特性 PXC优缺点 PXC原理描述 PXC的架构示意图 数据读写示意图 下面看传统复制流程 异步复制 半同步 超过10秒的阀值 ...

  6. MySQL高可用方案之MHA

    目录 一.简介 二.MHA特点 三.搭建MySQL MHA 1.安装MHA 2.在所有服务器上配置无密码认证 3.在manager节点上配置MHA 4. manager节点编辑配置文件,管理 mysq ...

  7. MySQL高可用方案选型参考

    高可用的意义以及各种不同高可用等级相应的停机时间我就不必多说了,直接进入主题. 可选MySQL高可用方案 MySQL的各种高可用方案,大多是基于以下几种基础来部署的: 基于主从复制: 基于Galera ...

  8. mysql高可用方案MHA介绍

    mysql高可用方案MHA介绍 概述 MHA是一位日本MySQL大牛用Perl写的一套MySQL故障切换方案,来保证数据库系统的高可用.在宕机的时间内(通常10-30秒内),完成故障切换,部署MHA, ...

  9. MySQL高可用方案

    作者:张  发表于:2014-08-19 版权声明:可以任意转载,转载时请务必以超链接形式标明文章原始出处和作者信息及本版权声明 (http://blog.csdn.net/mrz001 ) MySQ ...

最新文章

  1. Android滤镜效果实现及原理分析
  2. vc6.0注释功能的脚本快捷键设置代码
  3. 自定义是否允许文件继续执行下去
  4. 阿里云贾扬清:大数据+AI工程化,让数据从「成本」变为「资产」
  5. magento 插件
  6. 解决 XMLHttpRequest status = 0 问题 及 返回值为null问题
  7. Tomcat运行时报内存溢出
  8. linux网络服务错误6026,wpa_supplicant/wpa_cli无法检测到接入点的错误密钥
  9. ElementUI表单构建
  10. Spotfire调试经验——环比增长率的动态计算(Dynamic moving data percentage calculation in Spotfire visualization)
  11. 学生用计算机的使用技巧,选学生笔记本电脑的小窍门
  12. 【转载】数据中心网络架构浅谈
  13. 应用集成与数据集成建设总体思路
  14. Excel 2010 VBA 入门 129 利用窗体向工作表中录入数据
  15. 2-5 修理牧场【优先队列/最小堆】
  16. Android GoogleMap接入
  17. rk3568 移植 GPS/GNSS 模组
  18. JavaWeb项目中出现No converter found for return value of type的解决方法
  19. 影响人生的五大定律,值得一读
  20. 华为怎么改输入法皮肤_怎么设置华为手机输入法皮肤

热门文章

  1. 使用Photoshop给Premiere批量添加对白字幕听语音 |浏览:25974|更新:2013-12-23 23:18|标签:photoshop premiere 使用Photoshop给Pre
  2. Oracle中 Alter Table 语句的使用
  3. 被中国家长摧残的十种优秀儿童品质(转)
  4. 英雄联盟出现game_error_directx的解决办法
  5. python+selenium自动化能打开火狐浏览器但是打不开网址
  6. JS 下载 URL 链接文件(点击按钮、点击a标签、支持代理与非代理下载)
  7. 支付宝 APP登录 获取用户信息 PHP
  8. 智能时代悄然到来刷脸支付逐渐成为潮流
  9. 卖家后台管理项目效果预览
  10. 一个很好用的vue表单工具,快速进行表单开发