MySQL-ProxySQL中间件（一）| ProxySQL基本概念

目录

     MySQL-ProxySQL中间件（一）| ProxySQL基本概念：　http://www.javashuo.com/article/p-fnplpdym-k.html

    MySQL-ProxySQL中间件（二）| Admin Schemas介绍：http://www.javashuo.com/article/p-wuxjnuam-e.html

ProxySQL

    ProxySQL做为一款强大的中间件为MySQL的架构提供了有力的支持。

    目前能够很好的支持 Master Slave\ MGR \ PXC等，并提供链接池、读写分离、日志记录等功能，固然还有不少其余实用功能，这里不一一列举了。

    本文都是基础概念，基本出自官方文档，官方已经解释的很是清晰，我就不太多加工，汇总一些实用的分享给你们。

 

安装

    ProxySQL安装很是简单

    

 

链接ProxySQL

    ProxySQL默认管理端口6032，默认须要127.0.0.1来进入，进入方式和链接MySQL方式一致： 

    

ProxySQL 运行机制

RUNTIME

    RUNTIME表示处理请求的线程使用的ProxySQL的内存数据结构。

    runtime variables 包含了：

        1.    Global variables的实际值

        2.    将后端的服务器列表分组到hostgroup中。

        3.    让MySQL 的User们能够链接proxysql

注意：runntime层数据，谁都不能直接修改，必须经过下一层来提交修改。

MEMORY

    MEMORY（有时也称为main）表示经过MySQL兼容接口公开的内存数据库。 用户能够将MySQL客户端链接到此接口，并查询各类ProxySQL配置表/数据库。   

    经过此接口可用的配置表是：

mysql_servers - ProxySQL链接到的后端服务器列表

mysql_users - 链接到ProxySQL的用户及其凭据列表。 请注意，ProxySQL也将使用相同的凭据链接到后端服务器！

mysql_query_rules - 将流量路由到各类后端服务器时评估的查询规则列表。 这些规则还能够重写查询，甚至能够缓存已执行查询的结果。

global_variables - 代理配置使用的全局变量列表，可在运行时调整。

DISK 和 CONFIG FILE

    DISK表示磁盘上的SQLite3数据库，默认位置为$（DATADIR）/proxysql.db。 在从新启动时，未保留的内存中配置将丢失。 所以，将配置保留在DISK中很是重要。   

    

启动过程

    若是找到数据库文件（proxysql.db），ProxySQL将从proxysql.db初始化其内存中配置。 所以，磁盘被加载到MEMORY中，而后加载到RUNTIME中。 

    若是找不到数据库文件（proxysql.db）且存在配置文件（proxysql.cfg），则解析配置文件并将其内容加载到内存数据库中，而后将其保存在proxysql.db中并在加载到RUNTIME。 

    请务必注意，若是找到proxysql.db，则不会解析配置文件。 也就是说，在正常启动期间，ProxySQL仅从持久存储的磁盘数据库初始化其内存配置。

    配置文件有4个变量，即便存在proxysql.db，也始终会从配置文件里去解析：

        1.    datadir：

               定义了ProxySQL datadir的路径，其中存储了数据库文件，日志和其余文件

        2.    restart_on_missing_heartbeats（1.4.4中的新增内容）：

               若是MySQL线程错过了restart_on_missing_heartbeats心跳，则proxysql将引起SIGABRT信号并从新启动。 默认值为10。 

                详情请见：https://github.com/sysown/proxysql/wiki/Watchdog。

        3.    execute_on_exit_failure（1.4.4中的新增内容）：

               若是设置，ProxySQL父进程将在每次ProxySQL崩溃时执行定义的脚本。 建议使用此设置生成警报或记录事件。 

                请注意，在崩溃的状况下，proxysql可以在几毫秒内从新启动，所以其余监视工具可能没法检测到正常故障。

        4.    errorlog（2.0.0中的新增内容）：

               若是设置，ProxySQL将使用定义的文件做为错误日志。 若是未传递此类变量，则errolog将位于datadir / proxysql.log中

   

初始化启动过程（或--initial）

    在初始启动时，将从配置文件中填充内存和运行时配置。 此后，配置将保留在ProxySQL的嵌入式SQLite数据库中。 

    经过使用--initial标志运行proxysql能够强制从新发生初始配置，这会将SQLite数据库文件重置为其原始状态（即配置文件中定义的状态）并重命名现有的SQLite数据库文件 

    若是须要回滚（若是须要，检查已定义的数据目录中的旧文件）。

 

从新加载启动（或--reload）

    若是使用--reload标志执行proxysql，它会尝试将配置文件中的配置与数据库文件的内容合并。 以后，ProxySQL将继续启动程序。

    若是配置文件和数据库文件的参数存在冲突，则没法保证ProxySQL将成功管理合并，用户应始终验证合并结果是否符合预期。

 

核心配置表

    在运行时修改配置是经过ProxySQL的MySQL管理端口（默认为6032）完成的。 

    链接到它后，您将看到一个与MySQL兼容的接口，用于查询各类与ProxySQL相关的表：

