2
3
1
0
专栏/.../

TiDB4PG 中 TiDB 版本升级至 v5.3.0

 pupillord  发表于  2022-03-10

一、前言

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

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

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

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

二、升级

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

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

image.png

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

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

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

image.png

三、测试

对于升级之后的 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 版本性能有多少的提升。

image.png

我们拿了 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 协议层。

image.png

所以在数据迁移和备份的策略中,你可以使用 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 PostgreSQL—牛刀小试 | TiDB 社区

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

2
3
1
0

版权声明:本文为 TiDB 社区用户原创文章,遵循 CC BY-NC-SA 4.0 版权协议,转载请附上原文出处链接和本声明。

评论
暂无评论