担心异构数据库迁移踩“坑”？听听大咖们怎么说

在技术升级和国产化战略的双重推动下，如何将来自 Oracle、MySQL 等异构数据库的数据无缝迁移至国产数据库，已成为企业持续发展的关键一环。

YashanDB Meetup 第 13 期特别邀请首届迁移体验官用户代表、TechTalk 社区创始人尚雷，YashanDB 售后服务负责人张建龙，一起探讨数据库迁移之道！

以下内容根据直播对话实录整理而成，还有更多想听、想看的内容可以留言告诉我们~

Q1 在实际迁移时，该怎样去避免数据的丢失来保证数据的正确性、完整性？

尚雷：在迁移时，我们经常会发现有些迁移的文件，由于没有很好的备份，在迁移过程中会出现文件损坏、文件丢失、数据丢失等情况，导致迁移失败。建议在迁移前进行完整性检查，确保进行完整的数据备份，并建议使用可靠的迁移工具进行迁移。

此外，由于事务处理不同步或迁移脚本错误，还有可能出现迁移前后两边的数据不一致的情况，我们在做数据校验的时候才发现两边的数据存在数据条数以及数据对象相差较大。建议选择高度兼容的源数据库和目标库，并使用数据比较工具定期校验两者间的数据一致性，确保同步机制正确实施。

Q2 YashanDB 团队在迁移过程中，如何保障数据的完整性呢？

张建龙：YashanDB 主要从两个方面保障迁移数据的完整性。一方面是 YashanDB 内核设计上面，与 Oracle 保持一致，其他类型数据库如 MySQL、PG 等在不与 Oracle 兼容特性冲突的前提下，YashanDB 也尽可能和它们保持兼容；另一方面用崖山配套工具迁移平台 YMP 来保障。

首先，YashanDB 在内核设计上数据类型、语义语法、函数处理行为等均和 Oracle 保持一致。

在设计 YashanDB 时，就已考虑将数据类型和 Oracle 的数据类型保持一致，包括长度、精度等；还有对 Oracle 语法语义的兼容，包括那种很小的细节，如每个函数的处理结果、每个空类型的返回结果都会保持一致。所以从 Oracle 迁移至 YashanDB 会非常方便。

这样可以最大程度上降低因为异构数据库的迁移带来的应用行为的不一致，导致业务失败。所以说从 Oracle 迁移，我觉得我们是相对是做的是比较全的。

其次对于 PG 和 MySQL 这两个数据库，崖山主要采取如下两种做法：

一是 YashanDB 兼容两者与 Oracle 非冲突的特性，如果遇到了 PG 和 MySQL 特有的东西，而且与 Oracle 不冲突的，那我们就会把这些兼容性也会做到 YashanDB 里面去；但是假如这个行为和我们之前设计的 Oracle 行为是有冲突的话，目前需要通过修改应用代码的方式来解决，因此如果是从 MySQL 或 PG 迁移到 YashanDB 的话，它可能存在少量的修改。

这是当前的一个处理方法，随着 MySQL 迁移的市场需求越来越多，我们正在研发与 MySQL 兼容的版本，预计下半年进行发布。在 MySQL 的兼容版本里面，我们就会尽量跟 MySQL 保持语义语法的兼容，包括执行结果、所有函数类型的兼容。这样在迁移 MySQL 时，就像现在迁移 Oracle 一样，几乎不需要应用去做一些适配改造。

二是 YashanDB 适配两者的数据类型长度和精度等，以避免数据丢失。因为 Oracle 跟 MySQL 本身的数据类型是有一定的差异，在迁移 MySQL、PG 这种数据库的时候，对于数据类型，我们现在的设计是选择一个我们的长度、精度等于它当前的一个长度、精度或者说大于它的一个长度和精度，这样的话从它迁移过来就不会因为它存储长度的不够或者是精度的问题，导致它原来的数据迁移失败的问题。

这是我们从设计上说，崖山对数据迁移的数据一致性做的保障。

第二种方式就是通过崖山迁移平台 YMP 来保障。YMP 支持全量校验和统计校验，全量校验能够保证数据的一致性、完整性，但是效率偏低；统计校验效率较高，但它是通过对比源库和目标库的行数来快速确认数据是否完整，无法保证完整精确的一致性。大家可以根据数据量的大小来选择校验方式。

