proxysql 系列 ~ 原理与运维分析

一 主从检测机制

   admin查看检测返回值

        select hostgroup_id,hostname,port,status,max_replication_lag from runtime_mysql_servers;

   检测语句

        show slave status

  检测频率

        mysql-monitor_replication_lag_interval：主从延迟检测时间，默认10秒。

  检测值

       second_master_behind为非NULL max_replication_lag

       second_master_behind为NULL(复制出现异常情况)

       mysql-monitor_slave_lag_when_null 默认60s 换算成 max_replication_lag=60

   补充 mysql_servers的status是不能动态更新的,这点要牢记

二 连接池复用

     情况:一个后端DB的连接，可以“同时”被多个客户端使用 

     改进对比

     传统的连接池，会在客户端断开连接（会话）后，把连接放回到池里。

     在ProxySQL中，由于连接复用，连接会在 sql语句 执行结束后，便将连接放回到池里（客户端会话可能并没有断开），这样便可大大提高后端连接的使用效率，而避免前段请求过大导致后端连接数疯长。

三  池总结和复用 

   池

  线程池是为了快速和后端建立新的TCP连接

  连接池是为快速和后端建立新的打开的TCP连接

  处理方式

  1 当应用程序发送了一个MySQL请求给ProxySQL时，ProxySQL首先解析要路由到哪个后端，如果连接池中已经有和该后端的连接，将重用该连接，否则将创建一个新的和后端的连接。

  2 当处理完客户端的请求后，连接会还回主机组管理器(HostGroup Manager)。如果主机组管理器判断了该连接是可以被安全共享的，且连接池未满，则该连接会放进连接池。

 空闲链接

  1 放进连接池的连接都是空闲连接，正在使用的连接是不可能进入连接池的。

  2 ProxySQL会定期发送ping消息来维持空闲连接。如果某连接从上一次ping之后，如果还没有被使用，则该连接被定义为空闲连接

  3 对于每个hostgroup/backend，主机组管理器只会保持连接池中的最大连接数为mysql-free_connections_pct * mysql_servers.max_connections / 100。池中的每个空闲连接都通过间断性的ping来维持它的打开状态。

 空闲链接参数

 1 对于空闲连接ping的时间间隔由变量mysql-ping_interval_server_msec控制

 2 mysql-connection_max_age_ms 当该变量设置的值大于0时(单位毫秒)，如果某个空闲连接(当前没有任何会话使用)的空闲时长超过了这里设置的值，则这个连接会关闭。默认值为0，表示不会因为存活时间而关闭空闲连接

四  proxysql 高可用

   原理 监视指定主机组中所有服务器的read_only值，并且根据read_only的值将服务器分配给写入器或读取器主机组，定义 hostgroup 的主从关系。ProxySQL monitor 模块会监控 HG 后端所有servers 的 read_only 变量，如果发现从库的 read_only 变为0、主库变为1，则认为角色互换了，自动改写      mysql_servers 表里面 hostgroup 关系，达到自动 Failover 效果。

   相关表mysql_replication_hostgroups

   监控值('read_only','super_read_only','innodb_read_only')三者选1,默认read_only,最后一个值是适用于aws

  填写参数

   writer_hostgroup_id reader_hostgroup_id comment

  进行查询

  select * from runtime_mysql_replication_hostgroups 查询有数据库代表成功

  select * from runtime_mysql_servers 从库如果host_group_id已经变成write_group_id确定切换成功

  必须注意

  1 proxysql只负责进行切换并不负责补偿日志,要牢记,必须配合其他高可用手段（通过高可用调节read_only的值和proxysql进行配合)

  2 一旦开启此功能,会自动根据read_only进行分配group,优先级高于mysql_servers你指定插入的w/r-group-id，所以必须监控你从库的read_only,防止加入主库集群

五 proxysql日志

  目的 查看获取值的历史信息

  sql1

  select * from mysql_server_read_only_log order by time_start_us desc limit 20; 查看监控read_only

  sql2

  select * from mysql_server_connect_log order by time_start_us desc limit 20; 查看健康connect

  sql3 

  select  * from  mysql_server_replication_lag_log order by time_start_us desc limit 20; 查看延时lags

六 proxysql周边问题

   1 大量查询虽然导向从库,但是返回的数据量太大导致阻塞proxysql代理,导致性能问题甚至导致阻塞.可能场景常见于

          1 大数据查询 2 特殊需求需要大批量获取数据等

   2 数据库延迟问题导致所有从库打向主库,增大压力

      1 DDL大表操作导致延迟

      2 大事物导致延迟

      解决方法1: DDL操作尽量采用pt-osc操作,然后控制从库延迟参数  2 加大proxysql本身延迟容忍参数(请以实际业务为准) 3 对大事物进行拆分 4 优化慢sql 减少从库IO压力 

   3  业务进行改造

         业务针对主库进行的查询需要添加注释改造业务,后续要养成习惯

   4  版本本身BUG导致

         比如内存泄漏 无端cacsh等,建议时长对github留言区进行跟踪,最好上线采用全新版本,定期对版本进行升级等

   5  是否真的该用proxysql用来代理

         这取决于两个原因

         1 你的业务是读的比例远远大于写的比例,并且写的压力对于主库已经很大

          2 通过测试能保证proxysql读写分离后效率远远高于由于proxysql本身处理所带来的损耗

 6    集群整理描述

       1   一组porxysql管理多组集群,通过mysql_replication_hostgroups 进行分配管理 

       2   每个集群建立一个账号,用于读写操作,对于通用账号没办法解决,因为user_name是唯一的

七 监控

    相关数据库 state

     相关表  select * from stats_mysql_connection_pool;

转载于:https://www.cnblogs.com/danhuangpai/p/11579577.html