MySQL5.7MHA+MaxScale2.0构建高可用环境

环境介绍

Part1:写在最前

看了某大牛的文章，讲述了一下MaxScale比LVS的好处多多，那您倒是放出来配置文件啊~~大牛说：

需要的单独找我吧，太长了配置文件……

看到这我心中久久不能平静啊。。。联系不上您呐 = =，于是各种资料各种找啊~各种坑各种血崩啊！~~~

由于不知道大牛的配置文件是什么样子，本文仅以随笔的形式，记录下实施过程。也欢迎您和我探讨您在实施MaxScale时遇到的各种问题和心得体会。

Part2:环境

MySQL5.7 MHA + MaxScale2.0

192.168.1.248 HE1 slave1

192.168.1.249 HE2 slave2

192.168.1.250 HE3 master

192.168.1.251 HE4 MHA-manager

192.168.1.100 MHA-vip

Part3:MHA

MHA的优点不作赘述，看下原理图吧

从宕机崩溃的Master保存二进制日志事件(binlogevent)

识别含有最新更新的Slave

应用差异的中继日志(relaylog)到其他Slave

应用从Master保存的二进制日志事件

提升一个Slave为新的Master

使其他的Slave连接新的Master进行复制

构建MySQL5.7MHA

Part1:写在最前

MHA的部署不是本文的叙述重点，网上比比皆是。这里只记录下MySQL5.7的MHA搭建时的一些坑

Part2:坑

①mha4mysql-manager-0.57.tar.gz

②mha4mysql-node-0.57.tar.gz

Warning:警告这两个包首先你要搞到，虽然说0.56什么的不代表支持的mysql版本，但经过测试，想要在MySQL5.7上部署MHA，少走坑，请用0.57的。

Part3:安装包的位置

请在所有的节点包括Manager节点安装好你的mha4mysql-node-0.57.tar.gz，以保证后期在管理节点执行perl Makefile.PL的时候，你能如愿以偿的看到如下信息

Part4:一些常见错误记录

如果遇到

①这样

解决方案

用的不是默认端口3306，请修改你的配置文件

②这样

解决方案

[root@HE1 MHA]# ln -s /usr/local/mysql/bin/mysqlbinlog /usr/bin/mysqlbinlog

③或者这样

解决方案

注释掉my.cnf中的

[client]

#default-character-set=utf8

遇到上述错误别慌张，看日志，根据报错来排查问题。

折腾半天，就为了这个OK

[root@HE4 mha4mysql-manager-0.57]# masterha_check_status --conf=/etc/mha/mha.conf

mha (pid:32726) is running(0:PING_OK), master:192.168.1.250

MaxScale2.0

Part1:写在最前

maxscale是mariadb公司开发的一套数据库中间件，可以很方便的实现读写分离方案；并且提供了读写分离的负载均衡和高可用性保障。另外maxscale对于前端应用而言是透明的，我们可以很方便的将应用迁移到maxscale中实现读写分离方案，来分担主库的压力。maxscale也提供了sql语句的解析过滤功能。这里我们主要讲解maxscale的安装、配置以及注意事项。

Part2:整体架构

Part3:安装

Maxscale配置很简单

[root@HE3 MHA]# yum -y install maxscale-2.0.1-2.centos.6.x86_64.rpm (只在Maxscale上执行)

[root@HE3 ~]# /etc/init.d/maxscale start

Starting MaxScale: maxscale (pid 28851) is running...      [  OK  ]

[root@HE3 ~]#  netstat -lntp |grep maxscale

tcp        0      0 0.0.0.0:6603                0.0.0.0:*                   LISTEN      29878/maxscale     

tcp        0      0 0.0.0.0:4006                0.0.0.0:*                   LISTEN      29878/maxscale     

[root@HE3 ~]# maxadmin -pmariadb list services

Services.

--------------------------+----------------------+--------+---------------

Service Name              | Router Module        | #Users | Total Sessions

--------------------------+----------------------+--------+---------------

Read-Only Service         | readconnroute        |      1 |     5

Read-Write Service        | readwritesplit       |      1 |    11

MaxAdmin Service          | cli                  |      2 |     3

--------------------------+----------------------+--------+---------------

[root@HE3 ~]# maxadmin -pmariadb list servers

Servers.

-------------------+-----------------+-------+-------------+--------------------

Server             | Address         | Port  | Connections | Status             

-------------------+-----------------+-------+-------------+--------------------

server1            | 192.168.1.248   |  3306 |           0 | Slave, Running

server2            | 192.168.1.249   |  3306 |           0 | Slave, Running

server3            | 192.168.1.250   |  3306 |           0 | Master, Running

-------------------+-----------------+-------+-------------+--------------------

至此，MHA+Maxscale的环境就完成了。

读写分离与负载均衡校验

Part1:读写分离

在Master构建相应的测试表

在slave1插入数据HE1

在slave2插入数据HE2

现在链接4006读写分离端口，进行数据写入

可以看到主库插入完毕后从库已经同步完成，这条查询完成在了HE1（slave1）上

Part2:负载均衡

我们配置的read比例为1:1

OK!That's how it works!~

故障测试

Part1:stop slave故障

停止HE1的复制

可以看出，在slave1故障后，所有的读操作都进入了HE2(slave2)；

恢复HE1

在HE1（slave1）恢复完成后，重新有了负载均衡。

Part2:mysql down故障

Warning:警告这里我并没有在

[MySQL Monitor]中配置detect_stale_master=true

可以看出，在maxscale2.0中，已经默认从库都停掉，也不影响

Part3:master故障

可以看出，kill master的mysql进程后，MHA将slave1拉成新的master,Maxsale也识别了这一状态。

Java Druid注意事项

------------以下文章取材于贺春旸技术博客-------------------

http://hcymysql.blog.51cto.com/5223301/1869414

现象：

程序会不定时的出现连接错误，问题bug的异常信息如下：

The last packet successfully received from the server was 116 milliseconds ago.  The last packet sent successfully to the server was 115 milliseconds ago.

java.sql.SQLException: No database selected

但通过客户端sqlyog/navicat连接均为正常。

----------------------------------------------------------------------

另：maxscale1.4.3有时还会出现挂起现象，4006端口直接关闭。后我们用了watch命令后台跑监控。

watch -d /bin/bash /root/sh/restart_maxsacle.sh

解决：5.6以下可以直接在url上配置：autoReconnect=true

对于5.6以上的只能在jdbc的链接池里设置：

第一个设置成ture,超时自动链接，对于mysql要把第二个设置成false，不启用缓存。

以上是开发需要注意的都是一些基本的配置。

其目的为：每次归还连接时执行select 'x'检测连接是否有效。 

——总结——

maxscale的核心就在于内个配置文件，根据不同的业务和架构，做好相应的配置，本文意在抛砖引玉，如果您有更全的配置文件，欢迎您分享给笔者。由于笔者的水平有限，编写时间也很仓促，文中难免会出现一些错误或者不准确的地方，不妥之处恳请读者批评指正。