OneProxy :: 简化集群配置,适配MHA / MGR / Galera / Aurora / PolarDB等架构

从2016年开始,MySQL数据库正式在非互联网企业里多处落地,极大地推动了MySQL自身的发展,也推动了MySQL高可用/集群方面的技术发展,从早期清一色的MHA,到MySQL Group Replication、 Galera Cluster、 Amazon Aurora、 Aliyun POLARDB等,逐步解决了底层的事务性能、数据保护、流量分摊(单点)、故障快速切换等基础层面的核心问题。可以说让应用回归到单数据库时代的研发的感受,条件已经基本具备,实际上技术本质已经极其不同,可以让更多的企业和行业开始低成本享受先进的互联网架构。

一款优秀的数据访问层,比如OneProxy,可以进一步提升研发和运维的感受。在真实的来务场景中,OneProxy可以紧密配上述所有的数据库架构,来让运维和研发受益。从系统运行维护角度可以得到以下好处:

  • 解决连接数的问题,不管是在公有云还是在私有云,如果是直连数据库,后端都还不能提供不限的连接数,无法承受的短连接冲击。而数据访问层,可以让你不用规划应用连接池,实现无限连接能力。
  • 解决故障切换关题,OneProxy中间层可以数十毫秒级的频率感知后端数据库的状态,实现故障的及时隔离和切换。比如MGR / Aurora / POLARDB等后端切主了,OneProxy可以极速感知到,无须人工干预,无须运行维维人员下发命令。故障切换时间越快,应用感知越少,业务麻烦也减少。
  • 更智能的流量策略,可以实现一致性读的基础上提供流量均衡,可以根据后端的负载情况实时调整不同节点的流量,而要在其他层面实现这样的需求会十分复杂和困难。
  • 提供丰富性能信息,可以根据多个维度统计真实的性能信息,帮助运行维护人员深入了解SQL、事务、应用等;也能提供更多的手段(Query Cache,动态加减节点等)来应对临时意外情况。

而对研发人员来讲,可以更加专注于业务的研发,可以无须考虑系统运行维护方面(无法忽视)的需求,其中感受极深的有三条:

  • 降低研发的复杂度,不需要每个研发都深入了解后端,又没有忽略运行维护方面的需求,更宜达成系统架构的理解一致性。
  • 单一数据源管理,不管是流量均衡也好,还是分库分表也好,通过OneProxy应用只需要管理一个数据来源,极度地简化了配置信息,也可以说是前面一条的具体体现。
  • 简化连接池配置,让应用的弹性扩容少了一点限制,否则需要仔细考虑数据库层的物理连接数限制。在我的印象中,为此事和应用打过不少交道,花费不少口舌(在公有云上估计这个问题会比较突出)。

这里还不用去说复杂的Sharding情况,就已经有这么多的好处了。而OneProxy中间层的配置和管理方面,为前面的各种不同的数据架构,做了针对性的优化,仅需如下几个参数就可以适应前面所列的不同数据库架构了:

[oneproxy]
proxy-auto-readonly        = 1

proxy-slave-addresses.1    = 192.168.1.120:3306@default
# proxy-slave-addresses.2  = 192.168.1.119:3306@default
# proxy-slave-addresses.3  = ...

proxy-group-policy         = default:read_balance

proxy-user-list            = test/1378F6CC3A8E8A43CA388193FBED5405982FBBD3@test

-- for multi-nodes oneproxy cluster only
remote-address.1           = <cluster node address>:port

为了准确检测读节点的复制时延,OneProxy需要在探针用户(通常是配置的第一个用户)下创建一张表(如果有权限,会自动创建,否则需要手工创建),以便OneProxy可以往Master节点定时更新时间点,表结构如下所示:

CREATE TABLE `oneproxy_replication_timestamp` (
  `proxy_uuid` varchar(64) NOT NULL,
  `proxy_stamp` bigint(20) DEFAULT NULL,
  PRIMARY KEY (`proxy_uuid`)
) ENGINE=InnoDB;

探针用户(用来检测后端MySQL节点状态的Ping用户)的用户名可以从OneProxy的起动日志中找到,如下所示:

...... Ping backend (blog@127.0.0.1:3306) success, mark it up!

在各家不同的云上,都是同样的配置,不需要针对特别的云做特别的配置,或编写针对性的脚本,我们在这里已经做了统筹考虑了。接下来的事情就采用客户端的Load Balance机制或其他的类似服务,让应用连接到多个OneProxy就行了。