MySQL-ProxySQL中间件（二）| Admin Schemas介绍

时间 2019-11-18

标签 mysql proxysql 中间件 admin schemas 介绍栏目 MySQL 繁體版

原文原文链接

正文

此次咱们主要来介绍下ProxySQL中核心数据库Main的表结构及MGR监控配置脚本（内附彩蛋：MySQL 8.0 MGR 监控脚本）

计划其他数据库，随着功能介绍再作详细说明，本文不作过多扩展。

The Admin Schemas

ProxySQL管理界面是一个使用MySQL协议的界面，任何可以经过这种界面发送命令的客户端都很容易配置它。 html

ProxySQL解析经过此接口发送的查询以查找特定于ProxySQL的任何命令，若是适当，则将它们发送到嵌入式SQLite3引擎以运行查询。前端

请注意，SQLite3和MySQL使用的SQL语法不一样，所以并不是全部适用于MySQL的命令都适用于SQLite3。例如，尽管管理界面接受USE命令，但它不会更改默认架构，由于SQLite3中不提供此功能。mysql

链接到ProxySQL管理界面时，咱们能够看到有一些数据库可用。 ProxySQL将SHOW DATABASES命令转换为SQLite3的等效命令。git

这些数据库的做用以下：github

main：内存配置数据库 。
使用此数据库，能够轻松地以自动方式查询和更新ProxySQL的配置。 web

使用LOAD MYSQL USERS FROM MEMORY和相似命令，存储在此处的配置能够在运行时传播到ProxySQL使用的内存数据结构。正则表达式

disk：基于磁盘的“main”镜像。
在从新启动时，“main”不会持久存在，而且能够从“磁盘”数据库或配置文件中加载，具体取决于启动标志和磁盘数据库的存在。算法

stats：包含从代理的内部功能收集的运行时指标。
示例度量标准包括每一个查询规则匹配的次数，当前运行的查询等。sql

monitor：包含与ProxySQL链接的后端服务器相关的监控指标。
示例度量标准包括链接到后端服务器或对其进行ping操做的最短和最长时间。数据库

myhgm：仅在调试版本中启用
此外，使用这两种类型的用户使用这些默认凭据访问管理数据库：

user：admin / password：admin - 具备对全部表的读写访问权限

user：stats / password：stats - 具备对统计表的只读访问权限。这用于从ProxySQL中提取指标，而不会暴露太多的数据库

上述的访问凭据，可经过变量admin-admin_credentials和admin-stats_credentials进行配置。

MAIN数据库

主要包含了如下数据表：

核心配置表

1. mysql_server

字段定义

hostgroup_id

  包含此mysqld实例的主机组。请注意，同一实例能够是多个主机组的一部分

hostname，port

  能够联系mysqld实例的TCP端点

gtid_port

  ProxySQL Binlog Reader侦听GTID跟踪的后端服务器端口

status

  ONLINE - 后端服务器彻底能够运行

  SHUNNED - 后端服务器暂时中止使用，由于在时间过短或复制延迟超过容许阈值的状况下链接错误太多

  OFFLINE_SOFT - 当服务器进入OFFLINE_SOFT模式时，再也不接受新的传入链接，而现有链接将保持不变，直到它们变为非活动状态。换句话说，链接一直在使用，直到当前事务完成。这容许优雅地分离后端

  OFFLINE_HARD - 当服务器进入OFFLINE_HARD模式时，现有链接被丢弃，而新的传入链接也不被接受。这至关于从主机组中删除服务器，或暂时将其从主机组中取出以进行维护工做

weight

  服务器相对于其余权重的权重越大，从主机组中选择服务器的几率就越高

compression

  若是该值大于0，则与该服务器的新链接将使用压缩

max_connections

  ProxySQL将向此后端服务器打开的最大链接数。即便此服务器具备最高权重，但一旦达到此限制，就不会向其打开新链接。请确保后端配置了正确的max_connections值，以免ProxySQL尝试超出该限制

