TiProxy 是 TiDB 官方推出的高可用代理组件,旨在替代传统的负载均衡工具如 HAProxy 和 KeepAlived,为 TiDB 提供连接迁移、故障转移、服务发现等核心能力。 本文全面解析了 TiProxy 的设计理念、主要功能及适用场景,并通过实际案例展示了其在扩缩容、故障处理和流量捕捉与回放中的强大能力。
TiDB 是一款典型的分布式存算分离架构的数据库,其中计算层由多个无状态的 TiDB Server 组成,这些 TiDB Server 同时对外承担连接请求。为了可以将连接分发到多个 TiDB Server 节点上,一般需要借助外部负载均衡组件如硬件负载均衡 F5、软件负载均衡 HAProxy 等。
为了实现全链路的高可用架构,我们经常也需要考虑负载均衡组件本身的高可用性,比如通过 KeepAlived 来保证 HAProxy 的高可用。这无疑增加了整体的使用成本,尤其是对于使用最小规模的 TiDB 集群部署已经能够完全承载业务体量的系统而言。
如果用户本身没有现成的负载均衡设备,则必须搭建一套类似 KeepAlived+HAProxy 的高可用负载均衡层,增加了维护的成本, KeepAlived 和 HAProxy 本身也不属于 TiDB 数据库生态的组件,出现问题也只能寻找现网的解决方法。TiProxy 是 TiDB 官方的代理组件,它为 TiDB 提供负载均衡、连接保持、服务发现等功能,是替换开源的 KeepAlived+HAProxy 或其他负载均衡软件有效的方案。
TiProxy 的主要功能包括:连接迁移、故障转移、服务发现和一键部署。
基于上述介绍的 TiProxy 主要能力,我们可以梳理出 TiProxy 比较适用的场景。
需要注意的是,如果系统对交易的 Duration 延迟要求极高,那么 TiProxy 可能不是最优的选择。相比 F5 或 HAProxy 这样的外部负载均衡组件,TiProxy 性能会稍有不足,会一定程度的降低 TPS 或增加交易延迟,这在官网文档中有相关说明。
TiProxy 是 TiDB v8 版本才发布的组件(实际支持 v6.5 及以上 TiDB 版本),对很多 TiDB 用户来说可能还属于一个新鲜的东西。考虑到这是一个新的组件,大部分用户从安全稳定的角度考虑就是否使用 TiProxy 组件还处于一个观望阶段。不过从 TiDB 的产品发布内容来看,从 v8.1 到 v8.5,我们也看到 TiProxy 一直在改进和增强,可以在一些延迟要求不是特别敏感的系统中测试并使用起来。
那么如何在一个 TiDB 集群中使用 TiProxy 呢,以下参考官网文档 TiProxy 简介 ( https://docs.pingcap.com/zh/tidb/stable/tiproxy-overview#安装和使用 ) 做一个简单的示例说明。
1. 升级并检查 tiup 版本
如果 TiUP 版本是 v1.15.0 之前,需要为 TiDB Server 实例生成自签名证书并配置证书的路径,否则将无法使用 TiProxy 的连接迁移功能。鉴于为 tidb server 生成自签名证书步骤比较繁琐,建议直接将 tiup 升级至 v1.15.0 版本或以上,通过以下命令升级及检查 tiup 版本。
tiup update --self
tiup -v | grep tiup
2. 配置 tidb server 的 graceful-wait-before-shutdown
根据官网提示,tidb server 的 graceful-wait-before-shutdown 应大于应用程序最长事务的持续时间,否则 tidb server 下线时客户端可能断连,最长事务持续时间可通过 grafana 监控报表查看确认。
server_configs:
tidb: graceful-wait-before-shutdown: 15
TiProxy 可以部署多个,为了保证 TiProxy 的高可用,一般建议部署两个,通过配置虚拟 IP 将流量路由到 TiProxy 实例上。
1. 准备 TiProxy 部署配置文件 tiproxy.toml
TiProxy 支持一系列参数配置,具体可参考文档 TiProxy 配置文件 ( https://docs.pingcap.com/zh/tidb/stable/tiproxy-configuration ) 。以下是一个最基本的配置文件,它表示在两个节点上分别安装版本为 v1.3.0 的 tiproxy 组件,配置 ha.virtual-ip 及 ha.interface 指定虚拟 IP,用于对外提供连接服务。
component_versions:
tiproxy: "v1.3.0"
server_configs:
tiproxy:
ha.virtual-ip: "10.1.1.200/24"
ha.interface: "eth0"
tiproxy_servers:
- host: 10.1.1.154
- host: 10.1.1.155
2. 安装 TiProxy 组件
如果是首次安装集群,则 TiProxy 可以与集群一同完成安装;如果是在已有集群中增加 TiProxy ,可以通过 tiup scale-out 的方式扩容 TiProxy 组件。
安装或扩容完成后,通过 tiup display 命令可以查看到相应的 tiproxy 组件,其默认的连接端口为 6000。
tiup cluster display tidb-test | grep tiproxy
10.1.1.154:6000 tiproxy 10.1.1.154 6000/3080 linux/aarch64 Up - /data1/tidb-re-deploy/tiproxy-6000
10.1.1.155:6000 tiproxy 10.1.1.155 6000/3080 linux/aarch64 Up - /data1/tidb-re-deploy/tiproxy-6000
3. 验证连接 TiProxy
上述步骤完成后,我们便可以通过连接 TiProxy 地址及端口来验证是否可以正常连接到 tidb。如果配置无误, 无论是通过 <tiproxy_ip>:6000 还是通过 <virtual_ip>:6000,应该都可以正常连接到 TiDB。
如上面内容所述,TiProxy 具有连接迁移的能力,对于计划内的操作如扩缩容、滚动升级、滚动重启,TiProxy 可以保证完全不影响业务。TiProxy 同时也具有服务发现能力,当有计算节点增加或减少时,TiProxy 能自动感知,无须人工介入。我们通过模拟 sysbench 压测,并在压测过程中扩容和缩容计算节点,观察所有计算节点的连接变化以及业务影响情况。
1. 开启 sysbench 压测
使用 100 并发连接开启 sysbench 压力测试,场景为 oltp_read_only。观察各 tidb server 连接数情况,连接数分别为 33/33/34 ,处于相对均衡的状态。
进一步查看运行时 QPS,查询 QPS 约为 27.9K 。
2. 在线扩容一台 tidb server
使用 tiup scale-out 在线扩容一台 tidb server,扩容后 tidb server 从原来的 3 台变成 4 台
tiup cluster scale-out tidb-B ./scale-tidb.yaml
观察扩容过程中 sysbench 压测情况,发现运行平稳无任何报错。通过监控查看运行时 QPS,查询 QPS 约为 30.7 K ,较之前 QPS 有上升的趋势。
观察各 tidb server 连接数情况,连接数分别为 26/26/26/22 ,处于相对均衡的状态,可以看到在运行过程中连接被自动迁移到扩容的 tidb server 节点,无须手工介入。
3. 在线缩容一台 tidb server
使用 tiup scale-in 在线缩容两台 tidb server,缩容后 tidb server 从刚刚的 4 台变成 2 台
tiup cluster scale-in tidb-B -N 10.1.1.153:24000,10.1.1.154:24000
观察扩容过程中 sysbench 压测情况,发现运行平稳无任何报错。通过监控查看运行时 QPS,查询 QPS 约为 21.8K ,较之前 QPS 有明显下降的趋势。
进一步观察各 tidb server 连接数情况,连接数分别为 50/50/0/0 ,说明在运行过程中连接被自动迁移到剩余的 2 台 tidb server 节点,无须手工介入。
通过上述步骤的演示,无论是在线扩容还是缩容,TiProxy 组件可以实现业务完全无感知,TiProxy 能自动识别新增或移除的计算节点,将连接自动均衡到现有的节点上。
TiDB v8.5.0 LTS 版本中增加了 TiProxy 流量捕捉与回放的功能,作为实验特性。流量捕捉和回放适用于在生产环境捕捉流量并在测试环境回放,适用的场景包括:
使用 TiProxy 的流量捕捉回放功能需要使用 tiproxyctl 工具,安装 tiproxyctl 步骤如下,
tiup install tiproxy
ls `tiup --binary tiproxy`ctl
当要在生产环境进行流量捕捉时,使用 tiproxyctl traffic capture 。以下命令表示捕获指定 tiproxy 地址的流量,并保存到 /tmp/traffic 目录下,持续时间为 10 分钟。
tiproxyctl traffic capture --host 10.1.1.200 --port 3080 --output="/tmp/traffic" --duration=10m
捕获的流量将保存在 TiProxy 节点的对应目录下,包含两个文件:meta 和 traffic.log,meta 是流量的元数据信息记录,traffic.log 则保存了具体的业务流量信息。
tree /tmp/traffic/
/tmp/traffic/
├── meta
└── traffic.log
0 directories, 2 files
流量捕捉完成后,使用 tiproxyctl traffic replay 在测试环境中回放流量。以下命令表示在测试环境中从指定位置回放流量,回放速度为 2 倍速生产流量。
tiproxyctl traffic replay --host 10.1.1.200 --port 3080 --username=<uname> --password=<passwd> --input="/tmp/traffic" --speed=2
本文仅对 TiProxy 流量捕捉与回放功能做一个简要的介绍说明,更多细节内容请参考官网 TiProxy 流量回放 ( https://docs.pingcap.com/zh/tidb/stable/tiproxy-traffic-replay )。
本文对 TiDB 的官方代理组件 TiProxy 进行了一个整体的说明与介绍,TiProxy 是 v8 版本开始支持的可以用于代替开源负载均衡工具的一款 TiDB 生态组件。TiProxy 不仅具有连接迁移、故障转移、服务发现和一键部署的能力,在新版本中也支持流量捕捉与回放的功能,是替换开源代理组件的一个极佳方案。引入 TiProxy 在延迟要求极高的场景下可能带来一定的性能损失,建议以具体业务场景中性能测试为准。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。