TiDB4PG 升级至 v5.3.0 版本的过程

一、前言

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 能够一路高歌猛进，有着更加强大的功能和性能。

附录

关于 TiDB4PG：专栏 - 【优质技术文章推荐】TiDB for ***—牛刀小试 | TiDB 社区

Github：DigitalChinaOpenSource/TiDB-for-***: PgSQL compatible on distributed database TiDB (github.com)