max_replication_lag

  若是更大且为0，ProxySQL将按期监视复制延迟，若是超出此阈值，它将暂时避开主机，直到复制遇上

use_ssl

  若是设置为1，则与后端的链接将使用SSL

max_latency_ms

  按期监视ping时间。若是主机的ping时间大于max_latency_ms，则它将从链接池中排除（尽管服务器保持ONLINE状态）

comment

  可用于用户定义的任何目的的文本字段。能够是主机存储内容的描述，添加或禁用主机的提醒，或某些检查器脚本处理的JSON。

2. mysql_replication_hostgroups

表mysql_replication_hostgroups定义用于传统主/从异步或者半同步或者加强半同步复制的复制主机组。

若是使用Group Replication / InnoDB Cluster或Galera / Percona XtraDB Cluster进行复制，则应使用mysql_group_replication_hostgroups或mysql_galera_hostgroups（在2.x版中提供）。

mysql_replication_hostgroups中的每一行表明一对writer_hostgroup和reader_hostgroup。

ProxySQL将监视指定主机组中全部服务器的read_only值，并根据read_only的值将服务器分配给writer组或reader组。

字段的注释可用于存储任意数据。

字段定义

writer_hostgroup - 默认状况下将发送全部请求的主机组，MySQL中read_only = 0的节点将分配给该主机组。

reader_hostgroup - 应该发送读取请求的主机组，应该定义查询规则或单独的只读用户将流量路由到此主机组，将read_only = 1的节点分配给该主机组。

check_type - 执行只读检查时检查的MySQL变量，默认状况下为read_only（也可使用super_read_only）。对于AWS Aurora，应使用innodb_read_only。

comment - 可用于用户定义的任何目的的文本字段。能够是集群存储内容的描述，添加或禁用主机组的提醒，或某些检查器脚本处理的JSON。

3. mysql_group_replication_hostgroups（MGR）

字段定义

writer_hostgroup - 默认状况下将发送全部请求的主机组，MySQL中read_only = 0的节点将分配给该主机组。

backup_writer_hostgroup - 若是集群有多个节点，其read_only = 0和max_writers，则ProxySQL会将其余节点（超过max_writes的节点）放入backup_writer_hostgroup中。

reader_hostgroup - 应该发送读请求的主机组，将read_only = 1的节点分配给该主机组。

offline_hostgroup - 当ProxySQL的监视肯定节点为OFFLINE时，它将被放入offline_hostgroup。

active - 启用时，ProxySQL监视主机组并在适当的主机组之间移动节点。

max_writers' - 此值肯定writer_hostgroup中应容许的最大节点数，超过此值的节点将放入backup_writer_hostgroup中

writer_is_also_reader - 肯定是否应将同一个节点添加到reader_hostgroup和writer_hostgroup中。

max_transactions_behind - 肯定在屏蔽节点以前，ProxySQL应容许的写入器后面的最大事务数，以防止读取落后过多（这是经过查询MySQL中sys.gr_member_routing_candidate_status表的transactions_behind字段来肯定的）。

comment - 可用于用户定义的任何目的的文本字段。能够是集群存储内容的描述，添加或禁用主机组的提醒，或某些检查器脚本处理的JSON。

4. mysql_galera_hostgroups（PXC）

表mysql_galera_hostgroups（在ProxySQL 2.x及更高版本中可用）定义了用于Galera Cluster / Percona XtraDB Cluster的主机组。

字段定义

writer_hostgroup - 默认状况下将发送全部流量的主机组，MySQL中read_only = 0的节点将分配给该主机组。

backup_writer_hostgroup - 若是集群有多个节点，其read_only = 0和max_writers，则ProxySQL会将其余节点（超过max_writes）放入backup_writer_hostgroup中。

reader_hostgroup - 应该发送读取流量的主机组，应该定义查询规则或单独的只读用户将流量路由到此主机组，将read_only = 1的节点分配给该主机组。

