MySQL5.7+MHA+MAXSCAL2.0部署

据说MySQL5.7在性能和安全上有非常大的提升,这里调研一下MySQL5.7+MHA+MAXSCAL2.0的一主多从的高可用读写分离技术。

MySQL5.7新特性


此处只说明下针对运维相关的新特性,其他新功能,请参考:

  1. http://www.cnblogs.com/xuanzhi201111/p/4899960.html
  2. https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-0.html
安全性
  • 用户表 mysql.user 的 plugin字段不允许为空, 默认值是 mysql_native_password,而不是 mysql_old_password,不再支持旧密码格式;
  • 增加密码过期机制,过期后需要修改密码,否则可能会被禁用,或者进入沙箱模式;
  • 使用 mysql_install_db 初始化时,默认会自动生成随机密码,并且不创建除 root@localhost 外的其他账号,也不创建 test 库;
  • 为防止用户设置过简单的密码,mysql在5.6开始就已经支持了密码安全策略的插件
  • 提供了更为简单SSL安全访问配置,并且默认连接就采用SSL的加密方式
主从复制

MySQL5.6之前的主从复制

一般主从复制,有三个线程参与,都是单线程:Binlog Dump(主) —–>IO Thread (从) —–> SQL Thread(从)。
复制出现延迟一般出在两个地方:
1. SQL线程忙不过来(可能需要应用数据量较大,可能和从库本身的一些操作有锁和资源的冲突;主库可以并发写,SQL线程不可以;主要原因)
2. 网络抖动导致IO线程复制延迟(次要原因)

MySQL从5.6开始有了SQL Thread多个的概念,可以并发还原数据,即并行复制技术。

MySQL 5.6中,设置参数slave_parallel_workers = 4(>1),即可有4个SQL Thread(coordinator线程)来进行并行复制,其状态为:Waiting for an evant from Coordinator。
但是其并行只是基于Schema的,也就是基于库的。如果数据库实例中存在多个Schema,这样设置对于Slave复制的速度可以有比较大的提升。通常情况下单库多表是更常见的一种情形,

那基于库的并发就没有卵用。其核心思想是:不同schema下的表并发提交时的数据不会相互影响,即slave节点可以用对relay log中不同的schema各分配一个类似SQL功能的线程,来重放relay log中主库已经提交的事务,保持数据与主库一致。

MySQL5.7的主从复制

在MySQL 5.7中,引入了基于组提交的并行复制(Enhanced Multi-threaded Slaves),设置参数slave_parallel_workers>0并且global.slave_parallel_type=‘LOGICAL_CLOCK’,即可支持一个schema下,slave_parallel_workers个的worker线程并发执行relay log中主库提交的事务。其核心思想:一个组提交的事务都是可以并行回放(配合binary log group commit); slave机器的relay log中 last_committed相同的事务(sequence_num不同)可以并发执行。
其中,变量slave-parallel-type可以有两个值:DATABASE 默认值,基于库的并行复制方式;LOGICAL_CLOCK:基于组提交的并行复制方式

参考来自:
1. http://www.cnblogs.com/langdashu/p/6125621.html
2. http://www.ttlsa.com/mysql/mysql-5-7-enhanced-multi-thread-salve/

MySQL5.7 GTID

GTID简介GTID(全球交易标识符)在MySQL5.6时引入,GTID是事务的全局唯一标识.GTID结构如下:
1
2
3
GTID = source_id:transaction_id
# source_id:执行事务的原始实例的sever_uuid,此事务GTID在备库应用时也不变
# transaction_id:事务的执行编号,binlog_order_commits = 1时,此编号根据事务的提交顺序严格递增


GTID是在binlog flush生成的,因此同一个服务器ID的GTID在binglog中是严格有序的binlog_order_commits = 0时,GTID在二进制日志中也是序的,但并不一定与提交的顺序一致。
支持GTID后,备库启动时不再需要通过位点信息从主库来拉取二进制日志,而是根据备库本身已执行和拉取的GTID去主库查找第一个未执行的GTID,从此GTID位置开始拉取二进制日志。
更多内容请参考:
1. https://yq.aliyun.com/articles/68441
2. https://yq.aliyun.com/articles/57731

