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 的情况：

极端情况下，一个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 被执行时系统的信息。

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

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

Client_Connections_created：被创建的客户端连接数

2.1.3.3：stats_proxysql_servers_status

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

2.2 ：Re-configuration

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

同步过程如下：

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;

3：网络消耗

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

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

本文作者：张灿

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