offline_hostgroup - 当ProxySQL的监控肯定主机处于OFFLINE时，它将被放入offline_hostgroup

active - 启用时，ProxySQL监视主机组并在适当的主机组之间移动服务器。

max_writers - 此值肯定writer_hostgroup中应容许的最大节点数，超过此值的节点将放入backup_writer_hostgroup中

writer_is_also_reader - 肯定是否应将节点添加到reader_hostgroup以及在提高后的writer_hostgroup。

max_transactions_behind - 肯定在避开节点以前ProxySQL应容许的集群后面的最大写集数，以防止过期读取（这是经过查询wsrep_local_recv_queue Galera变量肯定的）。

comment - 可用于用户定义的任何目的的文本字段。能够是集群存储内容的描述，添加或禁用主机组的提醒，或某些检查器脚本处理的JSON。

5. mysql_users

表mysql_users定义MySQL用户，用于链接后端。

字段定义

username,password - 用于链接mysqld或ProxySQL实例的凭据。

active - 将在数据库中跟踪active = 0的用户，但永远不会在内存数据结构中加载

default_hostgroup - 若是此用户发送的查询没有匹配规则，则生成的流量将发送到指定的主机组

default_schema - 默认状况下链接应更改的架构

schema_locked - 尚不支持（TODO：check）

transaction_persistent - 若是是一个事务内的多条SQL，只会路由到一个主机组中。

fast_forward - 若是设置，它绕过查询处理层（重写，缓存）并直接将查询传递给后端服务器。

frontend - 若是设置为1，则此（用户名，密码）对用于对ProxySQL实例进行身份验证

backend - 若是设置为1，则此（用户名，密码）对用于针对任何主机组对mysqld服务器进行身份验证

max_connections - 定义特定用户的最大容许前端链接数。

comment - 可用于用户定义的任何目的的文本字段。能够是集群存储内容的描述，添加或禁用主机组的提醒，或某些检查器脚本处理的JSON。

注意，目前全部用户都须要将“frontend”和“后backend”都设置为1。

ProxySQL的将来版本将在前端和后端之间分离证书。

经过这种方式，前端永远不会知道直接链接到后端的凭证，强制经过ProxySQL进行全部链接并提升系统的安全性。

fast_forward 注意事项：

1.   它不须要不一样的端口：完整的功能代理逻辑和“快进”逻辑在同一代码/模块中实现

2.   fast_forward是基于每一个用户实现的：取决于链接到ProxySQL的用户，启用或禁用fast_forward

3.   验证后启用fast_forward算法：客户端仍然对ProxySQL进行身份验证，当客户端开始发送流量时，ProxySQL将建立链接。这意味着在链接阶段仍然会处理链接错误。

4. fast_forward不支持SSL

5.   若是使用压缩，则必须在两端启用它

注意：mysql_users中的用户也不该该与admin-admin_credentials和admin-stats_credentials里的配置相同

6. mysql_query_rules

表mysql_query_rules定义了路由策略和属性。

字段定义

rule_id - 规则的惟一ID。规则以rule_id顺序处理

active - 查询处理模块将仅考虑active = 1的规则，而且只将活动规则加载到运行时。

username - 匹配用户名的过滤条件。若是为非NULL，则仅当使用正确的用户名创建链接时，查询才会匹配

schemaname - 匹配schemaname的过滤条件。若是为非NULL，则仅当链接使用schemaname做为默认模式时，查询才会匹配（在mariadb / mysql schemaname中等效于databasename）

flagIN，flagOUT，apply -

这些容许咱们建立一个接一个地应用的“规则链”。
输入标志值设置为0，而且在开始时仅考虑flagIN = 0的规则。
当为特定查询找到匹配规则时，将评估flagOUT，若是为NOT NULL，则将使用flagOUT中的指定标志标记查询。
若是flagOUT与flagIN不一样，则查询将退出当前链并输入一个新的规则链，其中flagIN做为新的输入标志。
若是flagOUT与flagIN匹配，则将针对具备所述flagIN的第一个规则再次从新评估查询。
这种状况会发生，直到没有更多匹配规则，或者apply设置为1（这意味着这是要应用的最后一条规则）