MHA


MHA介绍

MHA,即MasterHigh Availability Manager and Tools for MySQL,是日本的一位MySQL专家采用Perl语言编写的一个脚本管理工具,该工具仅适用于MySQLReplication(二层)环境,目的在于维持Master主库的高可用性。
MHA是自动的master故障转移和Slave提升的软件包.它是基于标准的MySQL复制(异步/半同步)
MHA有两部分组成:MHA Manager(管理节点)和MHA Node(数据节点)

1. MHA node运行在每台MySQL服务器上(master/slave/manager),它通过监控具备解析和清理logs功能的脚本来加快故障转移的
2. MHA Manager可以单独部署在一台独立机器上管理多个master-slave集群,也可以部署在一台slave上.MHA Manager探测集群的node节点,当发现master出现故障的时候,它可以自动将具有最新数据的slave提升为新的master,然后将所有其它的slave导向新的master上.整个故障转移过程对应用程序是透明的

MHA特点
  • 10-30s实现master failover(9-12s可以检测到主机故障,7-10s可以关闭主机避免SB,在用很短的时间应用差异日志)
  • 部署简单,无需对现有M-S结构做任何改动(至少3台,保证切换后仍保持M-S结构)
  • 支持手动在线切换(主机硬件维护),downtime几乎很短0.5-2s
  • 保证故障切换后多从库数据的一致性
  • 完全自动化的failover及快速复制架构恢复方案(一主多从)

详情参考:

  1. http://www.2cto.com/database/201504/389797.html
  2. http://dbaspace.blog.51cto.com/6873717/1872105
  3. http://www.cnblogs.com/xiaoyanger/p/5633459.html

MaxScale 2.0

简介

MaxScale是maridb开发的一个MySQL数据中间件,配置好MySQL的主从复制架构后,希望实现读写分离,把读操作分散到从服务器中,并且对多个服务器实现负载均衡。

基础组成

MaxScale是插件式结构,允许用户开发适合自己的插件。MaxScale 目前提供的插件功能分为5类。

认证插件

提供了登录认证功能,MaxScale 会读取并缓存数据库中 user 表中的信息,当有连接进来时,先从缓存信息中进行验证,如果没有此用户,会从后端数据库中更新信息,再次进行验证

协议插件

包括客户端连接协议,和连接数据库的协议

路由插件

决定如何把客户端的请求转发给后端数据库服务器,读写分离和负载均衡的功能就是由这个模块实现的

监控插件

对各个数据库服务器进行监控,例如发现某个数据库服务器响应很慢,那么就不向其转发请求了

日志和过滤插件

提供简单的数据库防火墙功能,可以对SQL进行过滤和容错

参考来自:

  1. http://dbaspace.blog.51cto.com/6873717/1871274
  2. https://mariadb.com/blog-tags/maxscale

集群部署

架构逻辑图

MySQL5.7主从复制

主从复制的配置网上教程较多,这里就不作过多描述哈哈。

MHA部署

SSH免密登录

此操作需要在所有部署MHA服务器上配置
1
2
3
4
ssh-keygen -t dsa -P ''
# 生成ssh密钥
ssh-copy-id -i /root/.ssh/id_dsa.pub root@192.168.19.138
# 将ssh公钥传给其他服务器

安装MHA_node

相关软件包下载地址: http://pan.baidu.com/s/1slCxzE9
此操作依然在所有部署MHA服务器上配置,首先需要找到mha4mysql-node-0.57.tar.gz安装包
1
2
3
4
5
yum -y install perl-DBD-MySQL perl-ExtUtils-Embed perl-CPAN
tar -zxf mha4mysql-node-0.57.tar.gz
cd mha4mysql-node-0.57
perl Makefile.PL
make && make install

安装MHA_manager

这次安装的是管理节点,可以在一台上装,当然也可以多台,主要用于监控并切换
需要找到mha4mysql-manager-0.57.tar.gz安装包
1
2
3
4
tar -zxf mha4mysql-manager-0.57.tar.gz
cd mha4mysql-manager-0.57
perl Makefile.PL
make && make install

