ProxySQL亮点、安装、配置及测试等解析

下文内容主要给大家带来ProxySQL亮点、安装、配置及测试等解析，这里所讲到的知识，与书籍略有不同，都是开发云专业技术人员在与用户接触过程中，总结出来的，具有一定的经验分享价值，希望给广大读者带来帮助。rpm包下载地址https://github.com/sysown/proxysql/releases 推荐rpm形式安装Installing from sourceMake sure you have installed the equivalent for each of these packages for your operating system:git clone https://github.com/sysown/proxysql.gitGo to the directory where you cloned the repo (or unpacked the tarball) and run:Compilation time should be around a couple of minutes for the first time around. The configuration file will be found at /etc/proxysql.cnf afterwards.在make这一步遇到了错误：网查是由于gcc版本低导致，centos 6的yum源（以及epel源）都只能获取到4.4.7版本换到centos7上，将上述软件安装/更新之后，make步骤完成，但是make install步骤又出了问题：update-rc.d是ubuntu的开发云主机域名自启动脚本管理软件,未成功安装不影响使用。安装完成后，自动在/etc/init.d/proxysql增加服务管理脚本（需要把/usr/local/bin/加入$PATH或者软链至 $PATH目录下，脚本中直接用到proxysql命令）配置文件/etc/proxysql.cnf和配置数据库文件/var/lib/proxysql/proxysql.db，如果存在 “proxysql.db”文件，则启动过程不解析proxysql.cnf文件；配置文件只在第一次启动的时候读取官方推荐用admin interface方式登陆admin interface：注意：admin interface对配置的存储是基于SQLite的，SQLite支持标准的SQL语法，与mysql也基本兼容。但是无法用use语句切换数据库，作者对use语句做了兼容（不报错），但是却没有实际效果。配置好一主(db1，hostgroup0)两从(db2和db3，hostgroup1) ，并且在’mysql_query_rules’表中增加一条路由规则意为所有以select开头的语句路由到hostgroup1，其余语句路由到hostgroup0在两台server的mysql-client分别连接至proxysql的6033端口，执行’select @@hostname’观察其分配到的后端server以mysql -e的形式执行该命令则能够看到请求在两台读server之间变换由以上结果可能会猜想并可印证：在一个client的一个链接周期内，所有query路由到同一台后端。
但是：这只是个假象(是因为正好用到了select @ 语句。按作者所说： sends a query that implicitly disables multiplexing. For example, if you run “SELECT @a” , ProxySQL will disable multiplexing for that client and will always use the same backend connection.)，proxysql的负载方式目前仅为加权轮询一种（经过作者确认的），并无其他机制。对上述架构用sysbench做只读测试，过程中关闭(service mysqld stop)某一台server (测试均在mysql-monitor_enabled=false的前提下)测试命令结果如下不是说好的自动重连/重执行吗？为毛报错了呢（atlas有同样问题）测试方法错了：其实关闭后端mysql服务来测试“reconnect”特性应该说从本质上就是不对的，mysql正常关闭会kill掉其上的所有processlist，我们可以用mysql-client来做一些验证可以看到mysql-client是具有重连(reconnect)功能的，然后我们来做一个kill掉mysql-client线程（也就是mysql在关闭时会kill掉所有线程）的操作我们看到了之前sysbenche测试过程中关闭一台从库时的报错。也就是说这个场景下这个报错不是proxysql的‘reconnect’机制的问题，倒更像是‘re-execute’机制的问题。而kill操作应该理解为是mysql“主动”的动作，而非“异常”，所以这就不符合proxysql 的”re-execute”特性了，故而会报错。应该换一种方式来进行这个测试：模拟网络层无法通信的异常我们在两台slave上通过iptables阻断peoxysql到本机的3306端口来模拟无法链接和链接中断异常在sysbench开始之后再重启iptables已经建立的链接会被保留，所以新规则要放到第一条的位置
-A INPUT -s 192.168.1.34 -p tcp -m tcp –dport 3306 -j DROP首先 ：启动sysbench只读测试
然后 ：在测试结束前，修改db1的iptables，禁止来自proxysql的请求进入
然后 ：观察sysbench的输出和proxysql.log的输出
结果 ：sysbench等待很长时间，依然无法完成，同时，proxysql也不会把db1标记为SHUNNED
proxysql.log输出：然后，直接对后端node（db1）进行同样的测试，发现结果是一样的，sysbench等待很长时间依然无法完成也无报错。
从这一点似乎可以判定在这个测试方法下，未达到预期结果的原因可能不在proxysql，而在sysbench本身。通过对重启iptables之后的通信进行抓包（分别对针对proxysql和mysql在这个测试场景下进行抓包）,命令如下：
~]# date; service iptables restart; tcpdump -i em2 host 192.168.1.35 and port 3306 and host not 192.168.1.10 -w /tmp/sysbench-proxysql-network-issue.pacp
~]# date; service iptables restart; tcpdump -i em2 host 192.168.1.34 and port 3306 and host not 192.168.1.10 -w /tmp/sysbench-proxysql-network-issue.pacp发现，sysbench“一直”在重传由于iptables新规则而无法返回的几个请求，所以就成了“无穷尽等待的样子” (atlas 在这个场景下有同样问题)照理说，proxysql kill掉了一些查询，会返回给sysbench错误，但为什么sysbench并未将错误展示出来呢(可能是因为re-execute机制)最后，通过跟作者沟通，发现是由于没开启monitor模块，导致proxysql无法检测到后端出了什么类型的错误，也就无法执行对应各种后端错误的一些操作（之前我是特意关掉了monitor模块）好多框架用prepare语句来避免SQL注入等安全问题，同时能在MySQL解析查询方面降低一些开销，所以对于prepare语句支持与否也很重要首先要从MySQL协议层面了解prepare语句，分为两种(参考)抓包分析一次prepare,set,execute过程，可以观察到，客户端发送的是COM_STMT_PREPARE
抓包分析一次prepare,set,execute过程，可观察到客户端发送的是COM_QUERY

