ProxySQL 入门教程

ProxySQL 作为一款强大的中间件为 MySQL 的架构提供了有力的支持。

目前可以很好的支持 Master Slave\ MGR \ PXC等,并提供连接池、读写分离、日志记录等功能,当然还有很多其他实用功能,这里不一一列举了。

本文都是基础概念,基本出自官方文档,官方已经解释的非常清晰,我就不太多加工,汇总一些实用的分享给大家。

安装

ProxySQL 安装非常简单。

连接 ProxySQL

ProxySQL 默认管理端口 6032,默认需要 127.0.0.1 来进入,进入方式和连接MySQL 方式一致:

ProxySQL 运行机制

RUNTIME

RUNTIME 表示处理请求的线程使用的 ProxySQL 的内存数据结构。

Runtime Variables 包含了:

1. Global Variables 的实际值。

2. 将后端的服务器列表分组到 hostgroup 中。

3. 让 MySQL 的 User 们可以连接 ProxySQL。

注意:Runntime 层数据,谁都不能直接修改,必须通过下一层来提交修改。

MEMORY

MEMORY(有时也称为 Main)表示通过 MySQL 兼容接口公开的内存数据库。用户可以将 MySQL 客户端连接到此接口,并查询各种 ProxySQL 配置表/数据库。

通过此接口可用的配置表是:

mysql_servers - ProxySQL 连接到的后端服务器列表 mysql_users - 连接到 ProxySQL 的用户及其凭据列表。请注意,ProxySQL 也将使用相同的凭据连接到后端服务器! mysql_query_rules - 将流量路由到各种后端服务器时评估的查询规则列表。这些规则还可以重写查询,甚至可以缓存已执行查询的结果。 global_variables - 代理配置使用的全局变量列表,可在运行时调整。

DISK 和 CONFIG FILE

DISK 表示磁盘上的 SQLite3 数据库,默认位置为 $(DATADIR)/proxysql.db。

在重新启动时,未保留的内存中配置将丢失。因此,将配置保留在 DISK 中非常重要。

启动过程

如果找到数据库文件(proxysql.db),ProxySQL 将从 proxysql.db 初始化其内存中配置。因此,磁盘被加载到 MEMORY 中,然后加载到 RUNTIME 中。

如果找不到数据库文件(proxysql.db)且存在配置文件(proxysql.cfg),则解析配置文件并将其内容加载到内存数据库中,然后将其保存在 proxysql.db 中并在加载到 RUNTIME。

请务必注意,如果找到 proxysql.db,则不会解析配置文件。也就是说,在正常启动期间,ProxySQL 仅从持久存储的磁盘数据库初始化其内存配置。

配置文件有 4 个变量,即使存在 proxysql.db,也始终会从配置文件里去解析:

1. datadir

定义了 ProxySQL datadir 的路径,其中存储了数据库文件,日志和其他文件。

2. restart_on_missing_heartbeats(1.4.4中的新增内容)

如果 MySQL 线程错过了 restart_on_missing_heartbeats 心跳,则 ProxySQL 将引发 SIGABRT 信号并重新启动。默认值为 10。

详情请见:https://github.com/sysown/proxysql/wiki/Watchdog。

3 .execute_on_exit_failure(1.4.4 中的新增内容)

如果设置,ProxySQL 父进程将在每次 ProxySQL 崩溃时执行定义的脚本。建议使用此设置生成警报或记录事件。

请注意,在崩溃的情况下,ProxySQL 能够在几毫秒内重新启动,因此其他监视工具可能无法检测到正常故障。

4. errorlog(2.0.0中的新增内容):

如果设置,ProxySQL 将使用定义的文件作为错误日志。如果未传递此类变量,则 errolog 将位于 datadir/proxysql.log 中

初始化启动过程(或 --initial)

在初始启动时,将从配置文件中填充内存和运行时配置。此后,配置将保留在ProxySQL 的嵌入式 SQLite 数据库中。

通过使用 --initial 标志运行 ProxySQL 可以强制重新发生初始配置,这会将 SQLite 数据库文件重置为其原始状态(即配置文件中定义的状态)并重命名现有的 SQLite 数据库文件。

如果需要回滚(如果需要,检查已定义的数据目录中的旧文件)。

重新加载启动(或--reload)

