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：同步什么

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： 检查间隔和频率相关参数

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 部分的配置。

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

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) )

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 的带宽。

原文发布时间为：2018-03-18

本文作者：张灿

本文来自云栖社区合作伙伴“老叶茶馆”，了解相关信息可以关注“老叶茶馆”微信公众号