MySQL-ProxySQL中介软件
ProxySQL
ProxySQL作为一款强大的中介软件为MySQL的架构提供了有力的支援。目前可以很好的支援 Master Slave MGR PXC等,并提供连线池、读写分离、日志记录等功能,当然还有很多其他实用功能,这里不一一列举了。本文都是基础概念,基本出自官方文件,官方已经解释的非常清晰,我就不太多加工,汇总一些实用的分享给大家。安装
ProxySQL安装非常简单
连线ProxySQL
ProxySQL预设管理埠6032,预设需要127.0.0.1来进入,进入方式和连线MySQL方式一致:

ProxySQL 执行机制
RUNTIMERUNTIME表示处理请求的执行绪使用的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
