查看原文
其他

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

2016-04-07 刘李明 DBAplus社群



企业面临的困境


当前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大版本分钟级别升级迁移等项目。


全球敏捷运维峰会【杭州站】




杭州站倒计时:2016年4月16日,DBA+社群联合Linux中国、三墩IT人开启全球敏捷运维峰会第一站:杭州!


技术大咖云集:峰会力邀来自阿里、京东、淘宝、网易、IBM、浙江移动、新炬网络、蘑菇街、百世物流等互联网与传统企业的资深大咖,汇聚500+行业精英!


互联网 VS 传统的碰撞:共同探讨互联网前沿技术应用心得、传统企业技术转型的实践与困境、全程拒绝无营养的广告,绝对干货,精彩不容错过!


DBA+社群专属购票优惠

门票优惠价:39元(原价99元)

(优惠码:dbaplus001)

VIP票优惠价:199元(原价299元)

(优惠码:dbaplusvip)


↓↓ 购票通道 ↓↓


长按识别二维码

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存