Configuring ProxySQL

一、Multi layer configuration system

ProxySQL的配置系统很复杂，但是上手很简单，一般适合有如下需求的服务：

• 可以轻松的动态修改配置（满足那些具有庞大业务基础架构，又严格要求零停服时间的用户），为此，ProxySQL提供了一个兼容MySQL特性的管理接口
• 动态修改配置项，不需要重启ProxySQL服务进程
• 可以轻松回滚掉无效配置

这可以通过一个多层配置系统来做这事，在这样一个配置系统中，我们可以将runtime状态的配置转换到内存中，进而持久化到物理磁盘。

下面就是一个ProxySQL的三层配置结构

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

RUNTIME 表示处理请求的线程用到的内存中的配置

runtime状态的变量包含

• global变量定义的值
• 被分组的后台sever的hostgroups列表；
• 可以连接发哦ProxySQL的MySQL用户列表

注意：runtime状态的配置不能直接修改，只能修改下层（内存或者disk，一般是内存）的配置再加载到runtime

MEMORY（也可以称作main）表示通过MySQL-compatible interface处理的内存中的数据，用户能够通过mysql客户端连接到这个接口来查询ProxySQL的各种表或者数据库配置

通过这个接口我们可以配置这些配置表：

• mysql_servers：ProxySQL连接的数据库server列表
• mysql_users：连接到ProxySQL的用户以及认证列表。记住ProxySQL将会用相同的认证连接后台的mysql server。
• mysql_query_rules：当连接路由到后端服务器时可以执行的查询规则列表，这些规则也能重写查询甚至缓存执行结果。
• global_cariables：配置proxy的全局变量，服务运行是可以做调整以达到临时想要的功能

全局变量配置样例：

mysql> select * from global_variables limit 3;
+----------------------------------+----------------+
| variable_name                    | variable_value |
+----------------------------------+----------------+
| mysql-connect_retries_on_failure | 5              |
| mysql-connect_retries_delay      | 1              |
| mysql-connect_timeout_server_max | 10000          |
+----------------------------------+----------------+

• mysql_collations：proxy字符集检验规则列表，直接来源于mysql client library。
• [仅debug模式]debug_levels：带有debug级别的ProxySQL debug语句列表，这就使得我们能够调试不同的问题然后通过日志输出来定位不同的问题，这中功能只有在debug模式下才有效。

DISK and CONFIG FILE

DISK表示数据是存储在磁盘上的SQLite3数据库，其存储的默认位置为$(DATADIR)/proxysql.db。在重启ProxySQL时，存储在内存中没有被持久化的配置将会丢失，因此将配置持久化到磁盘就显得尤为重要，ProxySQL的CONFIG文件是一个典型的配置文件，我们来看下他与下一部分其他配置层的关系

在下面部分，我们将会提到在ProxySQL后台进程首次启动、启动、重启、关闭等这些基本操作过程中，每一层的生命周期。

Startup

 一般情况下，如果存在配置文件的话，ProxySQL启动时会从配置文件获取数据存储的datadir信息，接下来的要看datadir下有没有数据文件来决定要做什么操作

如果数据库文件存在，ProxySQL会从数据库中获取数据来初始化内存配置，就这样，磁盘数据加载到内存中然后克隆到runtime。如果没找到数据文件，而配置文件是存在的，那么进程会解析这个配置文件，并把配置信息加载到内存，然后持久化到磁盘并加载到runtime。如意重要的一点是：如果进程找到数据库文件，那么他就不再去解析配置文件了。也就是说，proxysql启动的时候，只从磁盘上的数据库文件加载配置到内存中。

记住：ProxySQL 1.4.4引进了两个新的general variables，在服务启动的时候，进程会从配置文件加载这两个变量

Initial startup (or --initial flag)

在初始启动服务的时候，内存以及runtime状态的配置都是从配置文件加载，然后持久化到SQLite数据库，有时候可能会需要强制重新初始化配置，我们在可以运行ProxySQL的时候加上--initial参数来达到目的，这种操作的会将SQLite数据文件恢复到跟配置文件一致的原始状态并重命名SQLite数据库文件，这可能在需要回滚的时候会用到。

Reload startup (or --reload flag)

如果带--reload选项执行proxysql，它会将配置文件的内容和数据库文件内容merge到一块，然后，正常启动进程。

