一 常用命令
//实时加载
load mysql servers to runtime; mysql_server
load mysql users to runtime; mysql_users
load mysql variables to runtime; variables
load mysql query rules to runtime; query_rule
//刷新到磁盘
save mysql servers to disk;
save mysql users to disk;
save mysql variables to disk;
save mysql query rules to disk;
二 监控
stats 是proxysql运行抓取的统计信息，包括到后端各命令的执行次数、流量、processlist、查询种类汇总/执行时间，等等。
相关表
1 stats_mysql_connection_pool连接相关
2 stats_mysql_processlist 运行相关
3 stats_mysql_query_digest sql请求比例相关
4 系统监控
5 默认级别内存监控是被禁用的,这里要注意
三 数据备份与恢复
常见于节点的扩容和恢复
sqlite3 sqa.db ".dump [mytabl%]" > sqa.sql
sqlite3 sqb.db < sqa.sql
具体请参考sqlite3的备份恢复
四 相关问题
1 大量查询虽然导向从库,但是返回的数据量太大导致阻塞proxysql代理,导致性能问题甚至导致阻塞.可能场景常见于
1 大数据查询 2 特殊需求需要大批量获取数据等
2 数据库延迟问题导致所有从库打向主库,增大压力
1 DDL大表操作导致延迟
2 大事物导致延迟
解决方法1: DDL操作尽量采用pt-osc操作,然后控制从库延迟参数 2 加大proxysql本身延迟容忍参数(请以实际业务为准) 3 对大事物进行拆分 4 优化慢sql 减少从库IO压力
3 业务进行改造
业务针对主库进行的查询需要添加注释改造业务,后续要养成习惯
4 版本本身BUG导致
比如内存泄漏 无端cacsh等,建议时长对github留言区进行跟踪,最好上线采用全新版本,定期对版本进行升级等
5 是否真的该用proxysql用来代理
这取决于两个原因
1 你的业务是读的比例远远大于写的比例,并且写的压力对于主库已经很大
2 通过测试能保证proxysql读写分离后效率远远高于由于proxysql本身处理所带来的损耗
五 原理相关
1 后端从库延迟检测
通过show slave status 获取 Seconds_Behind_Master,以下情况会发生移除节点
1 和后端的连接断开。
2 slave落后于master过多。
3 和后端建立连接时，错误次数过多。
4 second_behind_master=null时，即slave的SQL线程未运行，或者slave未连接到master。(不过这种自动避开的情况是可控的，见全局变量mysql-monitor_slave_lag_when_null,这个变量值是置换值,设置最好大于能容忍的阈值)
2 连接池复用技术
情况:一个后端DB的连接，可以“同时”被多个客户端使用
改进对比
传统的连接池，会在客户端断开连接（会话）后，把连接放回到池里。
在ProxySQL中，由于连接复用，连接会在 sql语句 执行结束后，便将连接放回到池里（客户端会话可能并没有断开），这样便可大大提高后端连接的使用效率，而避免前段请求过大导致后端连接数疯长。
六 相关架构
1 proxysql本身有性能损耗,可以靠增加多台proxysql进行流量均衡,弥补带来的性能损耗,但是需要维护配置文件的统一
2 proxysql后端监控read_only,配合MHA切换后端mysql,实现高可用.由于proxysql的出现,MHA不必再使用VIP,有效的避免了脑裂的风险
七 参数优化
mysql-monitor_slave_lag_when_null 设置延时参数
mysql-max_allowed_packet 设置数据包大小
mysql-free_connections_pct 保持连接池连接数百分比 X最大连接数/100为保持连接数的连接值
max_connections 最大连接数,不要大于后端数据库的相对应值
表级别
mysql.server-> transaction_persisnt(1) 保证事务内查询路由到主库