TiDB4PG | 与 TiDB 共舞，一次“亦步亦趋”的升级

TiDB4PG 的诞生

去年我们启动了一个小项目—— 基于国内比较火的开源分布式数据库 TiDB 进行改造。

TiDB 的兼容难题

TiDB 高度兼容 MySQL 协议，你可以在使用 TiDB 的时候将其视作 MySQL，基本的语法，功能，包括一些 MySQL 的生态工具都可以直接使用。

我们想将一些企业应用搬迁到 TiDB 上充分享受分布式数据库带来的优势，但是企业级的应用下层数据库 不仅仅只有MySQL，还有 PgSQL 和 Oracle 等其他数据库，这使得 迁移工作量十分庞大。

为此我们更 希望 TiDB 也 能够兼容其他的常用数据库协议，例如 PgSQL，于是我们团队 创建了 TiDB4PG 的开源项目。

TiDB 的版本升级问题

TiDB4PG 研发之初，选择 TiDB 的版本是当时比较新的 4.0.11，也是我们用的比较稳定的一版。

但是万万没想到，TiDB 版本迭代速度，远超乎我们的想象，一年不到，TiDB 版本就给推到 5.3 了。

在多方面的考虑下， 我们决定将 TiDB4PG 中的 TiDB 版本升级到 5.3

升级方案选定

高耦合

带来的升级难题

TiDB4PG 最早在改代码的时候就考虑过升级的问题。

项目是基于 TiDB 对于 PgSQL 的协议兼容的开发， 对于 TiDB 本身代码的入侵是非常大的，整个协议层都得替换掉，Session 这一块做的改动较多，同时也会影响到计划的构造和执行。

主要还是 数据库系统本身的耦合十分的高，整个改动下来，并不是写几个包去替换一下就能解决的，所以被我们修改后的分支，再想要去把 TiDB 主分支合过来，是十分困难的。

当然，我也是尝试了一下，强行将 5.3 的代码 Merge 到 TiDB4PG，从下面图中可以看到，有 2959 个文件的更改，其中存在冲突的文件有 上百个，这要 一个一个修复起来，工作量可以说是非常的大。

/ 强行 Merge 后的巨大冲突

一个更简单 的

升级方案

在权衡一段时间后，我们最终决定用一个更为简单的方法来实现这一次的升级，那就是 在 TiDB 5.3.0 版本代码上将我们 TiDB4PG 实现的代码再重新实现一次。

这种方法的工作量就大大减小了

一是因为TiDB4PG 中改动的代码都是一块一块的， 可以直接复制搬运过去使用。

二是因为TiDB 代码虽然迭代快，经常重构，但就协议和较上层的代码改动要少很多，所以 搬运时， 简单看一下搬运位置的代码改动，解决冲突就可以成功跑通。

并且这一次升级，我们 把和 PgSQL 相关的代码都抽出来做了单独的文件进行存放，方便后期代码的学习和维护。

/ 与 PgSQL 相关的代码

性能测试

测试目的

对于升级之后的 TiDB4PG 5.3.0 版本，我们做了相关的性能对比测试：

将TiDB 4.0.11，TiDB4PG 4.0.11，TiDB 5.3.0 和 TiDB4PG 5.3.0 四个版本再统一的集群配置与硬件环境进行 Sysbench 压测。

主要目的仍然是：

确保升级之后的 TiDB4PG 在性能上与 TiDB 5.3.0 保持一致。

同时也顺带测试 TiDB 5.3.0 版本对比 4.0.11 版本 性能有多少的提升。

测试结果

我们拿了 read, insert 和 update 包含读写的三种脚本简单的跑了四个版本的性能压测对比。

/ 性能压测对比结果

颜色对应 TiDB 4.0.11(蓝色)， TiDB 5.3.0(绿色)， TiDB4PG 4.0.11(黄色)， TiDB4PG 5.3.0(红色)。

