一 常用命令
//实时加载
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本身处理所带来的损耗