一

企业面临的困境

 

当前IT系统的软硬件迭代越来越频繁，特别是软件产品，客户生产系统中采用的软件都面临原厂的EOS风险。EOS即End Of Support，这是每个客户的IT部门都要面临的运维风险。当生产系统出现问题却又得不到原厂售后服务支持的时候，是一个多么悲催的事情，其中的麻烦谁遇谁知道，所以说跟着原厂的步伐进行大版本更新升级乃上上策。这是一个软件生命周期管理的课题，软件大版本的升级迁移是客户IT运维部门都要接受的重大挑战，同时也是IT运维服务厂商的重大挑战，当然如果IT运维服务厂商有合适的解决方案，那将是重大机遇。

简而言之，促使客户进行大版本升级迁移的两个根本原因：

1. EOS风险，如果不升级将得不到原厂官方的技术支持。

2. 新功能新特性的应用，对最新大版本中的某些新特性非常有兴趣。

二

行业解决方案

 

大部分的金融行业客户使用得最多的是IBM DB2数据库。在网络上关于DB2大版本升级迁移方面的资料并不多，或者说具有指导性建议的文章不多。本文简单介绍一个基于CDC复制技术实现DB2大版本平稳升级的案例，希望能够起到抛砖引玉的作用，达到探讨交流的目的。

众所周知，金融行业的客户对系统要求是7*24小时，对于系统可用性要求非常高，客户对系统升级迁移一般会提出以下三个要求：

1. 升级迁移时间窗口要求在分钟级别，新旧系统切换时间尽可能短，如5分钟至10分钟。

2. 升级过程中对源数据库（原生产系统）的性能无影响，要保障原系统不会因为升级而导致业务影响。

3. 升级失败后要求在分钟级别的时间窗口内回退至原版本运行，并且保障在新系统的变更数据同步回原系统。

如果要满足以上所有要求，传统的升级过程肯定是无法做到的，原因如下：

1. 时间窗口无法满足，传统升级过程至少是30分钟，甚至更长。

2. 低版本升级到高版本后不可回退，过程是不可逆的。

3. 一旦应用切到新版本而且有数据入库，当要切回旧系统版本运行时新数据不能追平。

基于以上原因，那么只能采用IBM的数据复制方案。将常用的IBM数据复制/同步方案比较如下：

数据复制方案	可靠性/可行性分析	备注
HADR	不适用升级迁移，源和目标的版本跨度太大时无法搭建HADR
SQL Replication	无法满足上述要求，需要在源库上创建相应的CD表；首次全量复制对源库有性能影响
Q Replication	无法满足上述要求,首次全量复制对源库有性能影响，即使使用备份还原至目标服务器，后续增量同步时的日志LSN很难找到	这里的LSN是为了定位自上次备份以来的变更数据的事务起点
CDC	完全适用，支持异构平台、大版本、双向复制等	通过bookmark技术，记录自上次备份以来的LSN号，下次CDC同步时仅需复制增量数据

综上所述，我们只能选用CDC软件技术实现。本文的重点就是探讨基于CDC技术如何实现DB2数据库大版本平稳升级迁移。CDC的技术突破在于以下两点：

1. 当首次全量复制同步（源库-->目标库）时，可以通过将源库的备份文件传至目标端进行Restore. 而不是象传统方式（传统做法是每张表先定义然后通过远程导出/导入）做法，这样可以大大减少网络传输开销，以及减轻源库抽数带来的性能的影响。

   
   

2. CDC断点续传功能，即bookmark功能可以标识当前的复制断点，即使源库在“bookmark”操作后有了新变更，CDC可以捕捉到增量的变更数据，下次复制只要从断点开始复制数据即可，既节省了全量复制的时间，同时保证了事务的一致性和连续性。比其他复制方案更智能和先进。

>>>>

CDC是什么？

CDC，现在叫IIDR（IBM Infosphere Data Replication），是一种基于DB2日志的高效复制解决方案，功能强大，使用灵活，可以实现多种方式、多种用途的数据复制，被广泛应用于企业报表、灾难恢复和高可用性环境中。下图为CDC的架构示意图：

>>>>

技术实现

当了解和熟悉了CDC复制技术的架构和原理之后，就可以开始制定DB2大版本升级迁移的流程和步骤。为了保障文章的简洁性，流程步骤简单概述如下：

1. 在源端(假设DB2版本为V9.1/V9.5/V9.7)和目标端(假设为V10.5)各自安装CDC相应软件。

2. 将源端的最近一次online backup恢复到目标端相应的版本，或者通过DDL创建V10.5版本的空库。

3. 在CDC管理控制台中配置源和目标端的复制关系（具体操作参阅CDC管理手册）。

4. 导出Subscription定义，并且备份V10.5库中CDC的Metadata表(TS_开头的三张表)

5. 在源数据库上执行dmmarkexternunloadstart，用来标记数据导出的起始点。

6. 需要重新恢复一次带有CDC bookmark的全备至目标端，前一次恢复是仅仅为了定义复制关系，本次才是关键点。

7. 在源数据库上执行dmmarkexternunloadend，用来标记数据导出的结束点。

8. 导入步骤4中备份的Metadata表以及CDC的Subscription定义。

9. 将目标端的DB2版本逐级升级至V10.5(ESE或PureScale)（假设源库的版本较低，如果为V9.7或以上则忽略此步骤）

10. 定义反向复制关系（目标端至源端的方向），在CDC中定义两个方向的同步关系，用于可回退到原版本运行。

11. 启动正向复制（源端至目标端的方向），开始进行增量数据的同步。

12. 停止所有应用程序（停机的时间取决于应用程序的复杂程度）

13. 验证源和目标端数据一致性（停机的时间取决于数据验证和校验的粒度，必须前期做好数据校验的计划和流程，否则无法保障数据库的完整性和一致性）

14. 启动反向复制（目标端DB2高版本至源端DB2低版本的方向），当源和目标端数据完全同步后，启动双向复制，保障“双活”情况下数据能完全同步。

15. 系统正式切割，启动所有应用程序，但必须保障应用程序要么连接老版本的数据库，要么连接是新版本的数据库。

16. 回退机制和流程的启动，如果出现极端情况，应用程序完全可以退回原来版本，恢复如初。

三

方案小结

 

迄今为止这应该是最完美的升级迁移方案了。

以上的流程和机制保障了DB2大版本升级迁移的平衡，在大版本升级过程前对源库无性能影响，升级过程中仅需要同步复制增量的变更数据，使网络传输量最小化，在升级失败后也可以轻松回退。基于CDC复制技术实现了DB2大版本的升级迁移，让客户享受到了IBM DB2原厂的售后服务，同时享受到了DB2最新版本的新功能、新特性。那么你还等什么呢，现在开始制定DB2大版本升级计划吧！

作者介绍：刘李明

• 资深lBM技术专家，8年lBM DB2售后支持经验。曾任lBM原厂华南GTS部门DB2服务团队Leader，主要负责大型运营商和金融行业的VIP客户。

• 国内最大的DB2数据仓库的规划和设计者，主导过某大型银行基于CDC技术实现DB2大版本分钟级别升级迁移等项目。