当然这个对比不是为了测试几个版本的性能极限等， 重点是测试性能的对比和相对的提升，所以具体的 QPS 和 TPS 数据不具有任何意义。

通过对比图，能够很清晰的看出来:

• 5.3.0 版本整体较 4.0.11 的 性能提升有 20%-40%

• 并且 TiDB 和 TiDB4PG 在相同版本下 性能都是差不多的，所以兼容的代码改动对于性能上几乎没有影响。

数据迁移

升级后的

数据迁移问题

完成了 TiDB4PG 4.0.11 到 5.3.0 版本的升级，就存在一个问题：

之前集群的数据，如何完全迁移到 5.3.0 版本的集群中？

首先需要明确一点的是 TiDB 的整体架构，一共是 有三个主要组件：

• TiDB-Server

• PD-Server

• TiKV-Server

而 TiDB4PG 的改造 仅仅只修改了 TiDB-Server 的代码逻辑，也就是 SQL 处理层逻辑。

那么最重要的点在于，大家都了解 TiDB-Server 是无状态的， 同理，TiDB4PG-Server 本身也是无状态的。

根据这一点，在 TiDB4PG 的集群中， TiDB-Server 和 TiDB4PG-Server 是可以共存的，你既可以使用 TiDB4PG 的 PG 协议和处理层支持，同样也可以使用 TiDB 的 MySQL 协议层。

/ 两者共存

所以在数据迁移和备份的策略中，你 可以使用 TiDB 原本就支持的逻辑备份工具和物理备份工具。

例如

• Dumpling & Lightning

• Backuo & Restore

这两个工具是通过测试验证的，但是 建议使用逻辑备份，因为在测试 BR 的过程中，我们遇到了版本问题，需要先用 BR v4.0 备份 4.0.11 的集群，再用 BR v5.0 恢复到 5.3 的集群中，操作比较复杂。

通过我们的迁移经验，也如上面的分析所言， TiDB4PG 集群从某种意义上同样是一个 TiDB 集群， 如果在 TiDB4PG 集群中启动一个 TiDB-Server 节点，就可以兼容很多 TiDB 生态工具。

甚至如果某些生态工具是 直接跳过 TiDB-Server，访问PD-Server 或者 TiKV-Server，那么 理论上都是可以直接使用的。所以像 DM，Binlog 和 TiCDC 这一类工具都是可以在TiDB4PG集群中使用的，当然这些目前还没有进行实际测试。

升级后的TiDB4PG

通过升级，TiDB4PG 从 v4.0.11 升级到 v5.3.0 整体上 在功能和性能上都有较大的提升，主要有以下几点：

• 读写性能有 20% ~ 40% 的提高。

• 对 公共表达式的支持（CTE）。

• 对于 其他排序规则的支持，5.x 后的版本对于排序规则的支持更多了。

• 对于 临时表的支持，之前解决方法就是单纯的创建一个实体表存放数据，最后删掉。

• 表达式索引，虽然目前支持的比较简单，但有总比没有好！

除此之外还有一些其他的细节提升，这里不做一一列举，可以 查阅 TiDB 官方文档来了解TiDB 5.3.0的版本细节。

TiDB4PG 对于 TiDB 的支持成功升级到 5.3，刚升级完一天不到，TiDB 推出了 5.4 版本。

很难说再过个多少天 6.0 的版本突然就发布了，所以我们也是经常讨论和思考， 这次升级完了，下一次怎么办？

随着 TiDB4PG 分支和 TiDB 主支的差异越来越大，每一次合并升级都是一件十分痛苦的事情。

我们还在不断探索，能够再找一个更好的方法来实现 TiDB4PG 的升级。

当然升级也并不完全都是痛苦，升级完成之后，看到新的功能和性能，还是十分开心的， TiDB 自己的功能越丰富，我们兼容路上的坑就会少很多。

所以还是很期待 TiDB 有着更加强大的功能和性能，与此同时， 我们也会不断升级TiDB4PG，与 TIDB 一起高歌猛进！