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 则能够绘制出一些有关的链接性能或其余的一些图形。
本文分享自微信公众号 - AustinDatabases（AustinDatabases）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。