ProxySQL Cluster 概述

导读

作者:张灿(邮箱:[email protected],欢迎交流)

知数堂MySQL DBA 班第9期学员

1:前言

ProxySQL 1.4.2 之前,ProxySQL 单点的解决方法有配合keepalived 使用来实现ProxySQL 的主备,但是需要在主备上配置两份完全相同的路由或规则,如果再没有自动运维平台,同时维护两份配置的也是相当麻烦的。而且目前主流的云环境,均不支持keepalived 使用的 VRRP 协议,所以在云环境上就无法通过keepalived 来实现故障切换。从1.4.2 开始,ProxySQL 开始支持原生的 Cluster,这就有效的解决了之前需要借助第三方工具才能解决的单点问题。

另外:ProxySQL Cluster 对MySQL Group Replication 的支持,和任务调度功能,也正在开发中。

2:ProxySQL Cluster

当前版本的ProxySQL Cluster 有2个主要组件:

  • monitoring

  • re-configuration

这2个组件对原有的4个表都是支持的:

  • mysql_query_rules

  • mysql_servers

  • mysql_users

  • proxysql _servers

2.1  Monitoring

为了监控Cluster,ProxySQL Cluster 新加了部分表、命令和变量。

2.1.1 :admin variables

2.1.1.1:同步什么

参数 默认值 描述
admin-checksum_mysql_query_rules true =true时,每次执行LOAD MYSQL QUERY RULES TO RUNTIME时,proxy都会生成一个新的配置checksum。=false时,新的配置不会自动被广播,也不会其他节点同步。
admin-checksum_mysql_servers true =true时,每次执行LOAD MYSQL serversTO RUNTIME时,proxy都会生成一个新的配置checksum。=false时,新的配置不会自动被广播,也不会其他节点同步。
admin-checksum_mysql_users true =true时,每次执行LOAD MYSQL usersTO RUNTIME时,proxy都会生成一个新的配置checksum。=false时,新的配置不会自动被广播,也不会其他节点同步。

2.1.1.2 :认证参数

集群间,Proxy 为了监控其他Proxy 实例需要认证参数:admin-cluster_username 和 admin-cluster_password。而且这2个参数指定的用户名/密码还必须配置到参数 admin-admin_credentials 中,否则会无法连接到其他proxy

admin_credentials="admin:admin;cluster1:secret1pass"

2.1.1.3: 检查间隔和频率相关参数

参数 默认值 描述
admin-cluster_check_interval_ms 1000 定义进行checksum的时间间隔。10~300000
admin-cluster_check_status_frequency 10

2.1.1.4 :持久化相关参数

当有新的集群配置被同步到远端proxy ,并且load to runtime 后,可以控制是否立即将配置自动存盘。 query rules, servers, users 和proxysql servers 分别有admin-cluster_XXX_save_to_disk 相关的参数,默认是 true。

有些原因,可能造成多个ProxySQL 实例在同一时间发生reconfigured 的情况:

  • 所有proxy 实例都在监控一个MySQL 集群,并且都发现了MySQL 集群发生了failover。在很短的时间内(通常小于1s),所有proxy 实例都会发生同样的配置变更,并且不需要和其他实例进行同步

  • 所有实例都探测到网络异常或者MySQL DB 反应慢,那所有proxy 实例都会避开该节点。此时所有proxy 实例都会执行同样的动作,从而也不用从其他实例上同步配置。

  • 极端情况下,一个slave 由于lag 很大,并且主动从集群中退出。此时所有proxy 实例也都会发生相应的reconfiguration。

2.1.1.5 :延迟同步

ProxySQL Cluster 可以定义达到多少个checksum 不同之后,才在集群内部进行配置同步。

query rules, servers, users 和proxysql servers 分别有admin-cluster_XXX_diffs_before_sync 相关的参数,取值范围0 ~ 1000,0 代表从不同步。默认3。

2.1.2 :configuration table

2.1.2.1: proxysql_servers

ProxySQL 集群有哪些实例,可以查看proxysql_servers 表。在新增ProxySQL 实例时,也需要 insert 该表,或者修改cnf 文件中的 proxysql_servers 部分的配置。

CREATE TABLE proxysql_servers (
    hostname VARCHAR NOT NULL,
    port INT NOT NULL DEFAULT 6032,
    weight INT CHECK (weight >= 0) NOT NULL DEFAULT 0,
    comment VARCHAR NOT NULL DEFAULT '',
    PRIMARY KEY (hostname, port) )

注意: weight 在当前版本中还未正式启用。

2.1.2.2:runtime_checksums_values

CREATE TABLE runtime_checksums_values (
    name VARCHAR NOT NULL,
    version INT NOT NULL,
    epoch INT NOT NULL,
    checksum VARCHAR NOT NULL,
    PRIMARY KEY (name))

runtime_checksums_values 记录当 load to runtime 被执行时系统的信息。

  • epoch : 记录load to runtime 被执行的时间

  • checksum: 记录每个组件在load to runtime 时的checksum 值

  • version :记录load to run 的次数。每次重启实例后,该值都会被重置为 1

目前6个组件中只有4个可以生成checksum,不能生成的组件是:admin_variables,mysql_variables。 checnsum 只有在执行了load to run ,并且admin-checksum_XXX = true 时,才可以正常生成。

2.1.3: state tables

有三个表被加入到stat 表中。

2.1.3.1:stats_proxysql_servers_checksums

记录集群中各个实例的组件checksum 信息。

Admin> SHOW CREATE TABLE stats.stats_proxysql_servers_checksums\G
*************************** 1. row ***************************
       table: stats_proxysql_servers_checksums
