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

原创
2020/08/20 06:00
阅读数 3.5K

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 则可以绘制出一些有关的连接性能或其他的一些图形。



本文分享自微信公众号 - AustinDatabases(AustinDatabases)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

展开阅读全文
打赏
0
2 收藏
分享
加载中
更多评论
打赏
0 评论
2 收藏
0
分享
返回顶部
顶部