MYSQL 中间件 为什么选择 PROXYSQL VS MHA

MYSQL 的中间件其实也不少，但实际上用的比较广的（非分库分表）的选择点基本上会落到 PROXYSQL 和 MyRouter 两个中间件中，1使用的人数多，2 丰富的文档和相当多的案例

实际上proxysql 可以算是一个支持广泛的中间件，下面是其支持的产品线

本着没有使用就没有发言权的原则，以下内容仅仅是针对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 则可以绘制出一些有关的连接性能或其他的一些图形。