BigdataLyn's TECH Blog! 刀不磨要生锈,人不学习要落后 - Thinking ahead

转:基于CDC复制技术实现DB2大版本升级迁移

2016-03-28
DB2
 

企业面临的困境

当前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数据复制/同步方案比较如下:

Replication-Compare

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

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

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


CDC是什么?

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

What-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大版本升级计划吧!


作者介绍:刘李明

http://mp.weixin.qq.com/s?__biz=MzI4NTA1MDEwNg==&mid=403173621&idx=2&sn=cb7fd3b0fe6d35c7a0dd145daf34a07e&scene=4#wechat_redirect



Comments