攻坚利器 KFS助我们力挽狂澜，9天内政务系统开发迁移容灾全搞定！

2022年2月25日晚10点

上线倒计时9天，愁云惨淡路在何方

日落月升，喧嚣的城市，逐渐归于宁静。

此刻，S市M大楼依旧灯火通明，作为X项目开发商项目经理的我，还在为项目的如期上线紧张地忙碌着。离上线仅剩最后9天的关键时刻，依旧问题频出，这令我们团队的每个人都忧虑万分。

X项目的主体是S市关键政务系统，该系统由我司承担搭建并维护，为全市上万个政务用户提供服务，其业务高峰期并发会话量超过1000个，涉及多个应用和几十个Oracle数据库，整个项目错综复杂，难乎其难。目前我们计划对X项目的所有业务系统进行升级迁移，将原本基于Oracle运行的业务系统统一迁移到S市大数据中心的国产云平台上运行，底层数据库使用KingbaseES数据库。简而言之，我们需要对业务层及数据层重新开发和整合，使相关业务系统及业务数据向统一服务平台迁移。

整个项目工期紧迫且工作量庞大。根据计划，我们需要在3月6日前完成系统的整体迁移工作，确保系统在3月7日早上8点正式上线后，政务用户能够正常使用，并且新系统能够顺利支撑业务高峰期。

我负责S市政务系统迁移升级项目的整体统筹工作，虽然前期已投入大量人力物力赶工应对，但项目整体进度依旧差强人意，目前系统的关键应用依旧处于开发调试阶段。

根据应用开发人员的最新反馈，挡在我们面前的，主要是这2座大山:

1.为验证新系统上业务是否可以正常运行，每开发一个新功能，就需要同时在新旧两个系统上验证数据，耗费了双倍的时间；

2.存量数据庞大，停机窗口期无法完成系统迁移上线；

系统上线在即，这2座大山的存在给项目带来了极大的风险。

然而，一波未平，一波又起，正当我们为如何跨过那2座高山而头疼时，项目协同会上的新需求，仿佛成为了压垮我们的最后一根稻草。

3.客户对新系统上线后的稳定性存在顾虑，要求在新系统上线后，旧的业务系统依然可用，因此，要将新系统上新增数据实时的转移到旧的系统上。这是我们从未考虑的的问题，不论是从技术层面还是方案层面，我们都毫无头绪。然而，该项目是S市的关键政务系统，事关民生，事关大局。按时完成是底线，不容有失！

车到山前必有路，前一段时间在数据库产业峰会的经历，让我认识了金仓数据同步产品KingbaseFlySync（简称KFS），基于KFS的解决方案似乎可解我的燃眉之急。在与项目组成员简单地沟通及讨论后，便紧急致电KFS的H经理寻求帮助。

电话接通，H经理便感受到了我的急切与忧虑，在得知我的困境并听取我的诉求之后，立即针对我的需求初步的给出了基于KFS的3道锦囊妙计，并表示次日一早便可携方案及人员亲临S市，为我出谋划策。 

2022年2月26日早8点

第1计|KFS数据集中，力保开发调试高效推进

东方将白，作为应用开发商的我们、客户和金仓KFS三方人员便齐聚项目所在地，多方共同沟通X项目技术方案。身处现场，客户对项目能否按时保质完成的担忧和顾虑令我压力倍增。但KFS的鼎力相助令我多了份底气，当即向客户表示将只争朝夕，全速推进项目，确保项目质量和进度。

时间紧、任务重，我迅速进入工作状态，重新梳理开发计划：

当前，新系统仍处于开发调试阶段，经常涉及表结构和表数据的更改。开发人员需要在开发环境完成所有修改验证后，再将新功能手工同步到生产环境当中。

由于业务系统的复杂性，项目开发人员就有200多名，常用的业务表更高达7000+个。通常一个功能的开发涉及到十多个业务表的更改，开发人员将这些修改同步到生产库中，少则20分钟，多则几个小时，常常令开发人员叫苦不迭。更有甚者，一个表经常被多个开发人员同时修改，手动同步到生产环境时，还需要开发人员进行再次确认核实。修改的数据多了之后，再向生产库同步时，很难找到哪些是新增的数据，哪些是原有的。毕竟在上千万条数据中找到自己需要的，犹如大海捞针，难度可想而知。

按照此般现状，至少还需15天才能完成应用开发调试工作，但7天后的系统切换是用户给定的最后期限！