mysql> show tables;
+-------------------+
| tables            |
+-------------------+
| mysql_servers     |
| mysql_users       |
| mysql_query_rules |
| global_variables  |
| mysql_collations  |
| debug_levels      |
+-------------------+

 

    每一个这样的表都有明确的定义：

        mysql_servers：        包含要链接的ProxySQL的后端服务器列表

        mysql_users：           包含ProxySQL将用于向后端服务器进行身份验证的用户列表

        mysql_query_rules:    包含用于缓存，路由或重写发送到ProxySQL的SQL查询的规则

        global_variables:        包含在服务器初始配置期间定义的MySQL变量和管理变量

        debug_levels:             仅用于调试ProxySQL的手动构建

 

在不一样层级间移动配置信息

    为了将配置持久化到磁盘或将配置加载到运行时，可使用一组不一样的管理命令，这些命令能够经过管理界面执行。 

    一旦理解了三层中的每一层的使用方式，语义都应该清楚。 

    连同每一个命令的说明，每一个命令旁边都有一个编号选项。 该数字对应于下图中列出的箭头

    

 

    

要从新配置MySQL用户，请执行如下命令之一：

 

[1]    LOAD MYSQL USERS FROM MEMORY / LOAD MYSQL USERS TO RUNTIME

    将MySQL用户从MEMORY加载到RUNTIME数据结构，反之亦然

 

[2]    SAVE MYSQL USERS TO MEMORY / SAVE MYSQL USERS FROM RUNTIME

    将MySQL用户从RUNTIME保存到MEMORY

 

[3]    LOAD MYSQL USERS TO MEMORY / LOAD MYSQL USERS FROM DISK

    将持久化的MySQL用户从磁盘数据库加载到MEMORY

 

[4]    SAVE MYSQL USERS FROM MEMORY / SAVE MYSQL USERS TO DISK

    将MySQL用户从MEMORY中保存到DISK

 

[5]    LOAD MYSQL USERS FROM CONFIG

    从配置文件加载用户到MEMORY

    经常使用的命令参考：

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;

注意：关键字MEMORY/RUNTIME 都支持缩写：
MEM for MEMORY
RUN for RUNTIME

 

故障排除

    请注意，只有在将值加载到运行时才会进行最终验证。 

    能够设置一个值，该值在保存到内存时不会引起任何类型的警告或错误，甚至能够保存到磁盘。

    可是，当执行加载到运行时，会自动将更改恢复为先前已经保存的状态。 

    若是发生这种状况，应该检查定义的错误日志文件：

    例如：

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

    

经常使用的一些命令技巧

1.    限制ProxySQL到后端MySQL的链接数经过权重，来控制ProxySQL到后端MySQL的访问量

    权重只做用在同一个hostgroup中有效

    

 

    

2.    自动回避复制延迟较大的节点

    若是服务器将max_replication_lag设置为非零值，则Monitor模块会按期检查复制延迟    

    下图中，当172.16.0.3的复制延迟超过了30秒会自动回避，设置max_replication_lag = 0，表明不检查复制延迟 。

    

    注意，max_replication_lag主要来源Seconds_Behind_Master，该参数判断延迟准确性不高，顾我的建议为参考功能。

 

3.    Master Slave，将Master做为Slave的备用读节点

   在下面的示例中，若是咱们将HG1配置为提供读请求，则99.95％的请求将发送到172.16.0.2和172.16.0.3，而0.05％的请求将正常发送到172.16.0.1。 

   若是172.16.0.2和172.16.0.3不可用，172.16.0.1将获取全部读取请求。

   注意：max_replication_lag仅适用于从节点。 若是服务器未启用复制，则Monitor不会执行任何操做。

4.    优雅的禁用后端Server

    要正常禁用后端服务器，须要将其状态更改成OFFLINE_SOFT。 

    不会影响当前的活动事务和链接，但不会向该节点发送新流量。

 

5.    当即禁用后端Server

    要当即禁用后端服务器，须要将其状态更改成OFFLINE_HARD。 全部当前请求将当即终止，而且不会发送新请求。

    172.18.0.1 设置了OFFLINE_HARD 会马上中断当前的请求。

    

 

6.    从新启用脱机/禁用后端Server

    要在离线后端从新启用，将其状态更改回ONLINE就能够了

    

 

7.    删除后端Server

 

    注意：

        在内部，删除后端或将其设置为OFFLINE_HARD的方式相同。 

        当执行LOAD MYSQL SERVERS TO RUNTIME时，Hostgroup_Manager将检测到后端服务器已被删除，并在内部将其标记为OFFLINE_HARD。   

 

8.    将明文密码转换成Hash密码，配置到ProxySQL中的mysql_users表 

    mysql_users表，支持明文密码和Hash密码的写入，但生产环境，咱们仍是建议用Hash密码。

    将明文密码转换Hash密码有两种方式：

    1.    经过PASSWORD()

           该函数生成Hash密码，但该函数ProxySQL是不支持的，须要在MySQL数据库里自行生成，再粘贴加密后的密码插入到ProxySQL中。

    2.    经过变量：admin-hash_passwords（推荐）

            此参数默认开启，明文密码存放到MEMORY的mysql_user中，一旦load到RUNTIME会自动HASH加密。

            而后再SAVE回MEMORY/DISK便可完成明文到Hash密码的转换

          

          

9.    限制User和ProxySQL之间的链接数

  

10.    同个事务内的SQL，禁止被路由到不一样节点上

    启动事务后，可能会根据查询规则将某些查询发送到其余主机组。 为了防止这种状况发生，能够开启transaction_persistent

      

还有不少没有总结，一点点来，基础知识梳理完成，会对核心功能再进行测试说明，但愿对须要的同窗有帮助