前言

TiDB 是一款典型的分布式存算分离架构的数据库，其中计算层由多个无状态的 TiDB Server 组成，这些 TiDB Server 同时对外承担连接请求。为了可以将连接分发到多个 TiDB Server 节点上，一般需要借助外部负载均衡组件如硬件负载均衡 F5、软件负载均衡 HAProxy 等。

为了实现全链路的高可用架构，我们经常也需要考虑负载均衡组件本身的高可用性，比如通过 KeepAlived 来保证 HAProxy 的高可用。这无疑增加了整体的使用成本，尤其是对于使用最小规模的 TiDB 集群部署已经能够完全承载业务体量的系统而言。

什么是 TiProxy

如果用户本身没有现成的负载均衡设备，则必须搭建一套类似 KeepAlived+HAProxy 的高可用负载均衡层，增加了维护的成本, KeepAlived 和 HAProxy 本身也不属于 TiDB 数据库生态的组件，出现问题也只能寻找现网的解决方法。TiProxy 是 TiDB 官方的代理组件，它为 TiDB 提供负载均衡、连接保持、服务发现等功能，是替换开源的 KeepAlived+HAProxy 或其他负载均衡软件有效的方案。

TiProxy 的主要能力

TiProxy 的主要功能包括：连接迁移、故障转移、服务发现和一键部署。

连接迁移。连接迁移就是说可以把客户端连接从 A 计算节点迁移到 B 计算节点而不影响业务。这种通常在扩缩容、滚动升级、滚动重启场景使用，是一种计划内的动作，如果是计算节点异常下线这种情况，则不属于连接迁移的范畴。
故障转移。故障转移就是说当发现有计算节点故障的时候，比如 OOM 或是发现与 PD/TiKV 组件无法连接时，TiProxy 可以发现故障并将连接转移到正常的计算节点上。
服务发现。使用外部的负载均衡组件时无法自动感知到有计算节点变化的情况，比如对计算节点做了扩缩容，而使用 TiProxy 就能自动的发现新增/删除的计算节点，不需要人工介入。
一键部署。TiProxy 被集成到 TiUP、TiOperator 管理工具中，可通过 tiup 命令直接扩容的方式安装即可，不需要单独下载并单独安装。

TiProxy 的适用场景

基于上述介绍的 TiProxy 主要能力，我们可以梳理出 TiProxy 比较适用的场景。

可用性要求高的业务。有些业务系统通常要求 7*24 对外提供服务，这些系统对可用性要求极高，比如要满足 4 个 9 或 5 个 9 之类的不停机时间。然而系统在长时间运行的环境中，无法避免因为业务变更或程序漏洞需要进行计划性的调整，这就要求数据库能够支持不影响业务的前提下进行在线重启、升级等操作。使用 TiProxy 的连接迁移功能结合 TiDB 数据库的滚动重启功能可以完美的解决这一场景。
敏态类的业务。某些业务系统可能在大部分的时间段业务都处于低峰期，但在某些时间段内业务会比平时增加 10 倍或者更多，比如电商促销活动期间。这要求数据库在短时间内能够支持快速的扩缩容操作，以应对高峰时段的业务负载。TiProxy 也非常适合这样的场景，可以保证在扩缩容操作过程中对业务无影响。
提前规避系统风险。分布式系统由多个节点组成，每个节点都对外提供服务。无论是因为业务自身的原因，还是因为数据库内部机制，节点之间出现不均衡的状态是无法避免的。通过监控节点的均衡状态，我们可以提前发现可能存在 CPU 或内存资源严重不均的情况，结合 TiProxy，将异常节点的连接提前转移到正常节点，并在恢复之后再将连接均衡回来。

需要注意的是，如果系统对交易的 Duration 延迟要求极高，那么 TiProxy 可能不是最优的选择。相比 F5 或 HAProxy 这样的外部负载均衡组件，TiProxy 性能会稍有不足，会一定程度的降低 TPS 或增加交易延迟，这在官网文档中有相关说明。

安装并体验 TiProxy