在 YMP 新的版本里，我们还会对这两种校验方式做一个折中，既保留行数的快速校验，又保证数据的全量校验一致性，但这个全量不是指全部的数据。比如说我们会随机抽取部分行数做些校验，这样的话就是根据随机抽取的行数，看它是否一致，这样的话我们可以根据我们抽取的数据量大小来保证我们校验的效率。

当然在真实的迁移场景中，不同的生产环境可能对停机时间是要求不一样的，有的可能只能停几分钟，有的可能停几小时，有的可以停一天，所以说我建议如果生产时间充裕的话，最好还是进行全量校验；如果时间不充裕，可以将全量校验放在测试环境，在测试环境去校验我们的数据一致性。同时，对于异构数据库的迁移，应根据我们应用对数据的一致性要求，建议尽量对应用做全面的功能测试、性能测试以及回归测试等，来保证我们应用系统不出问题。一般来说越重要的系统，就更要做这种测试，且要测得更充分一些。

这就是我们崖山目前在保障异构迁移过程中数据类型的一致性，以及精度数据丢失等问题上面做的一些工作。

Q3 对于异构迁移源数据库和目标库兼容性的问题，有什么需要注意的地方，两位老师有什么看法和经验吗？

尚雷：兼容性里面有点很多需要注意。比如说数据类型的兼容性；还有数据表的兼容性（普通表、分区表等）；以及数据结构的兼容性和数据字符串的兼容性，如时间类型、精度等方面；或是 SQL 语句的兼容性，还有执行计划的兼容性等等。建议在做正式迁移前要进行大量兼容性验证测试，避免迁移前后数据库不兼容。

举个例子，我们之前在做迁移时，发现字符串块的大小不适合，所以调整了块大小。但这样也导致迁移之后，由于块的大小在开始时没有规划好，出现了容量增长特别快的情况。

另外还有一些存储过程函数和触发器的兼容性，这也是前段时间我们在做异构迁移时发现的一个大问题；还有一些表大小的存储容量，迁移后数据库与其他系统之间业务联调或者复制等协调相关的优化问题；以及针对 TP 的业务系统都是需要在迁移之前大量的、反复的测试，才能保证兼容性。

以上是我的一些直观感受，我也是通过之前做的一些同构和异构的迁移，发现的这些常见问题。

张建龙：嗯，刚刚在第一部分也有讲到，我们崖山在内核设计上就是高度兼容 Oracle 的，我现在再从对业务场景的兼容和对熟悉 Oracle DBA 的用户体验兼容上讲一下。

刚刚尚雷老师也提到了，我们有些业务，特别是使用 Oracle 的业务，很多业务逻辑就写在数据库里面，我们通过触发器、PL SQL、存储过程还有 package 来把业务代码在数据库里面直接执行，它的好处是不需要出数据库外部，性能也能得到保障。如果我们要迁移，会有大量的这种写在 Oracle 里面的业务代码。为此我们就设计了一个自研的 PL SQL 引擎，这个引擎的语法行为也是跟 Oracle 全面兼容的，我们的想法就是从 Oracle 迁移过来后尽量不用改，或者尽量少改。我们的崖山迁移平台 YMP 也会对 YashanDB 数据库跟 Oracle 的兼容性会做一个评估。

另外一点就是除了对这种业务的兼容，我觉得 YashanDB 对用户的兼容也是非常好，特别是对于 DBA 来说。其实我也是做了十多年的 DBA 了，对 Oracle 的使用非常多、也比较熟悉。我现在发现我对 YashanDB 的一些理解，包括崖山的一些生态、管理理念以及 SQL 优化的理念，几乎所有的东西我都可以沿用我过去的实战经验。比如我要怎么排查一个故障呢？我要怎么去优化一下性能呢？我会想一下原来在 Oracle 有什么手段，我在崖山试一下原来监控的 SQL 和原来的管理命令。我发现这些命令和 Oracle 的基本上是一模一样的。也就是说，我拿着原来的 Oracle 实战技能用在 YashanDB 上，是几乎是做到无缝对接的，这可以极大地降低我的学习成本。

随着信创改造的进一步扩大，我想如果我们 YashanDB 产品发展好了，对于原来熟悉 Oracle 的 DBA 来说，我觉得是很容易掌握了另外一种数据库技能。当然 YashanDB 作为一个新产品，自身也还有一些不足的地方，我也是非常欢迎广大数据库爱好者们给我们提一些建议和意见。另外 YashanDB 在市场上也是起步不算太久，也需要更多的业务场景去打磨它和应用的兼容性、底层的兼容性等能力。