关于prepare语句，作者给出的回复和计划如下：
这是我在实验1.2.1版本时跟作者的沟通。现在已经发布1.3.5了，从1.3版本开始,两种协议都支持了。但是在设置字符集方面，对于binary protocol 的prepare set names xxx和普通query(set names ‘utf8’ collate ‘utf8_general_ci’)(注意加了校对规则，不加校对规则可以)语句还无法正确处理（例如，php的laravel框架默认就是以第一种形式设置字符集）。
修正：经测试1.3.7版本，以上两prepare语句的小bug都已解决MySQL supports two type of prepared statements:
using API
using SQL Further details here
SQL support currently not supported either, because PREPARE doesn’t disable multiplexing, so it is possible that ProxySQL sends PREPARE in a connection, and EXECUTE into another.SQL support will be fixed in v1.2.3 , see #684 .
API support is planned in ProxySQL 1.3 .首先来精确理解一下这两个词，依作者回复They are very related to each other
Connection pool is a cache of connections that can be reused.
Multiplexing is a technique to reuse these connections.后期逐渐了解到了proxysql的multiplexing。连接池是一个共享的池子里面有跟后端创建好的一些连接，一个服务端脚本的执行过程中可能有多次sql请求：很显然，对于连接池的使用效率上来说，理论上多数情况下proxysql的方式会更加高效并且与DB间维护的链接数量会更少测试场景：分两次测试，第一次测试脚本如下（每条命令一次连接）第二次测脚本如下（一次连接，执行所有命令）对ProxySQL进行测试分析
通过tcpdump抓包wireshark分析，通过ProxySQL对20条查询的路由情况及其和后端MySQL之间的建立连接情况（通过ProxySQL上的原端口号）来分析连接池和禁用multiplexing的情况。结果汇总如下第一次测试（每条命令一次连接）第二次测试（一次连接，执行所有命令）对比来看Atlas的分时分析
第一次测试（每条命令一次连接）第二次测脚本如下（一次连接，执行所有命令）由上面测试分析结果可以明显的看到可以主动这两种检测的区别，据作者回复和抓包分析，总结如下：Ping is done using mysql_ping()
    通过抓包分析，是通过现有的链接（连接池中）发送一个Request Ping语句
Connect is done using mysql_real_connect()
    这是一个客户端到云服务器建立链接，登录，退出登录，关闭链接的完整过程这两个函数的返回值不同，可以帮助proxysql理解与后端链接除了哪些问题。模拟场景，验证以上各设置并加深理解其故障检测机制：
两个前提修改web1 MySQL配置文件中max_connections = 3；重启web1 MySQL，在其他tty打开几个MySQL链接以确保proxysql无法链接该MySQL。同时在proxysql server上打开抓包功能tcpdump -i em2 host 192.168.1.4 and port 3306 -w /tmp/web_shun.pcap，然后通过wireshark对比上面各值进行分析。
附件：数据包文件通过分析可验以以下设置的有效性可以被动被动就是将全局变量‘mysql-monitor_enabled’置为false，这种情况下，后端server故障后，proxysql不会主动探知，而是在有请求被“正常”路由到该server之后才会在runtime层更改该server状态为‘SHUNNED’ 或者重新变为‘ONLINE’。这个过程，应用无感知（表现为mysql-client命令和sysbench均无报错）
相关变量为###七、关于proxysql和mysql中的最大连接数
首先明确下MySQL中的最大连接数由max_connections变量控制，proxysql中的最大连接数有两个方面的设置mysql_users.max_connections和mysql_servers.max_connections下面就直接说下我的结论 摘自我github上的issue###八、据我所知的bug和不足
bug：###总结
稳定性方面：目前我们已经部分业务切换到了ProxySQL上，运行一直稳定，未遇到cpu负载高或者占用内存多等情况。运维/DBA友好：借助于ProxySQL的错误日志，我们发现了之前没注意到的一些SQL问题（如主键重复类的问题等）。还通过stats库里的相关表定位了一些问题。性能方面：也强于atlas（参见文章）个人觉得，解决掉上述几点bug和不足的话（且不说可能会出现的其他feature），ProxySQL就会更加强大和完美。对于以上关于ProxySQL亮点、安装、配置及测试等解析，如果大家还有更多需要了解的可以持续关注我们开发云的行业推新，如需获取专业解答，可在官网联系售前售后的，希望该文章可给大家带来一定的知识更新。

相关推荐: mysql的性能优化工具（源自韩锋大师，针对5.7修改）

点击(此处)折叠开发云主机域名或打开相关推荐: PHP Mysql support: 是mysql 还是mysqlnd?您正在使用其中一个备用存储库安装现代版本的php，突然间您遇到了一个令人困惑的选择。你想在php程序中支持mysql（mysqli或PDO-…