client_addr - 匹配来自特定源的流量

proxy_addr - 匹配特定本地IP上的传入流量

proxy_port - 匹配特定本地端口上的传入流量

使用stats_mysql_query_digest.digest返回的特定摘要匹配查询

match_digest - 与查询摘要匹配的正则表达式。另请参见https://github.com/sysown/proxysql/wiki/Global-variables#mysql-query_processor_regex

match_pattern - 与查询文本匹配的正则表达式。另请参见https://github.com/sysown/proxysql/wiki/Global-variables#mysql-query_processor_regex

negate_match_pattern - 若是将其设置为1，则只有与查询文本不匹配的查询才会被视为匹配项。这在与match_pattern或match_digest匹配的正则表达式前面充当NOT运算符

re_modifiers -

用逗号分隔的选项列表，用于修改RE引擎的行为。使用CASELESS，匹配不区分大小写。

使用GLOBAL，替换是全局的（替换全部匹配而不只仅是第一个匹配）。

为了向后兼容，默认状况下仅启用CASELESS。有关更多详细信息，另请参见https://github.com/sysown/proxysql/wiki/Global-variables#mysql-query_processor_regex。

replace_pattern -

这是用于替换匹配模式的模式。

它是使用RE2 :: Replace完成的，所以值得一看有关的在线文档：https://github.com/google/re2/blob/master/re2/re2.h#L378。

请注意，这是可选的，当缺乏此选项时，查询处理器将仅缓存，路由或设置其余参数而不重写。

destination_hostgroup -

将匹配的查询路由到此主机组。

除非存在已启动的事务且登陆用户将transaction_persistent标志设置为1（请参阅mysql_users表），不然会发生这种状况。

cache_ttl - 缓存查询结果的毫秒数。注意：在ProxySQL 1.1中，cache_ttl只需几秒钟

cache_empty_result -

控制是否缓存没有行的结果集

从新链接 - 未使用的功能

timeout -

应执行匹配或重写查询的最大超时（以毫秒为单位）。

若是查询运行的时间超过特定阈值，则会自动终止查询。若是未指定timeout，则应用全局变量mysql-default_query_timeout

retries - 在执行查询期间检测到失败时须要从新执行查询的最大次数。若是未指定重试，则应用全局变量mysql-query_retries_on_failure

delay -

延迟执行查询的毫秒数。

这本质上是一种限制机制和QoS，容许优先考虑某些查询而不是其余查询。

此值将添加到适用于全部查询的mysql-default_query_delay全局变量中。将来版本的ProxySQL将提供更高级的限制机制。

mirror_flagOUT和mirror_hostgroup - 与镜像相关的设置 https://github.com/sysown/proxysql/wiki/Mirroring。

error_msg - 将阻止查询，并将指定的error_msg返回给客户端

OK_msg - 将为使用已定义规则的查询返回指定的消息

sticky_conn - 还没有实现

multiplex -

若是为0，则禁用Multiplex。

若是为1，若是没有任何其余条件阻止此操做（如用户变量或事务），则能够从新启用Multiplex。

若是为2，则不会仅针对当前查询禁用多路复用。请参阅wiki默认为NULL，所以不会修改多路复用策略

gtid_from_hostgroup - 定义哪一个主机组应该用做GTID一致性读取的领导者（一般是复制主机组对中定义的WRITER主机组）

log- 将记录查询

apply - 当设置为1时，在匹配和处理此规则后，将再也不评估进一步的查询（注意：以后不会评估mysql_query_rules_fast_routing规则）

comment- 自由格式文本字段，可用于查询规则的描述性注释

7. mysql_query_rules_fast_routing

