Proxysql读写分离配置

GitHub地址:https://github.com/sysown/proxysql

官网地址:https://www.proxysql.com/

Percona主推的读写分离中间件,下载地址:

https://www.percona.com/downloads/proxysql/

一、安装

1:下载
wget https://www.percona.com/downloads/proxysql/proxysql-1.4.5/binary/redhat/6/x86_64/proxysql-1.4.5-1.1.el6.x86_64.rpm
2:安装
rpm -ivh proxysql-1.4.5-1.1.el6.x86_64.rpm
3:启动
service proxysql start/stop/status

二、配置

登录Proxysql管理和监控界面(也是使用Mysql协议,端口是6032,不加-h在某些环境下会自动使用本地sock连到3306的mysql端口,所以建议要加上-h参数)

mysql -uadmin -padmin -P6032 -h127.0.0.1

6032为管理和监控端口,6033为对外提供数据库服务的端口,admin/amin为默认的管理监控的账号密码(只能本地登录),可以在proxysql.conf文件的admin_variables找到。

main
    是默认的数据库名,表里存放backend的mysql server、mysql user、路由规则等信息。表名以runtime_开头的表示proxysql当前运行的配置内容,是不能通过dml语句修改的,可以通过修改对应的不以runtime_ 开头的里的表(in-memory表),然后load xxx to runtime使其生效,记得最后使用save相关的命令将其存入disk库。
    需要注意的是main库中的表全是内存表,你可以通过修改那些不以runtime_ 开头的里的表来进行配置的热更新,但是需要load to runtime才能生效,通过runtime_表查看生效后的值,此外如果这些更新未被save到disk库,那么proxysql重启后这些更新会全部丢失。
disk
    是持久化到硬盘的配置,sqlite数据文件。你可以看到这里的表名和main库中的不以runtime_ 开头的里的表名一样,是的,这些就是main库里那些内存表的持久化映射表,proxysql启动时是从这里读取配置的。
stats
    proxysql运行抓取的统计信息,包括到后端各命令的执行次数、流量、processlist、查询种类汇总/执行时间,等等。
monitor 
    存储 monitor 模块收集的信息,主要记录针对后端db的connect log,ping和slave delay
main库中的表信息:

可以通过查看global_variables表来获取proxysql的各种参数,在其中你可以找到其默认自带的2个管理用户admin、stats,其默认db schema分别为main、stats,这两个用户一个可以用于进行proxysql一个可以用于观察stats,这俩账户唯一的区别就是admin权限大,stats权限小点,两者都只能本地登录。

此外还需要再定义一个监控账号,因为默认的admin和stats管理账号都是属于proxysql的不能用于后端mysql连接,我们需要一个账号用于ping后端的mysql以及检测mysql主从延迟。

这个监控账号虽然是在后端数据库真实存在的(既可以通过6033端口连接),但其实他是个管理账号,所以他很特殊,因为它既可以通过6032端口连到proxysql的管理界面,也可以通过6033端口连到后端的mysql业务库。平时我们既不会用他连6032(因为有stats管理账户)也不会用他连mysql业务库(权限受限)。但是如果你不想从本地登录还想查看proxysql的统计信息,那么可以使用此账户远程连接到6032的管理端口,此账户的管理权限等同于stats账户。

# 首先后端mysql主库添加账户:
mysql> GRANT SUPER,REPLICATION CLIENT ON *.* TO 'proxysql' IDENTIFIED BY 'proxysql';
# 然后设置proxysql对应的管理账户:
mysql -uadmin -padmin -h127.0.0.1 -P6032
set mysql-monitor_username='proxysql';
set mysql-monitor_password='proxysql';

关于proxysql配置,最重要的是mysql_servers,mysql_users,mysql_query_rules,其他表很少修改:

这3个最重要的表的内容也可以在/etc/proxysql.conf中修改,但只是第一次初始化时使用,以后的修改和初始化信息都是通过disk库实现的(存储在sqllite库中),目前建议不要对/etc/proxysql.conf和proxysql-admin.conf做任何修改。

  • mysql_servers:
