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_connectionsProxySQL将向此后端服务器打开的最大连接数。即使此服务器具有最高权重,但一旦达到此限制,就不会向其打开新连接。请确保后端配置了正确的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_variablesmysql_collationsscheduler
暂不介绍了,后面会逐步投在功能介绍里提及
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 ;
还有很多没有总结,一点点来,基础知识梳理完成,会对核心功能再进行测试说明,希望对需要的同学有帮助。
来源:cnblogs
原文:http://t.cn/Ai9B8mrV
题图:来自谷歌图片搜索
版权:本文版权归原作者所有
投稿:欢迎投稿,投稿邮箱: editor@hi-linux.com
文末推荐:极客时间视频专栏 「Elasticsearch 核心技术与实战」,一共 95 讲,约 1000 分钟,更多专栏介绍可戳「这里」。如果你想快速构建分布式搜索和分析引擎,这个课程可以帮到你,该专栏刚上架已经有 8000+ 名同学在学习了。
公众号额外福利:通过下面海报订阅专栏的读者,公众号再返 24 元红包。到手相当于 75 元,非常划算。(购买后,加我微信返现,还没加我微信的可戳「这里」找到我哟~)。
👇 优惠仅剩最后 3 天,抓紧时间订购吧
△ 扫码试读或订阅
推荐阅读
文章转载自公众号:运维之美