PostgreSQL 迁移到 PolarDB 2万5千里长征，太难了，太难了（今天DISS阿里云某部门）

最新推荐文章于 2025-12-03 22:56:48 发布

原创最新推荐文章于 2025-12-03 22:56:48 发布 · 1k 阅读

CC 4.0 BY-SA版权

文章标签：

❝
开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共3300人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 +9）(1 2 3 4 5 6 7群均已爆满，开8群近400 9群 200+，开10群PolarDB专业学习群100+)

上期说了一个流水账的PolarDB for PG 的迁移过程，以及注意事项，这期我们来说说一个有血有肉的，有温度，特别真实的迁移过程，可能会溅你一脸血的那种，今天又要DISS那个部门，咱们细说。

故事从何说起，先说为什么会开始谋划迁移，我和阿里云开会经常挂嘴上一句话，不提业务的数据库技术，就是耍流氓。是的迁移和业务有着紧密的关系，主要围绕着几个点。

1 故障率

2 故障恢复速度

3 降低业务开发难度

4 稳定性与成本

作为技术人员，一定会想着新数据库产品故障率如何，故障的恢复速度如何，同时对于业务开发有没有影响，最后考虑的才是成本。

实际上更换一个数据库产品，大多是第四点，成本，当下的经济环境让真正参与市场的企业，更换数据库的最大动力就是，成本。

此次的迁移就发生在第四点，当一个企业的运营者，获知更换一个数据库后，能为企业节省7位数的成本后，他是无法控制的不去推动更换这个数据库，此时什么开发，架构，DBA，都是蛆虫一样的存在，管理者要的就是在当下卷的要死的环境中，降低成本，卷死对手，让自己处于行业的领先地位。

DBA TEAM在提出PolarDB for PG这个数据库有价值的调研和研究是在2023年，我们当时对于PolarDB FOR PG是带有研究性的，我们当时也出了相关的报告。但各种原因，天时地利人和，全部都有问题，所以无法有效的推动迁移的计划，其实根本的问题是，成本这个话题我们没有深入研究，导致领导根本提不起兴趣听你唠叨，PolarDB的好。

同时当时的PolarDB for PG,也没有宣传现在的POLARDB 提供那个特别诱人，让人无法拒绝的“成本因素”。

直到今年上半年3月份，我们提出成本的因素后，潘多拉的魔盒打开了，在诱惑足够的情况下，开启了POC的测试。

然后用了差不多6个月来进行各种POC测试，这里包含业务的测试，压力测试，数据部门的测试，以及分析功能点等等。我们详细的测试了不少功能和稳定性，因为替换必然带来挑剔的眼光，鸡蛋里面挑骨头谁不会，所以我们的测试尽量要尽善尽美。

本周正式迁移了一台大库下来，的确这个鸡蛋里面没有大骨头，但是有没有小骨头，今天来说说，这才是开始见血的地方。

1 PolarDB for PG的周边部门不给力，这里不拉不踩，阿里云的监控部门，以及DTS部门是整体在迁移中我们，希望能进步的地方。迁移中我们发现存在诸多的问题，和后续需要解决的维内托。

问题：监控的指标不齐的问题（在2025年10月27日基本都解决了），监控的指标应该和阿里云的RDS的产品的监控拉齐，因为一部分客户是从RDS来的，那么必然在系统设计和监控上都希望能沿用之前RDS PG的那套，数据库量太多，修改的部分太多，工作量就会加大，出错的地方就会更多，产品经理应该想到这个部分。

DTS 迁移的过程中，我们的一键迁移的容错性，以及一些设置过于死板，无法灵活修改过滤的问题，我们也都提出来，对于一键迁移中的问题我们也都一一指出，一键迁移考虑的事中小型的客户的迁移，对于大型企业的数据库复杂性，还有很多情况可以考虑，很多的需求还需要斟酌，还有不少可以提高的部分。

比如DTS在数据校验中崩溃的问题，以及迁移中对源库的影响的问题，厂商和客户经验还需要更丰富，作为客户的我们还需要更多积累经验。

这里我举一个特别真实的例子，在数据进行迁移的过程中，客户提出的DDL的操作，并不能良好的支持。这是DTS系统的问题，我们举一个例子，一个大型的客户，他某个系统有几十个数据库实例，几百个逻辑库，几十万张表，而这些系统只为一个业务服务。那么同样的DDL 就会涉及几百次，上千次，但必须一次做完，而业务服务不同客户，不同库的同样的表，字段并不唯一，而如果要统一，就必须写函数在函数里面加入DDL 来进行批量的库的刷表。

这就产生问题了，DTS不认这个DDL ，DDL后，这些信息无法带入到迁移的POLARDB中。

针对这个问题，目前的方案是，只能停止业务的升级，禁止DDL的操作，而公司业务要运转，必须要升级，这是矛盾其一，业务部门对此表示理解，但并不认同，要DBA和阿里云来沟通，解决这个问题。

而这个问题的深层及在于我们在迁移中，并未考虑迁移的速度问题，因为之前使用DTS是可以调整速率的，而此次进行迁移，RDS PG的数据库的IOPS 无法支持DTS的抽取，导致业务库IOPS 100%，影响业务的正常运行，而我们做出了限流的决定。

限流后，又导致整体全量的时间很长，3天进行全量的数据传输，这还不包括增量的时间，对业务的升级影响较大。