定义所有可用的mysql server,hostgroup_id可以自定义数字,只需将读和写的组设为不一样的hostgroup_id即可。
本例中是在MHA环境下配置的,59、60、61为MHA的3个节点,其中59目前为master,200为MHA的VIP(公共IP)。
在配置完mysql_users后,ProxySQL为每个mysql_servers表中定义的hostname创建一个默认的连接放入连接池中,可以通过查看stats_mysql_connection_pool表获知。
insert into mysql_servers(hostgroup_id,hostname,port,weight,max_connections,max_replication_lag,comment) 
values(100,'10.0.1.59',3306,1,1000,10,'test my proxysql');
insert into mysql_servers(hostgroup_id,hostname,port,weight,max_connections,max_replication_lag,comment) 
values(100,'10.0.1.60',3306,1,1000,10,'test my proxysql');
insert into mysql_servers(hostgroup_id,hostname,port,weight,max_connections,max_replication_lag,comment) 
values(100,'10.0.1.61',3306,1,1000,10,'test my proxysql');
insert into mysql_servers(hostgroup_id,hostname,port,weight,max_connections,max_replication_lag,comment) 
values(1000,'10.0.1.200',3306,1,1000,10,'test my proxysql');
 这里把MHA的3个节点的IP--59,60,61的hostgroup_id设为100,将MHA的VIP--200的hostgroup_id设置为1000,实现读写分离和读的负载均衡。
  • mysql_users:
定义连接proxysql的数据库账户和密码。这里的账户是不同于你在global_variables看到的admin和stats账户的,那是属于连接6032的管理账户。而这里是用于连接6033端口的应用账户。
这些user的frontend和backend字段默认都为1,标识了账户既是属于proxysql server的账户,也是可以用于连接后端mysql server的账户。虽然proxysql文档说未来版本会把前端账户和后端账户分隔以便后端账户可以完全对proxysql的client们隔离,但目前前后端账户还是重合的。
思考一个问题:为何proxysql需要frotend和backend账户?
解释可以再上述链接看到,proxysql server其实只是一个转发mysql请求的代理,如果proxysql直接将请求转发到后端mysql进行身份验证,那么当后端mysql节点失败或者负载过高时连接就可能失败,而一般读节点可以有多个,一个拒绝了可以继续到另一个节点试试啊,所以为了实现简单的故障转移和负载均衡,proxysql选择自己也建立一套身份认证体系,这样客户端可以无阻塞的直接与proxysql创建连接,之后proxysql可以在后端节点之间进行负载均衡。
proxysql 6033端口使用与后端mysql相同的认证体系,在mysql_users中新增的账户需要在后端mysql中也存在,且密码要一致。
mysql_users里的账户与后端mysql账户的区别在于不需要指定权限,只要账密与后端mysql一样即可。
insert into mysql_users(username,password,active,default_hostgroup,transaction_persistent)
values('leo','leo',1,1000,1);
# 需要注意的是插入时设置的password是明文密码,可以使用如下方式加密一下:
LOAD MYSQL USERS TO RUNTIME;
SAVE MYSQL USERS FROM RUNTIME;
SAVE MYSQL USERS TO DISK;
# 其原理如下:
	参数admin-hash_passwords为true时,密码在load入runtime时会被自动hash,所以load mysql users to runtime可以实现密码hash
    save mysql users from runtime等价于save mysql users to mem,意思是main库的mysql_users表里记载的密码也更新下
    最后save mysql users to disk是将hash密码写入硬盘
default_hostgroup可以设为上边定义的1000,这样所有连接到MHA所在服务器的6033端口的客户端会话都会默认转发到hostgroup 1000上,但是如果设置了任何mysql_query_rules,那么只要有select操作就会按mysql_query_rules的规则转发,所以如果你设置了mysql_query_rules,那么select @@hostname;查到的可能不会是hostgroup为1000的节点,因为这也属于select语句。
本例中hostgroup为1000的是MHA的VIP,proxysql自动连接到MHA的VIP上,即始终默认连接到master库,执行任何语句都会根据mysql_query_rules的规则转发。
最后load加载并在sqlite中保存上述各种修改:
load mysql servers to runtime;
load mysql users to runtime;
load mysql variables to runtime;
save mysql servers to disk;
save mysql users to disk;
save mysql variables to disk;
  • mysql_query_rules:
定义读写分离规则,可以看到是通过正则实现的,下列定义表示除了select for update,其他的select一律转发到hostgroup_id为100的虚拟节点上,也就说读操作负载均衡的分配到59、60、61三个库上。其他操作使用默认的hostgroup_id为1000的库,也就是MHA的master库。
使用proxysql时我们可以先不设置query rules,这样客户端依然是对主库的单点读写,之后我们可以慢慢为一些慢查询设置正则规则导向读库们。
关于mysql_query_rules各个字段的解释参考:https://github.com/sysown/proxysql/wiki/Main-(runtime)#mysql_query_rules
INSERT INTO mysql_query_rules(active,match_pattern,destination_hostgroup,apply) 
VALUES(1,'^SELECT.*FOR UPDATE$',1000,1);
INSERT INTO mysql_query_rules(active,match_pattern,destination_hostgroup,apply) 
VALUES(1,'^SELECT',100,1);
# mysql_query_rules表的主键是自增的rule_id,匹配规则的应用顺序是按rule_id升序来的,所以可以把精细的匹配规则前置,模糊的匹配规则后置。
# load to runtime生效并在sqlite中保存上述修改。
load mysql query rules to runtime;
save mysql query rules to disk;
 
关于正则匹配规则:
proxysql支持两种正则匹配规则,由参数mysql-query_processor_regex控制,1.4.0版本之前只有RE2可用(即C++正则匹配规则)。
当前默认的匹配规则为PCRE即perl compatible Regular Expressions.
因此设计正则匹配规则是使用正常的正则表达式即可。
至于匹配规则的一些限制,如大小写敏感,匹配模式是全局替换还是只替换等首个匹配等等,可以通过mysql_query_rules.re_modifiers字段进行设置,默认的匹配规则是大小写不敏感的。
如何查看proxysql的统计信息?
在进行一系列增删改查后,可以通过如下视图查看统计信息,需要使用监控账号连接proxysql的6032端口.
本例中连接方式为mysql -ustats -pstats -P6032 -h127.0.0.1 (127.0.0.1为proxsql所在服务器,我这里直接在本地查的)
select * from stats_mysql_query_digest_reset;
# 以上视图与stats_mysql_query_digest的结构与内容一样,区别在于查询以上视图后统计信息会被清空。
本文使用的proxysql 1.4.5遇到一个BUG,stats.stats_mysql_query_digest无法记录query信息,相关的参数配置已查证无误,暂未找到其他原因,建议之后使用更新的版本。
Ps:后经过验证发现,在proxysql server上通过本地mysql命令行执行的SQL不会记录入stats_mysql_query_digest表。
最后,Proxysql日志的默认位置为/var/lib/proxysql/proxysql.log.
三、总结
本例使用Proxysql实现了MHA的读写分离,把VIP设置为了可读写的hostgroup,真实的3台MHA服务器IP设置为了可读的hostgroup,但是在MHA同步延迟较大时可能出现读取不到最新数据的情况,需要注意,可以通过设置mysql_servers的max_replication_lag来尽可能避免单个节点的slave delay。
一个需要注意的点:
    很不建议配置mysql_replication_hostgroups表,因为配置此表之后,proxysql会自动检测mysql_servers里mysql节点的read_only的值,只要read_only=0,此节点就会被加入writer_hostgroup中,否则加入reader_hostgroup,造成的结果就是假如集群重启之后read_only统一为0,那么这些节点就会全部加入读组中(mysql_servers里会出现处于不同组但是属性完全一样的记录),造成写入混乱,除非你能在任意时刻保证read_only参数的正确性
原文地址:https://www.cnblogs.com/leohahah/p/8529583.html