MySQL-ProxySQL中间件(一)| ProxySQL基本概念

目录

    MySQL-ProxySQL中间件(一)| ProxySQL基本概念: https://www.cnblogs.com/SQLServer2012/p/10972593.html
    MySQL-ProxySQL中间件(二)| Admin Schemas介绍:https://www.cnblogs.com/SQLServer2012/p/10972761.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
     
还有很多没有总结,一点点来,基础知识梳理完成,会对核心功能再进行测试说明,希望对需要的同学有帮助
posted @ 2019-06-04 11:35  Paddy_张  阅读(6093)  评论(2编辑  收藏  举报