如果使用 --reload 标志执行 ProxySQL,它会尝试将配置文件中的配置与数据库文件的内容合并。之后,ProxySQL 将继续启动程序。

如果配置文件和数据库文件的参数存在冲突,则无法保证 ProxySQL 将成功管理合并,用户应始终验证合并结果是否符合预期。

核心配置表

在运行时修改配置是通过 ProxySQL 的 MySQL 管理端口(默认为 6032)完成的。

连接到它后,您将看到一个与 MySQL 兼容的接口,用于查询各种与 ProxySQL 相关的表:

mysql> show tables;
+-------------------+
| tables            |
+-------------------+
| mysql_servers     |
| mysql_users       |
| mysql_query_rules |
| global_variables  |
| mysql_collations  |
| debug_levels      |
+-------------------+

每个这样的表都有明确的定义:

mysql_servers: 包含要连接的 ProxySQL 的后端服务器列表

mysql_users: 包含 ProxySQL 将用于向后端服务器进行身份验证的用户列表

mysql_query_rules: 包含用于缓存,路由或重写发送到 ProxySQL 的SQL查询的规则

global_variables: 包含在服务器初始配置期间定义的 MySQL 变量和管理变量

debug_levels: 仅用于调试 ProxySQL 的手动构建

在不同层级间移动配置信息

为了将配置持久化到磁盘或将配置加载到运行时,可以使用一组不同的管理命令,这些命令可以通过管理界面执行。

一旦理解了三层中的每一层的使用方式,语义都应该清楚。

连同每个命令的说明,每个命令旁边都有一个编号选项。该数字对应于下图中列出的箭头。

要重新配置 MySQL 用户,请执行以下命令之一: [1] LOAD MYSQL USERS FROM MEMORY / LOAD MYSQL USERS TO RUNTIME 将 MySQL 用户从 MEMORY 加载到 RUNTIME 数据结构,反之亦然。 [2] SAVE MYSQL USERS TO MEMORY / SAVE MYSQL USERS FROM RUNTIME 将 MySQL 用户从 RUNTIME 保存到 MEMORY [3] LOAD MYSQL USERS TO MEMORY / LOAD MYSQL USERS FROM DISK 将持久化的 MySQL 用户从磁盘数据库加载到 MEMORY [4] SAVE MYSQL USERS FROM MEMORY / SAVE MYSQL USERS TO DISK 将 MySQL 用户从 MEMORY 中保存到 DISK [5] LOAD MYSQL USERS FROM CONFIG 从配置文件加载用户到 MEMORY

常用的命令参考:

LOAD MYSQL USERS TO RUNTIME;
SAVE MYSQL USERS TO DISK;

LOAD MYSQL SERVERS TO RUNTIME;
SAVE MYSQL SERVERS TO DISK;

LOAD MYSQL QUERY RULES TO RUNTIME;
SAVE MYSQL QUERY RULES TO DISK;

LOAD MYSQL VARIABLES TO RUNTIME;
SAVE MYSQL VARIABLES TO DISK;

LOAD ADMIN VARIABLES TO RUNTIME;
SAVE ADMIN VARIABLES TO DISK;

注意:关键字 MEMORY/RUNTIME 都支持缩写:
MEM for MEMORY
RUN for RUNTIME

故障排除

请注意,只有在将值加载到运行时才会进行最终验证。

可以设置一个值,该值在保存到内存时不会引发任何类型的警告或错误,甚至可以保存到磁盘。

但是,当执行加载到运行时,会自动将更改恢复为先前已经保存的状态。

如果发生这种情况,应该检查定义的错误日志文件:

例如:

[WARNING] Impossible to set variable monitor_read_only_interval with value "0". Resetting to current "1500".    

常用的一些命令技巧

1. 限制 ProxySQL 到后端 MySQL 的连接数通过权重,来控制 ProxySQL 到后端 MySQL 的访问量

权重只作用在同一个 hostgroup 中有效

2. 自动回避复制延迟较大的节点

如果服务器将 max_replication_lag 设置为非零值,则 Monitor 模块会定期检查复制延迟。

下图中,当172.16.0.3的复制延迟超过了30秒会自动回避,设置max_replication_lag = 0,代表不检查复制延迟 。

注意,max_replication_lag主要来源Seconds_Behind_Master,该参数判断延迟准确性不高,顾个人建议为参考功能。

