mysql mha sqlproxy_MYSQL 中间件 为何选择 PROXYSQL VS MHA

MYSQL 的中间件其实也很多，但实际上用的比较广的(非分库分表)的选择点基本上会落到 PROXYSQL 和 MyRouter 两个中间件中，1使用的人数多，2 丰富的文档和至关多的案例mysql

实际上proxysql 能够算是一个支持普遍的中间件，下面是其支持的产品线sql

本着没有使用就没有发言权的原则，如下内容仅仅是针对proxysql 中间件的使用的一些特色和优势来阐述

数据库

从官方网址 https://proxysql.com/  下载最新的 proxysql rpm包后，直接yum -y install 包 安装后。同时也要保证你的proxysql 主机安装了MYSQL的客户端。后端

启动proxysql  service proxysql start    ， 对于proxysql 的配置基本上分为如下几个部分安全

1 MHA 方式服务器

1  登录到PROXYSQL 的管理端 mysql -u admin -padmin -h 127.0.0.1 -P6032 --prompt='Admin> '

微信

2  进入后，实际上看到的databases 和咱们常规理解的是有区别的，PROXYSQL是架设在业界使用最普遍的sqllite 数据库基础上的产品，虽然支持MYSQL的客户端，语法，但实际上后台数据的存储都是基于sqllite数据库的。网络

3  配置简单，针对一个需求简单的MHA，如何再也不使用VIP而是经过PROXYSQL来进行对应用透明的切换。架构

3.1  输入MySQL的主从节点   mysql_servers性能

3.2  配置用户               mysql_users

3.3  配置检测切换方式  mysql_replication_hostgroups

作完这几部，一个基于MHA 最简单的PROXYSQL 方式的集群就完成了。

优势：去掉了VIP 的迁移的脚本，相关的稳定性大幅度提升，总体的架构的复杂性也下降了。

原理：

PROXYSQL 经过判断默认 write组的连通性，咱们能够作一下相关的实验来证明在MHA的状态下

1  到底proxysql 是怎么来判断数据库到底在线仍是不在线

2  到底怎么来判断哪一个是读库，或者当库变为能够写的库时，进行相关的访问

答案就在下图， proxysql  在 1- 2秒会经过查看当前服务器的read_only 来判断当前的服务器是否应该在写的组，而且在1 分钟内会对所在的宿主服务器进行一个链接性的判断。

咱们如下图做为一个例证，目前101的read_only 设置为ON，而102 的 read_only 设置OFF ，也就是目前有两台MYSQL  主 102 从 101

咱们能够将101 的 read_only 设置为OFF 看看会出现什么效果，能够看到写组中的 600组，多了101 这台机器。

若是出现这样的状况就可能会引发数据不一致的状况，因此要保证在同一个时间只能有一个写库，只能有一个机器的 read_only = off 其余的集群的机器的read_only必须是on.

上方是官方文档，描述了

1 connect  链接的后端的成功和失败的，信息将存储在 mysql_server_connect_log 中

select * from mysql_server_connect_log;

2 查看proxysql 与 mysql之间的链接的状况,经过 connect_success_time_us来看当前的网络连通的状况(能够反映一部分)

下面是一些相关的关键的与监控有关的基本参数

1  mysql-monitor_enabled 是否打开监控

2  mysql-monitor_connect_timeout   链接超时的时间 600毫秒

3  mysql-monitor_ping_max_failures   尝试链接失败最大容忍数

4  mysql-monitor_ping_timeout 链接超时时间

判断一个节点是否存活，以上面两个方式来决定，因此若是你的网络延迟，或者某方面不稳定，能够调整某些参数已更适应与当前的设定。

5  mysql-monitor_read_only_max_timeout_count 设定当前read_only最大的超时的次数

6  mysql-monitor_replication_lag_interval 监控主从之间的数据传输差别，若是在设置了读写分离，这会让读写分离中若是主从差别太大的状况下，禁止将查询发送到延时较大的物理库中。

说到这里，必定会有同窗问一个问题，我不怕主机宕机，或者MYSQL服务没法提供服务，我怕的是

1  因为网络缘由，形成主库从库网络没法进行通讯，形成切库，而后网络又恢复了，此时就会出现一个问题，会有两个机器目前存在 read_only = off 的状态。那个人数据是否在继续写入的时候回不安全。

2  因为主库的缘由，OOM 切库，而后主库又起来了，此时也是 read_only = off  > 1

咱们来看一下结果如何。

操做步骤

1  断开primary 的网络  102

2  等待切库

3  切库完毕  主库 101

4  恢复primary 网络  101  102  read_only = off

5  ？？？？？？  写入数据 到底会怎样

图1 的状况是 5  链接到PROXYSQL 而后删除了一个数据库

结果若是是 101 和上图状况一致，则说明proxysql 解决了同时出现两个read_only = off 的状况

出现其余状况，则说明出现问题。

从上图能够看到，结果是正常的也是咱们想要的。

题目中的新想法是来自于proxysql 自己的一些监控和信息，若是将proxysql的一些监控信息利用好，则对于总体监控MHA 集群有部分帮助，若是配合ZABBIX 则能够绘制出一些有关的链接性能或其余的一些图形。