这种局面令我心乱如麻，好在，KFS产品的H经理在了解问题的关键点所在之后，适时拿出了第1计“KFS数据集中方案”。

在KFS工具介入后，我们开发人员在开发环境修改的表结构和数据能够实时地同步到生产环境中。并且，应用开发人员在提交修订后，可以在生产库中立即看到新功能的效果。避免了一次修改、多次重复操作的问题，也解决了在海量数据中筛选所需数据耗费大量时间的问题，还极大地缩减了项目整体人力成本。

3月2日晚8时，在全体应用开发人员紧锣密鼓的攻坚克难之下，在KFS产品的大力支持之下，我们在客户期望的时间节点之内，提前2天，完成了新系统的开发和调试！

2022年3月3日早8点

第2计|KFS平滑上线，零停机助力系统迁移上线

在与时间赛跑，成功翻越了第1座大山之后。我们来到了第2座大山的脚下。

由于客户的业务是面向全市的政务用户，因此留给业务的上线窗口期只有周六周日2天。毕竟对于政务系统，每多停机一天，造成的损失都不可估量。

然而，客户的应用系统为分布式架构，涉及的业务数据库众多，旧的Oracle库共几十个，存量数据高达20T+，数据量异常庞大。基于我们项目组现有的方案评估下来，完整的数据迁移至少需要4天，如果加上迁移后的系统调试，所需时间还会更多。如何与时间赛跑，在用户给定的停机窗口期内，完成系统的迁移上线，是我们无法破解的难题。

毕竟，在如此短的时间内，完成数据的迁移和新系统的调试，就好比“短时间”内给正在行驶中的 汽车 “换轮胎”一般，是一项巨大的挑战。

但提前完成的新系统开发和调试，为我们此刻的迁移工作争取到了充足的准备时间。在充分研究项目的历史数据之后，H经理献出了“基于kfs的不停机迁移”这第2计，在深入探讨该方案在本项目中应用的可行性后。

最终，我们引入KFS不停机迁移的能力，零停机，将旧的业务系统中的所有存量数据和增量数据完整地迁移到新的业务库当中。

2022年3月5日早8点

第3计|KFS双轨方案，新老系统间平滑切换

系统上线的问题解决后，新的挑战接踵而至！

由于客户对新系统上线后的稳定性存在顾虑，要求在新系统上线后，旧的业务系统依然可用。这就意味着，我们需要将新系统上新增数据实时地转移到旧的系统上。

如何将上线后KingbaseES中的增量数据给同步到原Oracle数据库中呢？项目组成员提出采取每天定时迁移的方式。但仔细论证一番后，发现筛选增量数据难、大数据量迁移耗时庞大等问题无法回避，该方案根本不现实。

天无绝人之路，正在大家一片焦头烂额之时，H经理抛出了第3计“KFS双轨方案”。

通过KFS双轨方案，在上线后一键更改同步方向，将新业务系统中产生的数据实时同步到原Oracle数据库，以此避免开发人员每日对新增数据的筛选、搬迁等重复工作；同时也保证了不论新系统是否稳定运行，旧系统中的数据都是完整可靠的。最大限度地保证了用户业务运行的连续性，减少因故障带来的损失。

应用KFS双轨方案之后，新系统数据将会实时回写到原Oracle数据库中作为灾备，全面消除了客户对新系统故障的顾虑。

海到天边天作岸，山登绝顶我为峰！就这样，第3座大山也被我们征服。 3月7日，到了检验战果的时刻。从早上7点起，我们就开始监控整个系统的运行状态，一直稳定运行到到晚上6点。为X项目交出圆满的答卷：

可以看到，无论是业务高峰期还是系统维护期，KFS始终以高吞吐、低延迟的同步能力保障服务的稳定运行；帮助我们翻过了这3座大山，经受住了这次困难的检阅。

小结

历经9天的奋战，X项目终于顺利上线，并平稳运行。即使在业务高峰期，性能依旧强势，令客户交口赞誉。

在此次项目中，我不止要感谢我的项目组成员夜以继日的奋战和攻坚克难。我更要感谢KFS的3道锦囊妙计。KFS的数据集中和不停机迁移不仅极大地节省了我们项目上线前的开发人工投入，缩短了项目上线周期，还减少了客户服务停止时间，令我们的项目得到客户充分认可和肯定。此外，双轨并行规避了上线失败的风险，大大缩减了后期运维成本，数据同步全自动，数据校验全自动。

KingbaseFlySync助力应用系统平稳升级，你也值得拥有！