配置MHA

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
mkdir /etc/masterha
vim /etc/masterha/app1.cnf
[server default]
manager_workdir=/var/log/masterha/app1
manager_log=/var/log/masterha/app1/manager.log
user=manager
password=Manager_1234
ssh_user=root
repl_user=repl
repl_password=Repl_1234
ping_interval=1
[server1]
hostname=192.168.19.138
candidate_master=1
master_binlog_dir=/var/lib/mysql/
[server2]
hostname=192.168.19.139
#candidate_master=1
master_binlog_dir=/var/lib/mysql/
[server3]
hostname=192.168.19.140
#candidate_master=1
master_binlog_dir=/var/lib/mysql/

这里贴一下配置,更多详情参考:
http://www.cnblogs.com/gomysql/p/3675429.html

启动MHA

1
2
3
4
masterha_check_ssh --conf=/etc/masterha/app1.cnf
masterha_check_repl --conf=/etc/masterha/app1.cnf
# 所有检测都OK即可启动MHA了
nohup masterha_manager --conf=/etc/masterha/app1.cnf >> ./app.log &

启动完成后,我们可以把主节点down掉,然后看一下MHA的日志

1
2
3
4
5
6
7
8
9
10
11
12
Fri Aug 11 10:34:30 2017 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Fri Aug 11 10:34:30 2017 - [info] Reading application default configuration from /etc/masterha/app2.cnf..
Fri Aug 11 10:34:30 2017 - [info] Reading server configuration from /etc/masterha/app2.cnf..
Creating /var/tmp if not exists.. ok.
Checking output directory is accessible or not..
ok.
Binlog found at /var/lib/mysql/, up to mysql-bin.000003
Fri Aug 11 10:34:53 2017 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Fri Aug 11 10:34:53 2017 - [info] Reading application default configuration from /etc/masterha/app2.cnf..
Fri Aug 11 10:34:53 2017 - [info] Reading server configuration from /etc/masterha/app2.cnf..

然后再看一下我们其他两台主机的主从状态,会发现主已经转移。
当MHA主切换成功以后,会自动退出进程,此操作还需运维重新恢复数据库,修改配置文件,再启动MHA即可。当然也可以通过自动化的方式来实现。

MaxScale2.0部署

这里直接在官网 https://mariadb.com/products/technology/maxscale 下载最新版RPM包安装即可
或者
1
curl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup | sudo bash

这里仅贴一下我的配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
grep -v '^#' /etc/maxscale.cnf
[maxscale]
threads=1
[server1]
type=server
address=127.0.0.1
port=3306
protocol=MySQLBackend
[MySQL Monitor]
type=monitor
module=mysqlmon
servers=server1
user=myuser
passwd=mypwd
monitor_interval=10000
[Read-Only Service]
type=service
router=readconnroute
servers=server1
user=myuser
passwd=mypwd
router_options=slave
[Read-Write Service]
type=service
router=readwritesplit
servers=server1
user=myuser
passwd=mypwd
max_slave_connections=100%
[MaxAdmin Service]
type=service
router=cli
[Read-Only Listener]
type=listener
service=Read-Only Service
protocol=MySQLClient
port=4008
[Read-Write Listener]
type=listener
service=Read-Write Service
protocol=MySQLClient
port=4006
[MaxAdmin Listener]
type=listener
service=MaxAdmin Service
protocol=maxscaled
socket=default

详情参考:

  1. http://www.cnblogs.com/itfenqing/p/6140029.html
  2. http://blog.csdn.net/wjf870128/article/details/51218697

本文标题:MySQL5.7+MHA+MAXSCAL2.0部署

文章作者:火柴

发布时间:2017年08月10日 - 19:08

最后更新:2017年08月14日 - 15:08

原始链接:http://www.chen-hao.com.cn/posts/62835/

许可协议: 署名-非商业性使用-禁止演绎 4.0 国际 转载请保留原文链接及作者。

火柴 wechat
扫描上方二维码关注我的博客!
0%