proxySQL

多层配置系统结构

+-------------------------+|         RUNTIME         |+-------------------------+/|\          ||           |[1] |       [2] ||          \|/+-------------------------+|         MEMORY          |+-------------------------+ _/|\          |      |\|           |        \[3] |       [4] |         \ [5]|          \|/         \+-------------------------+  +---------------+|          DISK           |  |  CONFIG FILE  |+-------------------------+  +---------------+

解释下这个3层的配置系统。

最底层的是disk库和config file。这里需要注意，这里的config file就是传统的配置文件，默认为/etc/proxysql.cnf，ProxySQL启动时，主要是从disk库中读取配置加载到内存并最终加载到runtime生效，只有极少的几个特定配置内容是从config file中加载的，除非是第一次初始化ProxySQL运行环境(或者disk库为空)。

中间层的是memory，表示的是内存数据库，其实就是main库。通过管理接口修改的所有配置，都保存在内存数据库(main)中。当ProxySQL重启或者崩溃时，这个内存数据库中的数据会丢失，所以需要save到disk库中。

最上层的是runtime，它是ProxySQL有关线程运行时读取的数据结构。换句话说，该数据结构中的配置都是已生效的配置。所以，修改了main库中的配置后，必须load到runtime数据结构中才能使其生效。

常用管理命令

登录

mysql -uadmin -p -h127.0.0.1 -P6032

6032为管理端口

查看挂接的mysql

select * from mysql_servers;

结果形如：

±-------------±--------------±-----±----------±-------±-------±------------±----------------±--------------------±--------±---------------±--------+
| hostgroup_id | hostname | port | gtid_port | status | weight | compression | max_connections | max_replication_lag | use_ssl | max_latency_ms | comment |
±-------------±--------------±-----±----------±-------±-------±------------±----------------±--------------------±--------±---------------±--------+
| 10 | xx.xx.xx.67 | 3306 | 0 | ONLINE | 2 | 0 | 1000 | 0 | 0 | 0 | |
| 20 | xx.xx.xx.67 | 3306 | 0 | ONLINE | 2 | 0 | 1000 | 0 | 0 | 0 | |
| 10 | xx.xx.xx.69 | 3306 | 0 | ONLINE | 1 | 0 | 1000 | 0 | 0 | 0 | |
| 20 | xx.xx.xx.69 | 3306 | 0 | ONLINE | 1 | 0 | 1000 | 0 | 0 | 0 | |
±-------------±--------------±-----±----------±-------±-------±------------±----------------±--------------------±--------±---------------±--------+

各字段含义如下：

hostgroup_id：该后端MySQL实例所在的主机组。注意，同一MySQL节点可属于多个主机组。
hostname,port：后端MySQL监听的地址和端口。就是默认3306端口的意义
status：
ONLINE：该后端MySQL节点完全正常。
SHUNNED：该后端MySQL节点将暂时被ProxySQL自动避开(忽略)，原因可能是一个较短时间内发生了大量连接错误，也可能是该slave与master的数据延迟太大(replication lag)。
OFFLINE_SOFT：当某后端MySQL被设置为 OFFLINE_SOFT 时，ProxySQL将不会向它发送新的请求，但该节点正在执行的事务会继续执行，直到所有事务执行完毕后会进入非激活状态。也就是说，和该后端的连接会保持到事务执行完毕。这可以实现后端节点的graceful停止、重启。
OFFLINE_HARD：当某后端MySQL被设置为 OFFLINE_HARD 时，ProxySQL将不会向它发送新的请求，该节点正在执行的事务也会立即中断。也就是直接将该后端杀掉。等价于删除该节点，或临时将其移除出组(例如出于维护的目的)。

weight：节点在组中的权重值越高，ProxySQL会发送越多请求给它们。

compression：如果该字段的值设置为大于0，ProxySQL和该后端新建的连接中，ProxySQL将会先压缩数据再传输。

max_connections：和mysql后端允许建立的最大连接数。当达到最大数量时，即使该后端的权重很大，也不会和它新建连接。默认值为1000，表示每个后端最多能同时接受1000个连接。请确保该后端的max_connections值是合理的，以避免MySQL超负荷时ProxySQL继续向其发送请求。

max_replication_lag：如果值大于0，ProxySQL的Monitor模块将会定期检查该slave的复制是否延后于master，如果延迟的值大于该字段的值，ProxySQL将会暂时避开该节点，直到该slave赶上master。

use_ssl：如果设置为1，则和该后端MySQL建立SSL连接。

max_latency_ms：Monitory模块定期向该后端发起ping检查，如果该节点的ping时间大于该字段的值，则将其排除在连接池之外(尽管该节点仍处于ONLINE状态)。

comment：该表的说明信息，可随便定义。

查看读写组

select * from mysql_replication_hostgroups;

查看用户

select * from mysql_users;

ProxySQL有多种粒度的路由规则，每个用户都有默认的路由目标组，当使用该用户发送的SQL语句没有能够匹配的语句级路由规则，则会将该SQL语句路由给该用户默认的路由目标组。

查看路由规则

select * from runtime_mysql_query_rules;

参考

https://www.cnblogs.com/f-ck-need-u/p/9281199.html