TiProxy 是 TiDB v8 版本才发布的组件（实际支持 v6.5 及以上 TiDB 版本），对很多 TiDB 用户来说可能还属于一个新鲜的东西。考虑到这是一个新的组件，大部分用户从安全稳定的角度考虑就是否使用 TiProxy 组件还处于一个观望阶段。不过从 TiDB 的产品发布内容来看，从 v8.1 到 v8.5，我们也看到 TiProxy 一直在改进和增强，可以在一些延迟要求不是特别敏感的系统中测试并使用起来。

那么如何在一个 TiDB 集群中使用 TiProxy 呢，以下参考官网文档 TiProxy 简介做一个简单的示例说明。

TiDB Server 实例配置

升级并检查 tiup 版本

如果 TiUP 版本是 v1.15.0 之前，需要为 TiDB Server 实例生成自签名证书并配置证书的路径，否则将无法使用 TiProxy 的连接迁移功能。鉴于为 tidb server 生成自签名证书步骤比较繁琐，建议直接将 tiup 升级至 v1.15.0 版本或以上，通过以下命令升级及检查 tiup 版本。

tiup update --self
tiup -v | grep tiup

配置 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 可以部署多个，为了保证 TiProxy 的高可用，一般建议部署两个，通过配置虚拟 IP 将流量路由到 TiProxy 实例上。

准备 TiProxy 部署配置文件 tiproxy.toml

TiProxy 支持一系列参数配置，具体可参考文档 TiProxy 配置文件。以下是一个最基本的配置文件，它表示在两个节点上分别安装版本为 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

安装 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

验证连接 TiProxy

上述步骤完成后，我们便可以通过连接 TiProxy 地址及端口来验证是否可以正常连接到 tidb。如果配置无误，无论是通过 <tiproxy_ip>:6000 还是通过 <virtual_ip>:6000，应该都可以正常连接到 tidb。

体验 TiProxy 连接迁移

如上面内容所述，TiProxy 具有连接迁移的能力，对于计划内的操作如扩缩容、滚动升级、滚动重启，TiProxy 可以保证完全不影响业务。TiProxy 同时也具有服务发现能力，当有计算节点增加或减少时，TiProxy 能自动感知，无须人工介入。我们通过模拟 sysbench 压测，并在压测过程中扩容和缩容计算节点，观察所有计算节点的连接变化以及业务影响情况。

开启 sysbench 压测

使用 100 并发连接开启 sysbench 压力测试，场景为 oltp_read_only。观察各 tidb server 连接数情况，连接数分别为 33/33/34，处于相对均衡的状态。

进一步查看运行时 QPS，查询 QPS 约为 27.9K。

在线扩容一台 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 节点，无须手工介入。

在线缩容一台 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 能自动识别新增或移除的计算节点，将连接自动均衡到现有的节点上。

TiProxy 新特性体验：流量捕捉与回放

TiDB v8.5.0 LTS 版本中增加了 TiProxy 流量捕捉与回放的功能，作为实验特性。流量捕捉和回放适用于在生产环境捕捉流量并在测试环境回放，适用的场景包括：

数据库版本升级前验证。比如某套业务生产环境的 TiDB 版本要进行升级，可以通过在现有生产环境捕捉一定时间段的流量并在测试环境新版本中进行回放验证，判断新版本中业务是否能平稳运行。
业务改造或应用打版验证。有时候应用可能也会进行打版或升级，可能是因为业务需求的变化，如果直接在生产环境操作存在一定的风险，可以用生产的流量在测试环境中进行回放验证。
扩缩容及业务上限评估。有些生产环境数据库可能长期处于高压状态，需要通过扩容来满足业务需求；也有些生产环境数据库资源使用率极低，资源存在浪费的情况，可以适当缩容一些节点出来。使用 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 流量回放。

总结

本文对 TiDB 的官方代理组件 TiProxy 进行了一个整体的说明与介绍，TiProxy 是 v8 版本开始支持的可以用于代替开源负载均衡工具的一款 TiDB 生态组件。TiProxy 不仅具有连接迁移、故障转移、服务发现和一键部署的能力，在新版本中也支持流量捕捉与回放的功能，是替换开源代理组件的一个极佳方案。引入 TiProxy 在延迟要求极高的场景下可能带来一定的性能损失，建议以具体业务场景中性能测试为准。

一文了解 TiDB 官方代理组件 TiProxy

前言