这里总结，经验不丰富的原因，后面在此次迁移中我们也沟通了后续我们应该怎么去做，首先要提升磁盘的性能，需要我们针对RDS产品进行磁盘的升级，那么阿里云在给出这个方案后，我们否定这个方案，在企业里面当DBA负责人是要承担责任的，你能保证迁移成功，你能保证不回滚，你单纯升级磁盘了，如果迁移失败，我们回到RDS产品而磁盘无法降级了，带来的就是高昂且无法承受的成本。所以我们采用了第二个方法，升级配置，也就是升级RDS 数据库配置，也会连带提升 IOPS的能力，但这里对企业是灵活的，可以操作的。

延迟监控图的缺失，在RDS PG有复制槽延迟的监控图，而在POLARDB FOR PG好像我们没有找到，而逻辑复制槽就是我们第二个问题，很担心。（这个问题已经解决）

为了这个问题，我们和阿里云PolarDB的小伙伴们，费尽心机。为什么，因为把一键迁移的功能想简单了，做数据库产品都知道，技术人员没有业务的经验，而业务的不同导致数据库的产品需求花样百出，矛盾必然产生。

一键迁移中的考虑是，RDS PG >>> PolarDB PG 在复制过程中，POLARDB FOR PG是只读状态。这是为了保证不出现，错误数据写入到POLARDB 导致复制错误的问题，也就是保证单向写的初衷，出发点很好。

但，但，但，业务是复杂的，逻辑业务槽和发布是需要提前在切换前进行操作的，也就是一键迁移这个产品没有考虑到，客户的实际需求，客户需要在同一个时间，两边的数据库同时开启逻辑复制槽，且同时往大数据同步数据，大数据在剥离重复数据，为业务在最后一刻切换数据库后，达到无感平移的水平，大数据能持续得到数据流而做准备。

所以到此一键迁移得的问题出来了，不合适，不配套，要阿里云的同学来手工给我们做一些工作。这样整体的迁移的速度，沟通的效率，以及诸如此类的，都会变慢。因为一个数据库的迁移，变成两个单位，很多人之间的沟通工作。

迁移的进度必然变慢，就此一点，我们核算，按照原计划至少速度会慢20%以上。因为太多的事情都是需要阿里云来负责，这里感谢阿里云的路老师，耿老师的大力协助。同时我们也希望，阿里云的其他的协作部门的老师，能在这部分给PolarDB for PG一定的技术倾斜，一个好的数据库产品不光是数据库本身的作为，那是周边方方面面上上下下的通力协作得来的。

到这里各种问题到此为止了吗？没有，各种数据库的extension的个性化，在数据库复制中报错，需要人工处理，各种不符合DTS的无主键的表，阻碍着复制一次又一次，导致复制经常中断。

这里有人会说，你们为什么不给所有的表添加主键，是的这是一个好问题，为什么，因为那些就不是业务表，那些是临时表，因业务的临时驻留的表，过后会清理掉,那些都是业务撰写的表，而这些表都没有主键，而为了迁移让业务改造代码，有经验的DBA都知道，这并不容易，这又牵扯开发成本的问题。

这项问题导致迁移的进度在慢20%。说到这里还的说到DTS，听说DTS整体架构要改，我看真的有必要，DTS的问题我们不是一次两次对其产品的一些，设计，方案，提出过异议。虽然他在日常工作是不错的，但DTS的数据核验部分，的确是一个非常困难的地方，这里如果我是产品经理我会提出一个建议。

DTS提供两种验证服务，自动化验证服务，和手动验证服务。手动的验证服务，提供客户自己写语句，对特殊的表，进行条件式的数据核验服务。同时标注清楚，核验结果以与客户撰写的语句有关，DTS不承担由于客户业务逻辑错误，导致的验证不准确的问题。（免责条款），让数据验证更加的灵活一些，满足一些特殊情况的数据验证，比如无主键表的自主验证。

因为有些表太大了，一个表里面存几亿的数据是很正常的，而这样的表多如牛毛。

数据验证又是一个非常敏感的问题，我觉得数据验证的技术可以在提高，客户哪怕付费也是可以的，终究数据的严谨性通过更多的系统资源和技术来保证，是不能白嫖的。

今天就到这里吧，一看字数，洋洋洒洒，3500多字，其实我还有更多的一些问题，不过先这样吧？ PolarDB for PostgreSQL 牛不牛，我觉得以现有的类POSTGRESQL产品比较，他可以称为牛，尤其那个必杀技一出，但你说他问题多不多，我的回答不少。希望有责任心的客户和厂商一起做好产品，当下数据库产品，不应是厂商自己就能制定单一标准的时代，把核心客户，关键客户拉过来一起提高数据库产品的时代就在现在。这也是云产品最大的优势，贴近客户，倾听客户，互相成就，快速迭代。

这是一个长系列，后续会将迁移中的感受，使用数据库的感受，组成一个PolarDB for PG 迁移新长征系列，记录我们与阿里云PolarDB 这一段艰辛的旅程。

置顶

数据库HTAP概念新解读，一定和你知道的不一样

Oracle 26i 的一个功能演进后，云厂商利用会不会造出千年老妖样的“数据库”

在某国产数据库 “小黑屋” 会议后的感想和记录

“一顿海鲜引发”（3）一分钟定位数据库问题，试用得京东卡和礼物！

“一顿海鲜引发”（2）“运维工具与DBA之间不打不相识”

“一顿海鲜引发”（1）：DBA、架构师与数据库运维工具的爱恨情仇

DBA 从“修电脑的” 到上演一套 “数据治理” 大戏 --- 维护DBA生存空间，体现个体价值

Oracle 也有做失败的数据库系统？是的今天我们来说说他

老板说 MongoDB 测试环境这么贵，弄单机？开发说要复制集测试？你们这群XXX！！

国庆节2号 PostgreSQL 停机罢工协助解决问题得 66.66元的红包