美文网首页MySql
ProxySQL管理专题

ProxySQL管理专题

作者: 这货不是王马勺 | 来源:发表于2021-10-07 19:33 被阅读0次

    管理参考:
    https://www.cnblogs.com/kevingrace/p/10329714.html
    https://www.dazhuanlan.com/singlezeus/topics/959248
    https://www.cnblogs.com/f-ck-need-u/p/9300829.html

    一.ProxySQL多层管理

    1.ProxySQL多层管理配置

    (有三层配置)

    • runtime:运行中使用的配置文件
    • memory:提供用户动态修改配置文件
    • disk:将修改的配置保存到磁盘SQLit表中(即:proxysql.db)
    • config:一般不使用它(即:proxysql.cnf)

    2.ProxySQL配置系统分为三层的目的

    1. 自动更新;
    2. 尽可能的不重启proxysql就可以修改配置;
    3. 方便回滚错误配置;
      简单说就是配置proxysql分为三个级别,RUNTIME是即时生效的,MEMORY是保存在内存中但并不立即生效的,DISK|CONFIG FILE是持久化或写在配置文件中的。
      这三个级别的配置文件互不干扰,在某个层级修改了配置文件,想要加载或保存到另一个层级,需要额外的LOAD或SAVE操作:"LOAD xx_config FROM xx_level | LOAD xx_config TO xx_level | SAVE xx_config TO xx_level | SAVE xx_config FROM xx_level",达到加载配置或者持久化配置的目的。

    3.每层的功能与含义

    • RUNTIME层
      代表的是ProxySQL当前生效的配置,包括 global_variables, mysql_servers, mysql_users, mysql_query_rules。无法直接修改这里的配置,必须要从下一层load进来。该层级的配置时在proxysql管理库(sqlite)的main库中以runtime_开头的表,这些表的数据库无法直接修改,只能从其他层级加载;该层代表的是ProxySQL当前生效的正在使用的配置,包括global_variables, mysql_servers, mysql_users, mysql_query_rules表。无法直接修改这里的配置,必须要从下一层load进来。也就是说RUNTIME这个顶级层,是proxysql运行过程中实际使用的那一份配置,这一份配置会直接影响到生产环境的,所以要将配置加载进RUNTIME层时需要三思而行。

    • MEMORY层
      是平时在mysql命令行修改的 main 里头配置,可以认为是SQLite数据库在内存的镜像。该层级的配置在main库中以mysql_开头的表以及global_variables表,这些表的数据可以直接修改;用户可以通过MySQL客户端连接到此接口(admin接口),然后可以在mysql命令行查询不同的表和数据库,并修改各种配置,可以认为是SQLite数据库在内存的镜像。也就是说MEMORY这个中间层,上面接着生产环境层RUNTIME,下面接着持久化层DISK和CONFIG FILE。MEMORY层是我们修改proxysql的唯一正常入口。一般来说在修改一个配置时,首先修改Memory层,确认无误后再接入RUNTIME层,最后持久化到DISK和CONFIG FILE层。也就是说memeory层里面的配置随便改,不影响生产,也不影响磁盘中保存的数据。通过admin接口可以修改mysql_servers、mysql_users、mysql_query_rules、global_variables等表的数据。

    • DISK|CONFIG FILE层
      持久存储的那份配置,一般在(DATADIR)/proxysql.db,在重启的时候会从硬盘里加载。 /etc/proxysql.cnf文件只在第一次初始化的时候用到,完了后,如果要修改监听端口,还是需要在管理命令行里修改,再 save 到硬盘。该层级的配置在磁盘上的sqlite库或配置文件里。DISK/CONFIG FILE层表示持久存储的那份配置,持久层对应的磁盘文件是$(DATADIR)/proxysql.db,在重启ProxySQL的时候,会从proxysql.db文件中加载信息。而 /etc/proxysql.cnf文件只在第一次初始化的时候使用,之后如果要修改配置,就需要在管理端口的SQL命令行里进行修改,然后再save到硬盘。 也就是说DISK和CONFIG FILE这一层是持久化层,我们做的任何配置更改,如果不持久化下来,重启后,配置都将丢失。

    4.总结

    1. ProxySQL每一个配置项在三层中都存在,但是这三层是互相独立的,也就是说proxysql可以同时拥有三份配置,每层都是独立的,可能三份配置都不一样,也可能三份都一样。
    2. RUNTIME层代表 ProxySQL 当前生效的正在使用的配置,无法直接修改这里的配置,必须要从下一层 "load" 进来。
    3. MEMORY这一层上面连接 RUNTIME 层,下面连接持久化层。在这层可以正常操作 ProxySQL 配置,随便修改,不会影响生产环境。修改一个配置一般都是先在 MEMORY 层完成,然后确认正常之后再加载到 RUNTIME 和持久化到磁盘上。
    4. DISK 和 CONFIG FILE层持久化配置信息,重启后内存中的配置信息会丢失,所以需要将配置信息保留在磁盘中。重启时,可以从磁盘快速加载回来。

    ProxySQL配置文件的修改流程一般是:

    • 启动时:先修改必要的CONFIG FILE配置,比如管理端口,然后启动;
    • 其他配置:修改MEMORY中的表,然后加载到RUNTIME并持久化。


      以MYSQL USERS为例

    二.ProxySQL的库说明

    1.ProxySQL库概述

    ProxySQL提供了几个库,每个库都有各自的意义;

    • main 内存配置数据库,表里存放后端db实例、用户验证、路由规则等信息。表名以 runtime_开头的表示proxysql当前运行的配置内容,
      不能通过dml语句修改,只能修改对应的不以 runtime_ 开头的(在内存)里的表,然后 LOAD 使其生效, SAVE 使其存到硬盘以供下次重启加载。
    • disk 是持久化到硬盘的配置,sqlite数据文件。
    • stats 是proxysql运行抓取的统计信息,包括到后端各命令的执行次数、流量、processlist、查询种类汇总/执行时间等等。
    • monitor 库存储 monitor 模块收集的信息,主要是对后端db的健康/延迟检查。

    2.main库和disk库常用表

    (disk库的表字段和main一样,只是对应了不同层级)

    • global_variables
      设置变量,包括监听的端口、管理账号等。
    • mysql_collations
      相关字符集和校验规则。
    • mysql_query_rules
      定义查询路由规则。
    • mysql_replication_hostgroups
      监视指定主机组中所有服务器的read_only值,并且根据read_only的值将服务器分配给写入器或读取器主机组。ProxySQL monitor模块会监控hostgroups
      后端所有servers 的read_only 变量,如果发现从库的read_only变为0、主库变为1,则认为角色互换了,自动改写mysql_servers表里面 hostgroup关系,
      达到自动 Failover 效果。
    • mysql_servers
      设置后端MySQL的表
    • mysql_users
      配置后端数据库的程序账号和监控账号。
    • scheduler
      调度器是一个类似于cron的实现,集成在ProxySQL中,具有毫秒的粒度。通过脚本检测来设置ProxySQL。

    3.stats库常用表

    • stats_mysql_commands_counters
      统计各种SQL类型的执行次数和时间,通过参数mysql-commands_stats控制开关,默认是ture。
    • stats_mysql_connection_pool
      连接后端MySQL的连接信息。
    • stats_mysql_processlist
      类似MySQL的show processlist的命令,查看各线程的状态。
    • stats_mysql_query_digest
      表示SQL的执行次数、时间消耗等。通过变量mysql-query_digests控制开关,默认是开。
    • stats_mysql_query_rules
      路由命中次数统计。

    4.monitor库常用表

    • mysql_server_connect_log
      连接到所有MySQL服务器以检查它们是否可用,该表用来存放检测连接的日志。
    • mysql_server_ping_log
      使用mysql_ping API ping后端MySQL服务器,检查它们是否可用,该表用来存放ping的日志。
    • mysql_server_replication_lag_log
      后端MySQL服务主从延迟的检测。
      注:
      runtime_开头的是运行时的配置,这些是不能修改的。要修改ProxySQL的配置,需要修改了非runtime_表,
      修改后必须执行"LOAD ... TO RUNTIME"才能加载到RUNTIME生效,执行save ... to disk才能将配置持久化保存到磁盘。

    三.常用表说明

    1.mysql_servers

    • hostgroup_id: ProxySQL通过 hostgroup (下称HG) 的形式组织后端db实例。一个 HG 代表同属于一个角色
    • 该表的主键是 (hostgroup_id, hostname, port),可以看到一个 hostname:port 可以在多个hostgroup里面,如上面的 10.0.100.100:3307,这样可以避免 HG 1000 的从库全都不可用时,依然可以把读请求发到主库上。
    • 一个 HG 可以有多个实例,即多个从库,可以通过 weight 分配权重
    • hostgroup_id 0 是一个特殊的HG,路由查询的时候,没有匹配到规则则默认选择 HG 0
    • status:
    • ONLINE: 当前后端实例状态正常
      • SHUNNED: 临时被剔除,可能因为后端 too many connections error,或者超过了可容忍延迟阀值 max_replication_lag
      • OFFLINE_SOFT: “软离线”状态,不再接受新的连接,但已建立的连接会等待活跃事务完成。
      • OFFLINE_HARD: “硬离线”状态,不再接受新的连接,已建立的连接或被强制中断。当后端实例宕机或网络不可达,会出现。
    • max_connections: 允许连接到该后端mysql实例的最大连接数。不要大于MySQL设置的 max_connections,如果后端实例 hostname:port 在多个 hostgroup 里,以较大者为准,而不是各自独立允许的最大连接数。
    • max_replication_lag: 允许的最大延迟,主库不受这个影响,默认0。如果 > 0, monitor 模块监控主从延迟大于阀值时,会临时把它变为 SHUNNED 。
    • max_latency_ms: mysql_ping 响应时间,大于这个阀值会把它从连接池剔除(即使是ONLINE)
    • comment: 备注,不建议留空。可以通过它的内容如json格式的数据,配合自己写的check脚本,完成一些自动化的工作。

    2.mysql_users

    • username, password: 连接后端db的用户密码。
      这个密码你可以插入明文,也可以插入hash加密后的密文,proxysql会检查你插入的时候密码是否以 * 开头来判断,而且密文要在其它地方使用 PASSWORD()生成。但到 runtime_mysql_users 里,都统一变成了密文,所以可以明文插入,再 SAVE MYSQL USERS TO MEM,此时看到的也是HASH密文。
    • active: 是否生效该用户。
    • default_hostgroup: 这个用户的请求没有匹配到规则时,默认发到这个 hostgroup,默认0
    • default_schema: 这个用户连接时没有指定 database name 时,默认使用的schema
      注意表面上看默认为NULL,但实际上受到变量 mysql-default_schema 的影响,默认为 information_schema。关于这个参考我所提的 issue #988
    • transaction_persistent: 如果设置为1,连接上ProxySQL的会话后,如果在一个hostgroup上开启了事务,那么后续的sql都继续维持在这个hostgroup上,不伦是否会匹配上其它路由规则,直到事务结束。
      虽然默认是0,但我建议还是设成1,虽然一般来说由于前段应用的空值,为0出问题的情况几乎很小。作者也在考虑默认设成 1,refer this issue #793
    • frontend, backend: 目前版本这两个都需要使用默认的1,将来有可能会把 Client -> ProxySQL (frontend) 与 ProxySQL -> BackendDB (backend)的认证分开。从 runtime_mysql_users 表内容看到,记录数比 mysql_users 多了一倍,就是把前端认证与后端认证独立出来的结果。
    • fast_forward: 忽略查询重写/缓存层,直接把这个用户的请求透传到后端DB。相当于只用它的连接池功能,一般不用,路由规则 .* 就行了。

    3.mysql_replication_hostgroups

    定义 hostgroup 的主从关系。ProxySQL monitor 模块会监控 HG 后端所有servers 的 read_only 变量,如果发现从库的 read_only 变为0、主库变为1,则认为角色互换了,自动改写 mysql_servers 表里面 hostgroup 关系,达到自动 Failover 效果。
    注:ProxySQL配置后端DB server两种方式

    1. 一种是在往mysql_servers表中添加server时就为其划分好hostgroup_id(例如0表示写组,1表示读组)
    2. 另一种往mysql_servers表中添加server时不区分hostgroup_id(例如全部设为0),然后通过mysql_replication_hostgroups表中的值,
      根据proxysql检测到的各server的read_only变量值来自动为后端server设置hostgroup_id
      这里推荐用第一种方式,因为第一种是完全由我们控制的;而第二种假如我们误将读server的read_only属性设置为0,则proxysql会将其重新分配到写组,这绝对是不期望的。

    4.mysql_query_rules

    mysql_query_rules 是ProxySQL非常核心一个表,定义查询路由规则

    • rule_id: 表主键,自增。规则处理是以 rule_id 的顺序进行。
    • active: 只有active=1的规则才会参与匹配。
    • username: 如果非 NULL,只有连接用户是username的值才会匹配。
    • schemaname: 如果非 NULL,只有查询连接使用的db是 schemaname 的值才会匹配。注意如果是 NULL,不代表连接没有使用schema,而是不伦任何schema都进一步匹配。
    • flagIN, flagOUT, apply: 用来定义路由链 chains of rules。
      • 首先会检查 flagIN=0 的规则,以rule_id的顺序;如果都没匹配上,则走这个用户的 default_hostgroup。
      • 当匹配一条规则后,会检查 flagOUT。
        • 如果不为NULL,并且 flagIN != flagOUT ,则进入以flagIN为上一个flagOUT值的新规则链。
        • 如果不为NULL,并且 flagIN = flagOUT,则应用这条规则。
        • 如果为NULL,或者 apply=1,则结束,应用这条规则。
        • 如果最终没有匹配到,则找到这个用户的 default_hostgroup。
    • client_addr: 匹配客户端来源IP
    • proxy_addr, proxy_port: 匹配本地proxysql的IP、端口。我目前没有想到它的应用场景,可能是把proxysql监听在多个接口上,分发到不同的业务?
    • digest: 精确的匹配一类查询。
    • match_digest: 正则匹配一类查询。query digest 是指对查询去掉具体值后进行“模糊化”后的查询,类似 pt-fingerprint / pt-query-digest 的效果。
    • match_pattern: 正则匹配查询。
      以上都是匹配查询的规则,1.3.5版本使用的正则引擎只有 RE2 ,1.4版本可以通过变量 mysql-query_processor_regex 设置 RE2 或者 PCRE,且1.4开始默认是PCRE。
      推荐用 match_digest 。关于每条查询都会计算digest对性能的影响,计算query digest确实会有性能损失,但是这却是proxysql里面非常重要的特性,主要是两点:
      • proxysql无法知道连接复用(multipexing)是否必须被自动禁用,比如连接里面有variables/tmp tables/lock table等特殊命令,是不能复用的。
      • 完整的查询去匹配正则的效率,一般没有参数化后的查询匹配效率高,因为有很长的字符串内容需要处理。再者,SELECT * FROM randomtable WHERE comment LIKE ‘%INTO sbtest1 % FROM sbtest2 %’字符串里有类似这样的语句,很难排除误匹配。
    • negate_match_pattern: 反向匹配,相当于对 match_digest/match_pattern 的匹配取反。
    • re_modifiers: 修改正则匹配的参数,比如默认的:忽略大小写CASELESS、禁用GLOBAL.
      上面都是匹配规则,下面是匹配后的行为
    • replace_pattern: 查询重写,默认为空,不rewrite。
    • rewrite规则要遵守 RE2::Replace 。
      destination_hostgroup: 路由查询到这个 hostgroup。当然如果用户显式 start transaction 且 transaction_persistent=1,那么即使匹配到了,也依然按照事务里第一条sql的路由规则去走。
    • cache_ttl: 查询结果缓存的毫秒数。
      proxysql这个 Query Cache 与 MySQL 自带的query cache不是同一个。proxysql query cache也不会关心后端数据是否被修改,它所做的就是针对某些特定种类的查询结果进行缓存,比如一些历史数据的count结果。一般不设。
    • timeout: 这一类查询执行的最大时间(毫秒),超时则自动kill。
      这是对后端DB的保护机制,相当于阿里云RDS loose_max_statement_time 变量的功能,但是注意不同的是,阿里云这个变量的时间时不包括DML操作出现InnoDB行锁等待的时间,而ProxySQL的这个 timeout 是计算从发送sql到等待响应的时间。默认mysql-default_query_timeout给的是 10h.
    • retries: 语句在执行时失败时,重试次数。默认由 mysql-query_retries_on_failure变量指定,为1。
      个人建议把它设成0,即不重试。因为执行失败,对select而言很少见,主要是dml,但自己重试对数据不放心。
    • delay: 查询延迟执行,这是ProxySQL提供的限流机制,会让其它的查询优先执行。
      默认值 mysql-default_query_delay,为0。我们一般不用,其实还是要配合应用端使用,比如这边延迟执行,但上层等待你返回,那前端不就堵住了,没准出现雪崩效应。
    • mirror_flagOUT,mirror_hostgroup
      这两个高级了,目前这部分文档不全,功能是SQL镜像。顾名思义,就是把匹配到的SQL除了发送到 destination_hostgroup,同时镜像一份到这里的hostgroup,比如我们的测试库。比如这种场景,数据库要从5.6升级到5.7,要验证现有查询语句对5.7的适用情况,就可以把生产流量镜像到5.7新库上验证。
    • error_msg: 默认为NULL,如果指定了则这个查询直接被 block 掉,马上返回这个错误信息。
      这个功能也很实用,比如线上突然冒出一个 “坏查询”,应用端不方便马上发版解决,我们就可以在这配置一个规则,把查询屏蔽掉,想正常的mysql报错那样抛异常。下一篇文章有演示。
    • multiplex: 连接是否复用。
    • log: 是否记录查询日志。可以看到log是否记录的对象是根据规则。
      要开启日志记录,需要设置变量 mysql-eventslog_filename 来指定文件名,然后这个 log 标记为1。但是目前proxysql记录的日志是二进制格式,需要特定的工具才能读取: eventslog_reader_sample 。这个工具在源码目录 tools下面。

    问题汇总

    【问题1】

    spring用jdbc实现事务时会set autocommit = 0; 加入一个session中开头是select关键字,则整个session的内容都会被路由到只读组,导致session中的其他增删改的DML回滚。
    之前在github上看到过一个问题:https://github.com/sysown/proxysql/issues/1256
    和我遇到的问题极其相似,SQL如下:

    set autocommit = 0;
    select version from t where version = xx;
    delete from t where version = xx;
    commit;
    

    另外mysql-forward_autocommit 已经设置为 1,
    (变量释义参考官网:https://proxysql.com/documentation/global-variables/mysql-variables/
    在 mysql_users 表中该用户transaction_persistent值为 1 ( transaction_persistent: 如果设置为1,连接上ProxySQL的会话后,如果在一个hostgroup上开启了事务,那么后续的sql都继续维持在这个hostgroup上,无论是否会匹配上其它路由规则,直到事务结束。)

    下面回复表示:
    “autocommit=0不会启动事务,因此proxysql“不将autocommit=0视为事务”在技术上是正确的,因为还没有事务。”
    新版本中添加了新变量mysql-autocommit_false_is_transaction,如果设置成true(默认为false),则autocommit=0的连接将被视为事务。如果forward_autocommit=true(默认为false),则同样的行为也适用。

    但是在我的测试中,mysql-autocommit_false_is_transaction和forward_autocommit均设置为true,且load mysql variables to runtime时,对jdbc的set autocommit = 0仍然不起效果,仍然被路由到只读组。

    到官网查看了相关变量的具体释义(图省事机翻):
    【mysql-autocommit_false_is_transaction】
    如果mysql-autocommit_false_is_transaction=true(默认为false),则autocommit=0的连接将被视为事务,并且不会返回到连接池。也就是说,autocommit=0将禁用多路复用。
    请注意,autocommit=0不足以启动事务:在数据库级别,当对事务表执行查询时,事务将启动。
    建议不要更改此变量。
    【mysql-forward_autocommit】
    当mysql-forward_autocommit=false(默认值)时,ProxySQL将跟踪(并记住)客户端需要的autocommit值,并根据需要更改后端连接上的autocommit。例如,如果客户机发送set autocommit=0,ProxySQL将只回复OK。当客户端发送DDL时,ProxySQL将获得到目标主机组的连接,并在运行DDL之前更改自动提交。
    如果mysql-forward_autocommit=true,则将SET autocommit=0转发到后端。SET autocommit=0不会启动任何事务,连接是在连接池中设置的,查询可能会在不同的连接上执行。如果设置mysql-forward_autocommit=true,那么还应该设置mysql-autocommit_false_not_reusible=true,以防止连接返回到连接池。换句话说,设置mysql-forward_autocommit=false将防止这种行为,因为自动提交状态是跟踪的。
    【mysql-autocommit_false_not_reusible】
    当设置为true时,autocommit=0的连接不会被重新使用,并且在连接返回到连接池时会被销毁。
    建议不要更改此变量。

    下一步准备测试mysql_user表中transaction_persistent置为0,mysql-forward_autocommit=true,mysql-autocommit_false_not_reusable=true,且可以尝试mysql_query_rules中按flagin和flagout设置规则链,看看这种情况下是否可以达到目的。
    2021-10-09更新:目前按此设置可以正常转发,测试成功。
    但这也引发一个问题,就是start transaction开启的事务也会被拆分,导致事务回滚。因此set autocommit = 0 和正常开启事务能否实现共存,目前还没有找到完全的解决办法。

    【问题2】

    在mysql存储过程中,定义了输入输出参数的情况下,OUTPUT的参数无法返回给应用,经查找stats_mysql_query_digest中的记录发现了问题:


    SQL记录

    其中call调用存错过程被分到了写组,而OUTPUT参数返回给了读组。
    目前将mysql_query_rules增加了一条^select @开头的被分配到写组,有待进一步验证。

    【问题3】

    应用端返回报错,got a packet bigger than 'max_allowed_packet' bytes
    而我检查了mysql端的对应参数,max_allowed_packet我设置了64M,理论上是够用的;于是联想到是否和用户验证一样,在proxySQL层也做了一次过滤,转而查看proxySQL是否有相关参数做了二次限制:
    发现果然有mysql-max_allowed_packet这个参数,将此参数设置为64M后问题解决。

    【问题4】

    应用端返回报错,查看stats_mysql_query_digest发现实现事务如果用了start transaction时,将transaction_persistent置为0,会事务中的语句分散,导致回滚;因此需要改为1

    附默认global variables值

    MySQL [main]> select * from global_variables;
    +-----------------------------------------------------+---------------------------+
    | variable_name                                       | variable_value            |
    +-----------------------------------------------------+---------------------------+
    | mysql-shun_on_failures                              | 5                         |
    | mysql-shun_recovery_time_sec                        | 10                        |
    | mysql-query_retries_on_failure                      | 1                         |
    | mysql-connect_retries_delay                         | 1                         |
    | mysql-connection_delay_multiplex_ms                 | 0                         |
    | mysql-connection_max_age_ms                         | 0                         |
    | mysql-connect_timeout_server_max                    | 10000                     |
    | mysql-eventslog_filename                            |                           |
    | mysql-eventslog_filesize                            | 104857600                 |
    | mysql-default_charset                               | utf8                      |
    | mysql-free_connections_pct                          | 10                        |
    | mysql-session_idle_ms                               | 1000                      |
    | mysql-client_found_rows                             | true                      |
    | mysql-monitor_enabled                               | true                      |
    | mysql-monitor_connect_timeout                       | 600                       |
    | mysql-monitor_ping_max_failures                     | 3                         |
    | mysql-monitor_ping_timeout                          | 1000                      |
    | mysql-monitor_read_only_max_timeout_count           | 3                         |
    | mysql-monitor_replication_lag_interval              | 10000                     |
    | mysql-monitor_replication_lag_timeout               | 1000                      |
    | mysql-monitor_groupreplication_healthcheck_interval | 5000                      |
    | mysql-monitor_groupreplication_healthcheck_timeout  | 800                       |
    | mysql-monitor_replication_lag_use_percona_heartbeat |                           |
    | mysql-monitor_query_interval                        | 60000                     |
    | mysql-monitor_query_timeout                         | 100                       |
    | mysql-monitor_slave_lag_when_null                   | 60                        |
    | mysql-monitor_wait_timeout                          | true                      |
    | mysql-monitor_writer_is_also_reader                 | true                      |
    | mysql-max_allowed_packet                            | 4194304                   |
    | mysql-throttle_connections_per_sec_to_hostgroup     | 1000000                   |
    | mysql-max_transaction_time                          | 14400000                  |
    | mysql-multiplexing                                  | true                      |
    | mysql-forward_autocommit                            | false                     |
    | mysql-enforce_autocommit_on_reads                   | false                     |
    | mysql-autocommit_false_not_reusable                 | false                     |
    | mysql-autocommit_false_is_transaction               | false                     |
    | mysql-verbose_query_error                           | false                     |
    | mysql-hostgroup_manager_verbose                     | 1                         |
    | mysql-threshold_query_length                        | 524288                    |
    | mysql-threshold_resultset_size                      | 4194304                   |
    | mysql-query_digests_max_digest_length               | 2048                      |
    | mysql-query_digests_max_query_length                | 65000                     |
    | mysql-wait_timeout                                  | 28800000                  |
    | mysql-throttle_max_bytes_per_second_to_client       | 2147483647                |
    | mysql-throttle_ratio_server_to_client               | 0                         |
    | mysql-max_stmts_per_connection                      | 20                        |
    | mysql-max_stmts_cache                               | 10000                     |
    | mysql-mirror_max_concurrency                        | 16                        |
    | mysql-mirror_max_queue_length                       | 32000                     |
    | mysql-default_max_latency_ms                        | 1000                      |
    | mysql-query_processor_iterations                    | 0                         |
    | mysql-query_processor_regex                         | 1                         |
    | mysql-long_query_time                               | 1000                      |
    | mysql-query_cache_size_MB                           | 256                       |
    | mysql-poll_timeout_on_failure                       | 100                       |
    | mysql-server_capabilities                           | 45578                     |
    | mysql-session_idle_show_processlist                 | true                      |
    | mysql-query_digests                                 | true                      |
    | mysql-query_digests_lowercase                       | false                     |
    | mysql-servers_stats                                 | true                      |
    | mysql-default_reconnect                             | true                      |
    | mysql-ssl_p2s_ca                                    |                           |
    | mysql-ssl_p2s_cert                                  |                           |
    | mysql-ssl_p2s_key                                   |                           |
    | mysql-ssl_p2s_cipher                                |                           |
    | mysql-init_connect                                  |                           |
    | mysql-default_sql_mode                              |                           |
    | mysql-default_time_zone                             | SYSTEM                    |
    | mysql-connpoll_reset_queue_length                   | 50                        |
    | mysql-stats_time_backend_query                      | false                     |
    | mysql-stats_time_query_processor                    | false                     |
    | mysql-threads                                       | 4                         |
    | mysql-max_connections                               | 2048                      |
    | mysql-default_query_delay                           | 0                         |
    | mysql-default_query_timeout                         | 36000000                  |
    | mysql-have_compress                                 | true                      |
    | mysql-poll_timeout                                  | 2000                      |
    | mysql-interfaces                                    | 0.0.0.0:6033              |
    | mysql-default_schema                                | information_schema        |
    | mysql-stacksize                                     | 1048576                   |
    | mysql-server_version                                | 5.5.30                    |
    | mysql-connect_timeout_server                        | 3000                      |
    | mysql-monitor_username                              | proxysql                  |
    | mysql-monitor_password                              | proxysql                  |
    | mysql-monitor_history                               | 600000                    |
    | mysql-monitor_connect_interval                      | 60000                     |
    | mysql-monitor_ping_interval                         | 10000                     |
    | mysql-monitor_read_only_interval                    | 1500                      |
    | mysql-monitor_read_only_timeout                     | 500                       |
    | mysql-ping_interval_server_msec                     | 120000                    |
    | mysql-ping_timeout_server                           | 500                       |
    | mysql-commands_stats                                | true                      |
    | mysql-sessions_sort                                 | true                      |
    | mysql-connect_retries_on_failure                    | 10                        |
    | admin-stats_credentials                             | stats:stats               |
    | admin-stats_mysql_connections                       | 60                        |
    | admin-stats_mysql_connection_pool                   | 60                        |
    | admin-stats_mysql_query_cache                       | 60                        |
    | admin-stats_system_cpu                              | 60                        |
    | admin-stats_system_memory                           | 60                        |
    | admin-telnet_admin_ifaces                           | (null)                    |
    | admin-telnet_stats_ifaces                           | (null)                    |
    | admin-refresh_interval                              | 2000                      |
    | admin-read_only                                     | false                     |
    | admin-hash_passwords                                | true                      |
    | admin-cluster_username                              |                           |
    | admin-cluster_password                              |                           |
    | admin-cluster_check_interval_ms                     | 1000                      |
    | admin-cluster_check_status_frequency                | 10                        |
    | admin-cluster_mysql_query_rules_diffs_before_sync   | 3                         |
    | admin-cluster_mysql_servers_diffs_before_sync       | 3                         |
    | admin-cluster_mysql_users_diffs_before_sync         | 3                         |
    | admin-cluster_proxysql_servers_diffs_before_sync    | 3                         |
    | admin-cluster_mysql_query_rules_save_to_disk        | true                      |
    | admin-cluster_mysql_servers_save_to_disk            | true                      |
    | admin-cluster_mysql_users_save_to_disk              | true                      |
    | admin-cluster_proxysql_servers_save_to_disk         | true                      |
    | admin-checksum_mysql_query_rules                    | true                      |
    | admin-checksum_mysql_servers                        | true                      |
    | admin-checksum_mysql_users                          | true                      |
    | admin-web_enabled                                   | false                     |
    | admin-web_port                                      | 6080                      |
    | admin-admin_credentials                             | admin:admin|
    | admin-mysql_ifaces                                  | 0.0.0.0:6032              |
    | admin-version                                       | 1.4.8-32-g669c149         |
    +-----------------------------------------------------+---------------------------+
    125 rows in set (0.003 sec)
    

    详述:
    https://baijiahao.baidu.com/s?id=1675243033575644586&wfr=spider&for=pc

    相关文章

      网友评论

        本文标题:ProxySQL管理专题

        本文链接:https://www.haomeiwen.com/subject/sfpbnltx.html