表mysql_query_rules_fast_routing是mysql_query_rules的扩展，以后会对快速路由策略和属性进行评估（仅在ProxySQL 1.4.7+中可用）。

字段定义

username - 与用户名匹配的过滤条件，只有在使用正确的用户名创建链接时，查询才会匹配

schemaname - 匹配schemaname的过滤条件，只有当链接使用schemaname做为默认模式时，查询才会匹配（在mariadb / mysql schemaname中，这至关于databasename）

flagIN - 与mysql_query_rules中flagin相同，并与mysql_query_rules表中指定的flagout / apply相关联

destination_hostgroup - 将匹配的查询路由到此主机组。

comment- 自由格式文本字段，可用于查询规则的描述性注释

8. global_variables\mysql_collations\scheduler 暂不介绍了，后面会逐步投在功能介绍里说起

Runtime层对应表

表以runtime_开头，其他基本与MAIN库中的表名相同，例如：runtime_mysql_servers 是内存层 mysql_servers表的对应表

runtime_global_variables : runtime version of global_variables
runtime_mysql_replication_hostgroups : runtime version of mysql_replication_hostsgroups
runtime_mysql_galera_hostgroups : runtime version of mysql_replication_hostsgroups
runtime_mysql_group_replication_hostgroups : runtime version of mysql_replication_hostsgroups
runtime_mysql_query_rules : runtime version of mysql_query_rules
runtime_mysql_query_rules_fast_routing : runtime version of mysql_query_rules_fast_routing
runtime_mysql_servers : runtime version of mysql_servers
runtime_mysql_users : runtime version of mysql_users
runtime_proxysql_servers : runtime version of proxysql_servers
runtime_scheduler : runtime version of scheduler

请注意，若是ProxySQL从新启动，若是内容未保存在磁盘数据库中，则内存表（MAIN数据库）的全部内容都将丢失。

Disk层对应表

“disk”数据库与“main”数据库具备彻底相同的表，具备相同的语义。

惟一的主要区别是这些表存储在磁盘上，而不是存储在内存中。

每当从新启动ProxySQL时，将今后数据库开始填充内存中的“main”数据库。

监控MGR，须要在MySQL实例中配置一些监控脚本（MySQL 5.7 和 MySQL 8.0略有不一样）

该脚本须要配置到sys库下，因笔记web显示问题，没法显示折行，可是不影响复制，能够自行复制粘贴出来便可。

先看看执行效果

 
        select * from sys.gr_member_routing_candidate_status;
+------------------+-----------+---------------------+----------------------+
| viable_candidate | read_only | transactions_behind | transactions_to_cert |
+------------------+-----------+---------------------+----------------------+
| YES              | NO        |                   0 |                    0 |
+------------------+-----------+---------------------+----------------------+
​
viable_candidate：MGR当前节点是否正常
read_only：当前节点是否开启了只读
transactions_behind：MGR应用relay log的队列中，积压事务数
transactions_to_cert：MGR当前节点的验证队列，积压事务数 
       

MySQL5.7，配置脚本为：

 
       USE sys;