3. Master Slave,将 Master 作为 Slave 的备用读节点

在下面的示例中,如果我们将 HG1 配置为提供读请求,则 99.95% 的请求将发送到 172.16.0.2 和 172.16.0.3,而 0.05% 的请求将正常发送到172.16.0.1。

如果 172.16.0.2 和 172.16.0.3 不可用,172.16.0.1 将获取所有读取请求。

注意:max_replication_lag 仅适用于从节点。如果服务器未启用复制,则 Monitor 不会执行任何操作。

4. 优雅的禁用后端 Server

要正常禁用后端服务器,需要将其状态更改为 OFFLINE_SOFT。

不会影响当前的活动事务和连接,但不会向该节点发送新流量。

5. 立即禁用后端 Server

要立即禁用后端服务器,需要将其状态更改为 OFFLINE_HARD。所有当前请求将立即终止,并且不会发送新请求。

172.18.0.1 设置了OFFLINE_HARD 会立刻中断当前的请求。

6. 重新启用脱机/禁用后端 Server

要在离线后端重新启用,将其状态更改回ONLINE就可以了

7. 删除后端 Server

注意:

在内部,删除后端或将其设置为 OFFLINE_HARD 的方式相同。

当执行 LOAD MYSQL SERVERS TO RUNTIME 时,Hostgroup_Manager 将检测到后端服务器已被删除,并在内部将其标记为 OFFLINE_HARD。

8. 将明文密码转换成Hash密码,配置到ProxySQL中的mysql_users表

mysql_users表,支持明文密码和 Hash 密码的写入,但生产环境,我们还是建议用 Hash 密码。

将明文密码转换Hash密码有两种方式:

1. 通过PASSWORD()

该函数生成 Hash 密码,但该函数 ProxySQL 是不支持的,需要在 MySQL 数据库里自行生成,再粘贴加密后的密码插入到 ProxySQL 中。

2.通过变量:admin-hash_passwords(推荐)

此参数默认开启,明文密码存放到MEMORY的mysql_user中,一旦load到RUNTIME会自动HASH加密。

然后再 SAVE 回 MEMORY/DISK 即可完成明文到 Hash 密码的转换。

9. 限制 User 和 ProxySQL 之间的连接数

10. 同个事务内的 SQL,禁止被路由到不同节点上

启动事务后,可能会根据查询规则将某些查询发送到其他主机组。为了防止这种情况发生,可以开启 transaction_persistent。

The Admin Schemas

ProxySQL 管理界面是一个使用 MySQL 协议的界面,任何能够通过这种界面发送命令的客户端都很容易配置它。

ProxySQL 解析通过此接口发送的查询以查找特定于 ProxySQL 的任何命令,如果适当,则将它们发送到嵌入式 SQLite3 引擎以运行查询。

请注意,SQLite3 和 MySQL 使用的 SQL 语法不同,因此并非所有适用于MySQL 的命令都适用于 SQLite3。例如,尽管管理界面接受 USE 命令,但它不会更改默认架构,因为 SQLite3 中不提供此功能。

连接到 ProxySQL 管理界面时,我们可以看到有一些数据库可用。ProxySQL 将 SHOW DATABASES 命令转换为 SQLite3 的等效命令。

这些数据库的作用如下:

main:内存配置数据库 。 使用此数据库,可以轻松地以自动方式查询和更新 ProxySQL 的配置。 使用 LOAD MYSQL USERS FROM MEMORY 和类似命令,存储在此处的配置可以在运行时传播到 ProxySQL 使用的内存数据结构。 disk:基于磁盘的 “main” 镜像。 在重新启动时,“main” 不会持久存在,并且可以从 “磁盘” 数据库或配置文件中加载,具体取决于启动标志和磁盘数据库的存在。 stats:包含从代理的内部功能收集的运行时指标。 示例度量标准包括每个查询规则匹配的次数,当前运行的查询等。 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当前节点的验证队列,积压事务数

MySQL 5.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 ;

MySQL 8.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 ;

还有很多没有总结,一点点来,基础知识梳理完成,会对核心功能再进行测试说明,希望对需要的同学有帮助。

原文发布于微信公众号 - 运维之美(Hi-Linux)

原文发表时间:2019-07-03

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券