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

一、TiDB4PG的诞生
在去年的时候，我们开启了一个小项目，基于国内比较火的开源分布式数据库TiDB进行改造。TiDB本身是高度兼容MySQL协议，你可以在使用TiDB的时候将其视作MySQL，基本的语法，功能，包括一些MySQL的生态工具都可以直接使用。所以我们想将一些企业应用搬迁到TiDB上享受分布式数据库带来的优势，但是企业级的应用下层数据库不仅仅只有MySQL，还有PgSQL和Oracle等其他数据库，这使得迁移工作量十分庞大。为此我们更希望TiDB也能够兼容其他的常用数据库协议，例如PgSQL，于是我们创建了 TiDB4PG 的开源项目。
TiDB for PostgreSQL 是我们基于 TiDB 源码修改的一款满足 PostgreSQL 协议的数据库。为了让基于 PostgreSQL 的系统能够在不修改本身业务代码的前提下，快速的迁移到分布式数据库上。
关于TiDB4PG的详细背景文章可翻阅 https://zhuanlan.zhihu.com/p/...
二、升级过程
TiDB4PG 最初开始做的时候，选择的是当时比较新的版本4.0.11，也是我们用的比较稳定的一版。但是万万没想到，TiDB版本迭代速度，远超乎我们的想象，一年不到，TiDB版本就给推到5.3了。在5.3的版本，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的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 从v4.0.11 升级到 v5.3.0 一共有两个方面提升，功能和性能，简单列举一下TiDB4PG v5.3.0 较 4.0.11提升的几点：

读写性能有 20% - 40% 的提高。
对公共表达式的支持（CTE）。
对于其他排序规则的支持，5.x后的版本对于排序规则的支持更多了。
对于临时表的支持，之前解决方法就是单纯的创建一个实体表存放数据，最后删掉。
表达式索引，虽然目前支持的比较简单，但有总比没有好！
除此之外还有一些其他的细节提升，这里不做一一列举，可以查阅TiDB官方文档来了解TiDB 5.3.0的版本细节。
最后TiDB4PG 对于TiDB的支持总算是升级到5.3，但是TiDB版本又升级到了5.4，很难说再过个多少天6.0的版本突然就发布了，所以我们也是经常讨论，这次升级完了，下一次怎么办？随着TiDB4PG分支和TiDB主支的差异越来越大，每一次合并升级都是一件十分痛苦的事情。所以我们还是希望能够再找一个更好的方法来实现升级。 当然升级也并不都是痛苦的事情，升级完成之后，看到新的功能和性能，还是十分开心的，毕竟TiDB自己的功能越丰富，我们兼容路上的坑就会少很多。所以还是很期待TiDB能够一路高歌猛进，有着更加强大的功能和性能。
TiDB4PG：DigitalChinaOpenSource/TiDB-for-PostgreSQL: PgSQL compatible on distributed database TiDB (github.com)