Create Table: CREATE TABLE stats_proxysql_servers_checksums (
    hostname VARCHAR NOT NULL,
    port INT NOT NULL DEFAULT 6032,
    name VARCHAR NOT NULL,
    version INT NOT NULL,
    epoch INT NOT NULL,
    checksum VARCHAR NOT NULL,
    changed_at INT NOT NULL,
    updated_at INT NOT NULL,
    diff_check INT NOT NULL,
    PRIMARY KEY (hostname, port, name) )
  • changed_at :探测到发生checksum change 的时间

  • updated_at :上次更新checksum 的时间

  • diff_check :计数器,用来记录本地proxy 和远端proxy checksum 不同的次数,当达到参数cluster_*_diffs_before_sync 定义的阀值后,才能触发集群的同步动作。如果 diff_check 很大,但是又没触发同步动作,那远端的proxy 就不是一个可靠的数据源。

2.1.3.2:stats_proxysql_servers_metrics

该表用来显示群集模块在各个实例中执行 SHOW MYSQL STATUS 时,当前系统的部分指标。目前该表只是用来debug 的,在未来该表的各个指标将用来反映各个实例的健康状态。

Admin> SHOW CREATE TABLE stats.stats_proxysql_servers_metrics\G
*************************** 1. row ***************************
       table: stats_proxysql_servers_metrics
Create Table: CREATE TABLE stats_proxysql_servers_metrics (
    hostname VARCHAR NOT NULL,
    port INT NOT NULL DEFAULT 6032,
    weight INT CHECK (weight >= 0) NOT NULL DEFAULT 0,
    comment VARCHAR NOT NULL DEFAULT '',
    response_time_ms INT NOT NULL,
    Uptime_s INT NOT NULL,
    last_check_ms INT NOT NULL,
    Queries INT NOT NULL,
    Client_Connections_connected INT NOT NULL,
    Client_Connections_created INT NOT NULL,
    PRIMARY KEY (hostname, port) )
  • weight: 和proxysql_servers.weight 一样,暂时未使用。

  • response_time_ms:单位毫秒。执行show mysql status 的响应时间。

  • uptime_s: 各个实例的启动时间。

  • queries:各个实例上已经执行的query 数量

  • last_check_ms:上一次执行 show mysql status 距今的时间,单位毫秒。

  • Client_Connections_connected :已经连接上来的客户端连接数

  • Client_Connections_created:被创建的客户端连接数

2.1.3.3:stats_proxysql_servers_status

在目前的1.4.6 版本中,该表还未启用。

2.2 :Re-configuration

因为集群间,所有节点都是相互监控的。所以当配置发生变动时,它们可以立即发现。当其他节点的配置发生变动时,本节点会先去检查一次它自身的配置,因为有可能remote instance 和local instance 同时发生配置变动。如果不同:

  • 如果它们自身的 version = 1,就去找集群内 version >1,并且 epoch 最高的节点,并立即同步。

  • 如果version >1, 该节点开始统计和其他节点间的differ 数。

    • 当 differ 大于 cluster__name___diffs_before_sync , 并且cluster__name__diffs_before_sync > 0, 就去找集群内 version >1, 并且epoch 最高的节点,并立即同步。

同步过程如下:

  • 健康检查语句会执行一系列的SELECT 语句,例如 Select list_of_columns FROM runtime_module.

SELECT hostgroup_id, hostname, port, status, weight, compression, max_connections, max_replication_lag, use_ssl, max_latency_ms, comment FROM runtime_mysql_servers;
SELECT writer_hostgroup, reader_hostgroup, comment FROM runtime_mysql_replication_hostgroups;
  • 删除本地配置。例如:

DELETE FROM mysql_servers;
DELETE FROM mysql_replication_hostgroups;
  • 将新的配置insert 到本地表

  • 内部提交LOAD module_name TO RUNTIME。 对应的version 会增加,并且生成一个新的 checksum

  • 如果cluster__name__save_to_disk =true,还会内部执行 SAVE module_name TO DISK。

3:网络消耗

从上面的论述可以看出,ProxySQL Cluster 中每个节点都在监控其他节点,是个很典型的点对点的网络。 为了减少网络开销,节点间并不总是交换所有的checksum 信息,而是将所有version 、所有checksum 相结合产生的单个新的 checksum 进行交换。所以一旦这个新的checksum 发生变动,那么得到详细的各个模块的checksum。 在一个200个节点的集群中,如果每个节点每 1000ms 去探测一次,每个节点需要 50KB 的带宽。

4:参考

https://github.com/sysown/proxysql/wiki/ProxySQL-Cluster

http://www.proxysql.com/blog/proxysql-cluster


640.gif?

扫码加入知数堂技术交流QQ群

(群号:579036588)

群内可@各位助教了解更多课程信息

640.png?



加入知数堂

挑战40万+年薪!


640?640?640?640?


知数堂

叶金荣与吴炳锡联合打造

领跑IT精英培训

行业资深专家强强联合,倾心定制

MySQL实战/MySQL优化 / Python/ SQL优化

数门精品课程

紧随技术发展趋势,定期优化培训教案

融入大量生产案例,贴合企业一线需求

社群陪伴学习,一次报名,可学1年

DBA、开发工程师必修课

上千位学员已华丽转身,薪资翻番,职位提升

改变已悄然发生,你还在等什么?

640.png?


扫码下载知数堂精品课程试听视频

或点击“阅读原文”直达下载地址

(MySQL 实战/优化、大数据实战、Python开发,及SQL优化等课程)

密码:hg3h


640?wx_fmt=png

640.png?


你可能感兴趣的:(ProxySQL Cluster 概述)