proxysql的配置系统特点
1 允许轻松自动更新配置。为此，有一个MySQL兼容的管理界面2 允许在运行时修改尽可能多的配置项，而无需重新启动守护程序
3 允许轻松回滚错误的配置
这是使用多层配置系统实现的，允许设置从一层移动到另一层。配置系统的3层如下图所示：
+-------------------------+
| RUNTIME |
+-------------------------+
/|\ |
| |
[1] | [2] |
| \|/
+-------------------------+
| MEMORY |
+-------------------------+ _
/|\ | |\
| | \
[3] | [4] | \ [5]
| \|/ \
+-------------------------+ +-------------------------+
| DISK | | CONFIG FILE |
+-------------------------+ +-------------------------+
RUNTIME
表示正在处理请求的线程使用的ProxySQL的内存中数据结构。这些包含使用的全局变量的值，分组到主机组的后端服务器列表或可连接到代理的MySQL用户列表。请注意，操作者永远不能直接修改RUNTIME配置部分的内容，总是需要通过底层来修改。
MEMORY（有时也称为main）
表示内存中的SQLite3数据库，它通过MySQL兼容界面暴露给外部。用户可以将MySQL客户端连接到此接口，并查询不同的表和数据库。通过此界面可用的配置表如下：
mysql_servers - 后端服务器列表mysql_users - 可以连接到ProxySQL的用户列表和凭据。请注意，ProxySQL也将使用这些凭据连接到后端服务器
mysql_query_rules - 用于将流量路由到不同的后端服务器的规则列表。这些规则也可能导致重写查询或缓存结果
global_variables - 可以在运行时调整的整个代理中使用的全局变量列表。全局变量示例：
proxysql>select * from global_variables limit 3;
+--------------------------------+----------------+
| variable_name | variable_value |
+--------------------------------+----------------+
| mysql-shun_on_failures | 5 |
| mysql-shun_recovery_time_sec | 10 |
| mysql-query_retries_on_failure | 1 |
+--------------------------------+----------------+
3 rows in set (0.00 sec)
mysql_collations - 可用于代理使用的MySQL排序规则列表。 这些是直接从客户端库提取的。
[仅在调试版本中可用] debug_levels - ProxySQL与其详细级别一起发送的调试语句的类型列表。 这允许我们在运行时轻松配置在日志中有什么样的语句来调试不同的问题。 这仅在调试版本中可用，因为它可能会影响性能
DISK和CONFIG FILE
DISK表示磁盘上的SQLite3数据库，默认位置为$（DATADIR）/proxysql.db。 在重新启动过程中，内存中未被保留的配置将丢失，因此将配置保留在DISK中是非常重要的。 CONFIG文件是经典的配置文件，我们将在下一节中看到它与其他配置层之间的关系。配置系统的加载方式
启动过程
在正常启动时，ProxySQL读取其配置文件（如果存在），以确定其datadir。 接下来发生的事情取决于它的数据库文件（磁盘）是否存在于其datadir中。如果找到数据库文件，ProxySQL将从持久的磁盘数据库初始化其内存中的配置。 因此，磁盘被加载到内存中，然后传播到运行时配置。 如果找不到数据库文件，并且存在配置文件，则会将配置文件解析并将其内容加载到内存数据库中，然后将其保存在磁盘数据库中，并在运行时加载。 如果重要的是要注意，如果找到数据库文件，则不会解析配置文件。 也就是说，在正常启动期间，ProxySQL仅从持久存储的磁盘数据库中初始化其内存中的配置。
初始启动（或 - 初始标志）
在初始启动时，内存和运行时配置从配置文件而不是数据库文件中填充。 有可能强制初始启动运行proxysql的--initial标志，它通过重命名旧数据库来重置数据库。完成后，配置也会持续到磁盘数据库，这将用于下一次重新启动。
重新加载启动（或--reload标志）
如果proxysql使用--reload标志执行，则会尝试将配置文件中的配置与数据库文件的内容合并。 之后，它执行定期启动。 不能保证ProxySQL会成功管理这两个配置源的冲突，并且用户应该验证合并是否符合预期。在运行时修改配置
在运行时修改配置是通过ProxyServer的MySQL管理端口完成的。 连接到它之后，我们会看到一个MySQL兼容的界面来查询几个与ProxySQL相关的表：
proxysql>show tables;
+--------------------------------------+
| tables |
+--------------------------------------+
| global_variables |
| mysql_collations |
| mysql_query_rules |
| mysql_replication_hostgroups |
| mysql_servers |
| mysql_users |
| runtime_global_variables |
| runtime_mysql_query_rules |
| runtime_mysql_replication_hostgroups |
| runtime_mysql_servers |
| runtime_mysql_users |
| runtime_scheduler |
| scheduler |
+--------------------------------------+
13 rows in set (0.00 sec)
每个这样的表在管理界面中具有明确定义的角色：
mysql_servers包含用于连接到ProxySQL的后端服务器列表
mysql_users包含用于向ProxySQL和后端服务器进行身份验证的用户列表
mysql_query_rules包含缓存，路由或重写通过代理的SQL查询的规则
global_variables包含单个表中的MySQL变量和管理变量
debug_levels仅用于ProxySQL的调试版本
这些表表示从上图的中间层（内存数据库），可以使用标准SQL查询进行操作。 为了从该层向上或向下移动配置，请参阅下一节。
Moving config between layers（在层之间移动配置）
为了在三层之间移动配置，通过管理界面有一组不同的管理命令。 一旦了解了三层中的每一层意味着什么，语义应该是相当明显的。 连同每个命令的说明，旁边写有一个数字。 数字对应于上图中的箭头。For handling MySQL users:
[1] LOAD MYSQL USERS FROM MEMORY / LOAD MYSQL USERS TO RUNTIME
loads MySQL users from the in-memory database to the runtime data structures
[2] SAVE MYSQL USERS TO MEMORY / SAVE MYSQL USERS FROM RUNTIME
persists the MySQL users from the runtime data structures to the in-memory database
[3] LOAD MYSQL USERS TO MEMORY / LOAD MYSQL USERS FROM DISK
loads MySQL users from the on-disk database to the in-memory database
[4] SAVE MYSQL USERS FROM MEMORY / SAVE MYSQL USERS TO DISK
persists the MySQL users from the in-memory database to the on-disk database
[5] LOAD MYSQL USERS FROM CONFIG
loads from the configuration file the users into the in-memory database
For handling MySQL servers:
[1] LOAD MYSQL SERVERS FROM MEMORY / LOAD MYSQL SERVERS TO RUNTIME
loads MySQL servers from the in-memory database to the runtime data structures
[2] SAVE MYSQL SERVERS TO MEMORY / SAVE MYSQL SERVERS FROM RUNTIME
persists the MySQL servers from the runtime data structures to the in-memory database
[3] LOAD MYSQL SERVERS TO MEMORY / LOAD MYSQL SERVERS FROM DISK
loads MySQL servers from the on-disk database to the in-memory database
[4] SAVE MYSQL SERVERS FROM MEMORY / SAVE MYSQL SERVERS TO DISK
persists the MySQL servers from the in-memory database to the on-disk database
[5] LOAD MYSQL SERVERS FROM CONFIG
loads from the configuration file the servers into the in-memory database
For handling MySQL query rules:
[1] LOAD MYSQL QUERY RULES FROM MEMORY / LOAD MYSQL QUERY RULES TO RUNTIME
loads MySQL query rules from the in-memory database to the runtime data structures
[2] SAVE MYSQL QUERY RULES TO MEMORY / SAVE MYSQL QUERY RULES FROM RUNTIME
persists the MySQL query rules from the runtime data structures to the in-memory database
[3] LOAD MYSQL QUERY RULES TO MEMORY / LOAD MYSQL QUERY RULES FROM DISK
loads MySQL query rules from the on-disk database to the in-memory database
[4] SAVE MYSQL QUERY RULES FROM MEMORY / SAVE MYSQL QUERY RULES TO DISK
persists the MySQL query rules from the in-memory database to the on-disk database
[5] LOAD MYSQL QUERY RULES FROM CONFIG
loads from the configuration file the query rules into the in-memory database
For handling MySQL variables:
[1] LOAD MYSQL VARIABLES FROM MEMORY / LOAD MYSQL VARIABLES TO RUNTIME
loads MySQL variables from the in-memory database to the runtime data structures
[2] SAVE MYSQL VARIABLES FROM MEMORY / SAVE MYSQL VARIABLES TO DISK
persists the MySQL variables from the in-memory database to the on-disk database
[3] LOAD MYSQL VARIABLES TO MEMORY / LOAD MYSQL VARIABLES FROM DISK
loads MySQL variables from the on-disk database to the in-memory database
[4] SAVE MYSQL VARIABLES TO MEMORY / SAVE MYSQL VARIABLES FROM RUNTIME
persists the MySQL variables from the runtime data structures to the in-memory database
[5] LOAD MYSQL VARIABLES FROM CONFIG
loads from the configuration file the variables into the in-memory database
For handling admin variables:
[1] LOAD ADMIN VARIABLES FROM MEMORY / LOAD ADMIN VARIABLES TO RUNTIME
loads admin variables from the in-memory database to the runtime data structures
[2] SAVE ADMIN VARIABLES TO MEMORY / SAVE ADMIN VARIABLES FROM RUNTIME
persists the admin variables from the runtime data structures to the in-memory database
[3] LOAD ADMIN VARIABLES TO MEMORY / LOAD ADMIN VARIABLES FROM DISK
loads admin variables from the on-disk database to the in-memory database
[4] SAVE ADMIN VARIABLES FROM MEMORY / SAVE ADMIN VARIABLES TO DISK
persists the admin variables from the in-memory database to the on-disk database