核心业务从SQLServer迁移到金仓KingbaseES V9实录

       随着国产化推进的加速，我们单位也开始启动国产数据库的选型，为了更好的了解国产数据库对现有应用的兼容性和性能表现，主任决定从主流的国产数据库厂商中选择多家进行迁移测试，从其中选择适合我们的国产数据库产品。

       由于单位现有的应用大部分使用的是SQLServer，且大量的程序代码使用T-SQL实现，一个业务系统大概有几十万行T-SQL，因此从主任到我们一线的工程师都非常担心迁移的难度和代价，由于业务系统是多年来迭代形成的，已经非常稳定了，因此，一般情况下谁都不愿意对代码做大的调整，因为仅仅是梳理需求都有着巨大的工作量。

       另外主任对于所谓的互联网架构也不认可，认为我们单位的应用没有这么高的扩展性要求，但是业务逻辑关系特别复杂，不适合、也没必要用微服务做拆分，开发、运维简单和稳定才是第一位的！作为一线工程师看我们的领导，真是务实、不卷的典范！

        由于前期和国内数据库厂商人大金仓做了交流，对方介绍自己的产品能够兼容SQLServer的T-SQL，且承诺如果有不兼容的代码对方来修改，因此决定首先测试人大金仓的产品。

       交流完第二天一早，人大金仓的工程师就上门部署了对方KES V9产品，我看了看对方安装过程，有一个向导界面，部署时选了数据库兼容模式为SQLServer，这一点挺有意思，在安装选项中一共有四种模式，除此之外还有Oracle、MySQL、PG三种模式，不过我们不太关心其他模式，先解决SQLServer迁移的问题。

        部署完成之后的过程，我们和人大金仓的工程师共同配合推进，我们选择的是我们最复杂的核心业务系统，数据表Table大概有12000张，存储过程有 1326个，函数有49 个，T-SQL的代码总量大概在 76万行，测试环境数据量是500 GB，实际生产环境 12 TB，每年差不多增长 900 GB。

       对方工程师使用工具将SQLServer上的测试数据和代码全部迁移到KES之上，500GB的测试数据大概跑了不到一个小时就迁移完毕了，然后我们配合更换业务系统的数据库驱动，然后配置地址到KES上，重启动应用。

       进入登录页面后点击登录，登录在后台直接调用的是存储过程，没报错，直接登录成功跳转到了业务工作台，点击主要的功能，正常，没有报错。由于我全程陪同对方工程师在做操作，没看到对方有做什么其他操作，就询问迁移过程中做过什么动作来修改代码没有，对方的反馈目前都是产品原生兼容的代码，如果有不兼容他们会告知我们，并报给研发团队就行产品升级。

       我和其他同事配合把主要的业务流程都跑了一遍，然后把一些报表统计的功能进行了验证，发现了三个问题，一个是有一个复杂统计报表金仓的响应速度比SQLServer明显要慢，另外两个是不兼容的能力点，代码执行报错，一个是我们很多代码是十多年前写的没有很严格遵从规范，有些代码没有用分号结束每行代码，在SQLServer中执行是可以的，在KES中运行报错，另外一个是KES不支持用等号赋予别名，SQLServer既可以用AS也可以用等号赋予别名。我就说嘛，一个国产的数据库产品不可能做的和SQLServer完全一样。但总体来看，兼容性已经非常优秀了。

       对方现场工程师记录下来问题，然后打开电脑开始提交问题工单，我也询问了解决问题的时间，对方说需要等研发团队分析后给出反馈，好吧，第一天就只能这样了。

       第二天，对方的工程师给出反馈，研发团队已经根据日志定位了原因，三个问题的修复时间大概需要一周，一周后给我们打补丁。

       第八天，对方工程师带着补丁文件到现场更新，然后重启应用和数据库，复测，问题已经解决，复杂报表的响应时间和SQLServer达到同等水平，不兼容的代码也能够正常执行了。我和同事一起再把其他主要功能回归测试了一遍，没有发现其他问题，下一步准备进行性能测试和稳定性测试。

       第九天，按照我们的性能测试脚本10个场景使用Loadrunner做50、100、200并发的压测，要求所有请求的最高响应时间不能超过5秒，平均响应时间要低于2秒，无步长、无思考时间。50、100并发压力下测试一次通过，各项指标满足要求，200并发有3个场景不达标，有一个场景出现了较大的性能瓶颈，对方的工程师收集了过程数据，两个场景建议我们优化SQL代码，选择更好的执行计划，经过代码调整后复测通过，现在仅剩一个场景的性能瓶颈，工程师反馈需要研发介入做产品优化，后续会提供补丁。

       第十五天，对方工程师将性能补丁更新到测试环境，200并发下最后一个场景的性能瓶颈解决，然后性能再次全面回归，各场景性能指标均达标，甚至部分场景性能指标优于SQLServer，满足生产要求。性能测试完毕，后续准备稳定性测试，计划测试7天，保持50并发的持续压力，由于设备需要协调，因此安排在两天后开始。

        第十八天，开始稳定性测试。

        第二十五天，稳定性测试结束，无报错，无异常，服务器各项指标正常。

       整个测试周期历时25天，我们单位一共投入了我和另外2名工程师，我是全时投入，其他2名工程师投入了2天功能测试的时间，算上性能测试和稳定性测试，总计差不多投入了10个人天，中间大部分时间是在等待对方提供功能和性能补丁。

       总体来看，测试结果领导非常满意，除了更换数据库驱动和极少的SQL代码性能优化之外，我们的业务系统代码没有做任何的修改，真的是没有任何的修改，十多年累计的七十多万行T-SQL代码啊，想想这是最头大的事情，居然就这么轻松的搞定了，真的是不敢相信，居然国内还能找到这样的替代品，为了确认这一点，主任反复和我们做了确认，也抽查了迁移到KES中我们的存储过程和函数的代码是否有变化，最后确认真是没有变化！好吧，膜拜下人大金仓，真的是只有想不到，没有做不到。

       至此，我们团队上下从主任到一线的工程师对于使用国产数据库这件事情信心大为增强，如果说之前大家还是认为这件事情难度太大，要谨慎考虑，现在认为也许没有那么复杂和可怕了，主任说，之前是愁的不行，现在则是踏实多了。

       功能和性能测试完成后，我们和人大金仓的技术团队又进行了一次方案交流，讨论切换生产的流程和风险，对方推荐了使用双轨并行的方案来完成业务系统的的分步骤上线，领导认为这样的方案比较稳妥，决定可以先测试一遍流程，确保风险可控。

       对方工程师到现场部署了数据同步软件来进行SQLServer到KES的数据复制，确保两个数据库的数据一致，便于在运行过程中进行数据库切换，本质来看，这个方案就是一个异构的容灾方案，如果一个数据库集群出问题，另外一个异构数据库集群接管，通过逻辑日志进行数据的解析复制，来确保业务的连续性。

       按照对方提供的操作手册，我在测试环境中连续多次的进行两个集群间的切换，总体来看切换时间和业务的繁忙程度密切相关，切换的时间在5分钟内能够完成，快的时候不到一分钟完成切换，能够满足我们要求的切换时间。

       一个来月的时间，终于完成了单位核心业务系统的迁移测试，从最开始的担忧和害怕，到逐步的明朗和建立信心，就像坐了一趟过山车，我们担心担忧的国产数据库的问题在人大金仓的解决方案和产品上都有了对应的解决之道！我们单位这么多年基于微软路线建立的技术栈.net+SQLServer的技术资产也得到了最大利用，我们也不用重写应用来完成数据库的国产化了，有时候我们自己也有一种不真实的感觉，什么时候国内的数据库厂商这么厉害了。但过程是实实在在亲身经历过来的，以前我们也会喷国内的基础软硬件厂商不行，烂泥扶不上墙，这次真的是彻底刷新了我们的认知！现在我们对国产数据库信心的增强了，期待未来有更好更优秀的产品推出。加油！