​
DELIMITER $$
​
CREATE FUNCTION IFZERO(a INT, b INT) RETURNS INT DETERMINISTIC RETURN IF(a = 0, b, a)$$
​
CREATE FUNCTION LOCATE2(needle TEXT(10000), haystack TEXT(10000), offset INT) 
RETURNS INT DETERMINISTIC RETURN IFZERO(LOCATE(needle, haystack, offset), LENGTH(haystack) + 1)$$
​
CREATE FUNCTION GTID_NORMALIZE(g TEXT(10000)) 
RETURNS TEXT(10000) DETERMINISTIC RETURN GTID_SUBTRACT(g, '')$$
​
CREATE FUNCTION GTID_COUNT(gtid_set TEXT(10000)) 
RETURNS INT DETERMINISTIC BEGIN DECLARE result BIGINT DEFAULT 0; DECLARE colon_pos INT; 
DECLARE next_dash_pos INT; DECLARE next_colon_pos INT; DECLARE next_comma_pos INT; 
SET gtid_set = GTID_NORMALIZE(gtid_set); SET colon_pos = LOCATE2(':', gtid_set, 1); 
WHILE colon_pos != LENGTH(gtid_set) + 1 DO SET next_dash_pos = LOCATE2('-', gtid_set, colon_pos + 1); 
SET next_colon_pos = LOCATE2(':', gtid_set, colon_pos + 1); SET next_comma_pos = LOCATE2(',', gtid_set, colon_pos + 1); 
IF next_dash_pos < next_colon_pos AND next_dash_pos < next_comma_pos 
THEN SET result = result + SUBSTR(gtid_set, next_dash_pos + 1, 
LEAST(next_colon_pos, next_comma_pos) - (next_dash_pos + 1)) - SUBSTR(gtid_set, colon_pos + 1, next_dash_pos - (colon_pos + 1)) + 1; 
ELSE SET result = result + 1; END IF; 
SET colon_pos = next_colon_pos; 
END WHILE; RETURN result; 
END$$
​
CREATE FUNCTION gr_applier_queue_length() 
RETURNS INT DETERMINISTIC 
BEGIN RETURN 
(SELECT sys.gtid_count( GTID_SUBTRACT( (SELECT Received_transaction_set 
                                        FROM performance_schema.replication_connection_status 
                                        WHERE Channel_name = 'group_replication_applier' ), (SELECT @@global.GTID_EXECUTED) ))); 
END$$
​
CREATE FUNCTION gr_member_in_primary_partition() 
RETURNS VARCHAR(3) DETERMINISTIC BEGIN RETURN (SELECT IF( MEMBER_STATE='ONLINE' AND ((
    SELECT COUNT() FROM performance_schema.replication_group_members WHERE MEMBER_STATE != 'ONLINE') >= ((
        SELECT COUNT() FROM performance_schema.replication_group_members)/2) = 0), 'YES', 'NO' ) 
                                               FROM performance_schema.replication_group_members 
                                               JOIN performance_schema.replication_group_member_stats USING(member_id)); 
END$$
​
CREATE VIEW gr_member_routing_candidate_status AS
    SELECT 
        sys.gr_member_in_primary_partition() AS viable_candidate,
        IF((SELECT 
                    (SELECT 
                                GROUP_CONCAT(variable_value)
                            FROM
                                performance_schema.global_variables
                            WHERE
                                variable_name IN ('read_only' , 'super_read_only')) != 'OFF,OFF'
                ),
            'YES',
            'NO') AS read_only,
        sys.gr_applier_queue_length() AS transactions_behind,
        Count_Transactions_in_queue AS 'transactions_to_cert'
    FROM
        performance_schema.replication_group_member_stats$$
​
DELIMITER ; 
      

MySQL8.0，配置脚本为：

USE sys;

DELIMITER $$

CREATE FUNCTION IFZERO(a INT, b INT)
RETURNS INT
DETERMINISTIC
RETURN IF(a = 0, b, a)$$

CREATE FUNCTION LOCATE2(needle TEXT(10000), haystack TEXT(10000), offset INT)
RETURNS INT
DETERMINISTIC
RETURN IFZERO(LOCATE(needle, haystack, offset), LENGTH(haystack) + 1)$$

CREATE FUNCTION GTID_NORMALIZE(g TEXT(10000))
RETURNS TEXT(10000)
DETERMINISTIC
RETURN GTID_SUBTRACT(g, '')$$

