TiDB4PG 中 TiDB 版本升级至 v5.3.0

2022 年 7 月 11 日
本文字数：2293 字
阅读完需：约 8 分钟

作者： pupillord 原文来源：https://tidb.net/blog/302e9454

一、前言

TiDB4PG 最初开始做的时候，选择的是当时比较新的版本 4.0.11，也是我们用的比较稳定的一版。但是万万没想到，TiDB 版本迭代速度，远超乎我们的想象，一年不到，TiDB 版本就给推到 5.3 了。在 5.3 的版本，TiDB 本身的性能和功能都有一定的提升。

其中我们需要的几个功能在 5.3 上面都有相应的支持：

对公共表达式的支持（CTE），这个是我们在兼容过程中非常头疼的，虽然可以通过改写 SQL 来兼容应用，但是有 CTE 还是方便太多了。
对于其他排序规则的支持，5.x 后的版本对于排序规则的支持更多了，应用兼容的路上又少了一块硬石头。
对于临时表的支持，之前解决方法就是单纯的创建一个实体表存放数据，最后删掉。
表达式索引，这个虽然 TiDB 目前支持的比较简单，但有总比没有好！

除此之外，性能的提升也是比较关注的一点，所以多方面的考虑下，我们决定将 TiDB4PG 中的 TiDB 版本升级到 5.3（刚升级完一天不到，TiDB 推出了 5.4 版本，喜忧参半）。

二、升级

最早在改代码的时候就考虑过升级的问题，基于 TiDB 对于 PgSQL 的协议兼容的开发，对于 TiDB 本身代码的入侵是非常大的，整个协议层都得替换掉，Session 这一块做的改动较多，同时也会影响到计划的构造和执行。主要还是数据库系统本身的耦合十分的高，整个改动下来，并不是写几个包去替换一下就能解决的，所以被我们修改后的分支，再想要去把 TiDB 主分支合过来，是十分困难的。

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

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

这种方法的工作量就大大减小了，一是因为 TiDB4PG 中改动的代码都是一块一块的，可以直接复制搬运过去使用。二是 TiDB 代码虽然迭代快，经常重构，但就协议和较上层的代码改动要少很多，所以搬运时，简单看一下搬运位置的代码改动，解决冲突就可以成功跑通。

并且这一次升级，我们把和 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 的 PGSQL 协议和处理层支持，同样也可以使用 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 对于 TiDB 的支持总算是升级到 5.3，但是 TiDB 又升级到了 5.4，很难说再过个多少天 6.0 的版本突然就发布了，所以我们也是经常讨论，这次升级完了，下一次怎么办？随着 TiDB4PG 分支和 TiDB 主支的差异越来越大，每一次合并升级都是一件十分痛苦的事情。所以我们还是希望能够再找一个更好的方法来实现升级。

当然升级也并不都是痛苦的事情，升级完成之后，看到新的功能和性能，还是十分开心的，毕竟 TiDB 自己的功能越丰富，我们兼容路上的坑就会少很多。所以还是很期待 TiDB 能够一路高歌猛进，有着更加强大的功能和性能。