不能保证能够成功merge这两个配置源，如果有冲突的话，那么只能是用户按自己的需求来调整解决

Modifying config at runtime

在进程正常运行时，我们可以通过mysql admin管理接口（默认6032）来修改runtime状态的配置，连接到ProxySQL查看下ProxySQL相关表

mysql> show tables;
+-------------------+
| tables            |
+-------------------+
| mysql_servers     |
| mysql_users       |
| mysql_query_rules |
| global_variables  |
| mysql_collations  |
| debug_levels      |
+-------------------+
6 rows in set (0.01 sec)

在admin管理接口中的每个表的角色

• mysql_servers：ProxySQL连接的后台mysql server列表
• mysql_users：ProxySQL连接后端mysql server服务的用户及认证列表
• mysql_query_rules：包括缓存、路由、以及发送到ProxySQL的sql的重写等规则
• global_variables：进程初始化配置时定义的mysql变量和admin变量
• debug_levels：值适用于debug模式

上面所描述的表都是数据库加载到内存中的表现形式并且通过标准SQL能够进行修改的，下面详细解析一下：

Moving config between layers

In order to persist configuration to disk or load configuration to runtime there is a set of different admin commands available which can be executed via the admin interface. Once you understand how each of the three layers are used, the semantics should be clear. Together with the explanation of each command, there is a numbered option written next to each. The number corresponds to the arrow listed in the diagram above.

             #原版废话粘贴

执行下面的命令来配置MySQL用户，每一行的前后两句效果一样

• [1] LOAD MYSQL USERS FROM MEMORY / LOAD MYSQL USERS TO RUNTIME #从内存加载到runtime
• [2] SAVE MYSQL USERS TO MEMORY / SAVE MYSQL USERS FROM RUNTIME  #从runtime save到内存
• [3] LOAD MYSQL USERS TO MEMORY / LOAD MYSQL USERS FROM DISK         #从磁盘加载到内存
• [4] SAVE MYSQL USERS FROM MEMORY / SAVE MYSQL USERS TO DISK          #从内存save到磁盘
• [5] LOAD MYSQL USERS FROM CONFIG                                                                  #从配置文件加载到内存

配置MySQL servers：

• [1] LOAD MYSQL SERVERS FROM MEMORY / LOAD MYSQL SERVERS TO RUNTIME #操作跟上面配置MySQL users一样，替换一下即可

配置路由规则

• [1] LOAD MYSQL QUERY RULES FROM MEMORY / LOAD MYSQL QUERY RULES TO RUNTIME

配置MySQL variables：

• [1] LOAD MYSQL VARIABLES FROM MEMORY / LOAD MYSQL VARIABLES TO RUNTIME

配置admin variables：

• [1] LOAD ADMIN VARIABLES FROM MEMORY / LOAD ADMIN VARIABLES TO RUNTIME

备注：

##########################################################

上面的命令可以简写成下面的形式

• MEM for MEMORY
• RUN for RUNTIME

比如，下面两天命令意思是一样的

• SAVE ADMIN VARIABLES TO MEMORY
• SAVE ADMIN VARIABLES TO MEM

##########################################################

Summary

对所有对象相关的操作也就是load或者save，我们在对配置做出变更之后，完整的后续操作如下，只有加载到runtime进程才会采用这些配置。

LOAD MYSQL USERS TO RUNTIME;
SAVE MYSQL USERS TO DISK;
LOAD MYSQL SERVERS TO RUNTIME;
SAVE MYSQL SERVERS TO DISK;
LOAD MYSQL QUERY RULES TO RUNTIME;
SAVE MYSQL QUERY RULES TO DISK;
LOAD MYSQL VARIABLES TO RUNTIME;
SAVE MYSQL VARIABLES TO DISK;

LOAD ADMIN VARIABLES TO RUNTIME;
SAVE ADMIN VARIABLES TO DISK;

Troubleshooting

注意只有配置加载到runtime才会生效，

当你把配置save到内存或者磁盘的时候不会产生任何警告或者错误，但是逆向的load到runtime的时候可能会报错或者报警告，如果报错的话，检查一下error log

比如：

[WARNING] Impossible to set variable monitor_read_only_interval with value "0". Resetting to current "1500".

参考文档