CREATE FUNCTION GTID_COUNT(gtid_set TEXT(10000))
RETURNS INT
DETERMINISTIC
BEGIN
  DECLARE result BIGINT DEFAULT 0;
  DECLARE colon_pos INT;
  DECLARE next_dash_pos INT;
  DECLARE next_colon_pos INT;
  DECLARE next_comma_pos INT;
  SET gtid_set = GTID_NORMALIZE(gtid_set);
  SET colon_pos = LOCATE2(':', gtid_set, 1);
  WHILE colon_pos != LENGTH(gtid_set) + 1 DO
     SET next_dash_pos = LOCATE2('-', gtid_set, colon_pos + 1);
     SET next_colon_pos = LOCATE2(':', gtid_set, colon_pos + 1);
     SET next_comma_pos = LOCATE2(',', gtid_set, colon_pos + 1);
     IF next_dash_pos < next_colon_pos AND next_dash_pos < next_comma_pos THEN
       SET result = result +
         SUBSTR(gtid_set, next_dash_pos + 1,
                LEAST(next_colon_pos, next_comma_pos) - (next_dash_pos + 1)) -
         SUBSTR(gtid_set, colon_pos + 1, next_dash_pos - (colon_pos + 1)) + 1;
     ELSE
       SET result = result + 1;
     END IF;
     SET colon_pos = next_colon_pos;
  END WHILE;
  RETURN result;
END$$

CREATE FUNCTION gr_applier_queue_length()
RETURNS INT
DETERMINISTIC
BEGIN
  RETURN (SELECT sys.gtid_count( GTID_SUBTRACT( (SELECT
Received_transaction_set FROM performance_schema.replication_connection_status
WHERE Channel_name = 'group_replication_applier' ), (SELECT
@@global.GTID_EXECUTED) )));
END$$

CREATE FUNCTION gr_member_in_primary_partition()
RETURNS VARCHAR(3)
DETERMINISTIC
BEGIN
  RETURN (SELECT IF( MEMBER_STATE='ONLINE' AND ((SELECT COUNT(*) FROM
performance_schema.replication_group_members WHERE MEMBER_STATE != 'ONLINE') >=
((SELECT COUNT(*) FROM performance_schema.replication_group_members)/2) = 0),
'YES', 'NO' ) FROM performance_schema.replication_group_members JOIN
performance_schema.replication_group_member_stats USING(member_id) 
          where performance_schema.replication_group_members.member_host=@@hostname);
END$$

CREATE VIEW gr_member_routing_candidate_status AS
    SELECT 
        sys.gr_member_in_primary_partition() AS viable_candidate,
        IF((SELECT 
                    (SELECT 
                                GROUP_CONCAT(variable_value)
                            FROM
                                performance_schema.global_variables
                            WHERE
                                variable_name IN ('read_only' , 'super_read_only')) != 'OFF,OFF'
                ),
            'YES',
            'NO') AS read_only,
        sys.gr_applier_queue_length() AS transactions_behind,
        Count_Transactions_in_queue AS 'transactions_to_cert'
    FROM
        performance_schema.replication_group_member_stats a
            JOIN
        performance_schema.replication_group_members b ON a.member_id = b.member_id
    WHERE
        b.member_host IN (SELECT 
                variable_value
            FROM
                performance_schema.global_variables
            WHERE
                variable_name = 'hostname')$$

DELIMITER ;

MySQL-ProxySQL中间件（二）| Admin Schemas介绍

目录

正文

The Admin Schemas

MAIN数据库

主要包含了如下数据表：

核心配置表

1. mysql_server

字段定义

2. mysql_replication_hostgroups

字段定义

3. mysql_group_replication_hostgroups（MGR）

字段定义

4. mysql_galera_hostgroups（PXC）

字段定义

5. mysql_users

字段定义

fast_forward 注意事项：

6. mysql_query_rules

字段定义

7. mysql_query_rules_fast_routing

字段定义

8. global_variables\mysql_collations\scheduler 暂不介绍了，后面会逐步投在功能介绍里说起

Runtime层对应表

Disk层对应表

监控MGR，须要在MySQL实例中配置一些监控脚本（MySQL 5.7 和 MySQL 8.0略有不一样）

先看看执行效果

MySQL5.7，配置脚本为：

MySQL8.0，配置脚本为：