Q4 其实用户除了关注产品兼容性以外，也会去关注迁移效率的问题。比如说在大数据量的一个场景下，我们怎么尽可能地去缩短迁移的时间窗口？

尚雷：我觉得首先要评估一下迁移的数据量大小，并在正式迁移前要在测试环境中反复地进行演练，演练的时候服务器、软硬件的配置尽量和要迁移的目标服务器，保持一致或者兼容性更好一些，这样能更好的保证迁移的效率。

比如说我们之前有一次做迁移，在开始前没有做很好的评估，我们服务器的配置相对来说是比较差的，导致在实际的迁移过程中，我们跟用户承诺的时间远远没有达到我们迁移的要求。我们开始的承诺时间是几个小时，但在迁移过程中发现出现了一些很大的意外，导致出现数据库回退的情况，整个过程我们花了差不多两天的时间，导致核心的业务不能使用。

以及在正式迁移前，我们还要做一些反向的演练。比如说从源端迁移到目标端，如果要是做回退的话，该如何快速地从目标端再回迁到源端？这些东西都需要去考虑。还有前面也提到，在前期迁移过程中可能会出现成本和时间的超支，如果开始的时候没有规划好，导致时间远超过业务的重塑恢复的时间，会给公司带来巨大的损失。

所以在正式迁移前我觉得是一定要把这种前期的准备工作给做好，才能保证我们在迁移的过程中万无一失。

Q5 那请问张建龙老师，就是针对尚雷老师说的这些点，比如说迁移前的反向演练，以及怎么去提升迁移效率，崖山是怎么来做的呢？

张建龙：嗯，尚雷老师说得非常好。在生产上做迁移是非常重要、慎重的，所以说我们对于各种硬件环境、迁移的方案以及回退的方案，要做到比较完善。在这我也想讲一下，崖山在这方面做的一些工作。

我们知道迁移根据时间窗口的不同，对应迁移的类型不同，主要分为三类，全量迁移、增量迁移和实时迁移。增量迁移一般是在全量的基础上基于时间做部分数据的迁移；实时迁移是基于 redo 日志、重构日志做实时的迁移，也就是数据同步。如果我们对时间要求非常紧的话，我们肯定是先做全量的迁移，然后再做实时迁移，因为基于数据库的实时产生的日志做业务数据的实时同步，这样的话可以保证我们业务切割时间会非常短。

现在我们崖山全量迁移是做得最多的，性能也是做得相对比较好的。全量迁移的核心很简单，就是一边把数据库导出来，另外一边数据库导入进去，对于导出，目前来说大家都是通过 SQL 查询出来这个值；在导入的时候，有的数据库是通过走 SQL 的方式去插入。崖山目前不是用插入的方式，而是用 yasldr，类似于 Oracle 的 SQL loader 一样，是一个数据灌入的技术，这个技术它比 insert 的效率提高很多，所以说目前崖山迁移效率高，得益于我们采用了数据灌入的方式。yasldr 还有一个功能，就是不记录归档日志 Redo，就像 Oracle nologging，我们可以在 YMP 压缩段里面把它禁用掉，禁用掉之后它就不再写日志了，可以再次提升我们全量迁移的效率。目前在 YMP 里面默认还是没有打开的，大家需要可以去打开。

还有就是 YashanDB 在并行上也做了非常多的努力，一方面我们可以做表级别的并行，可以做到分区并行，甚至可以拆分成子表内容的一个并行，并在不同的层级上做了一些并行来充分利用我们服务器的资源，把迁移同步的效率提上来。

在未来的 YMP 版本中，我们会把导入导出的数据落盘行为取消掉，使其变成一个数据流，它会进一步加快我们数据全量迁移的效率。

另外增量迁移，即基于日志的迁移我们也正在研发，目前来说 Oracle 和 MySQL 基于日志的解析工具已经非常完善了，比如说用 Oracle goldengate，可以实时地写入到崖山数据库里面，可以保证切割时间的缩短。

另外就是尚雷老师刚刚提到的回退问题。首先这种概率是非常低的，但是为了保障数据的完整性，我们还是要做到。这种操作叫反向同步，可以将迁移到 YashanDB 的数据完全反向写回原来的异构数据库 Oracle、MySQL，目前崖山已经在部分客户中用到了该操作，但是还没有完全对外，预计在下一个版本会上线，大家也可以期待一下。