基于CDC复制技术实现DB2大版本升级迁移
当前IT系统的软硬件迭代越来越频繁，特别是软件产品，客户生产系统中采用的软件都面临原厂的EOS风险。EOS即End Of Support，这是每个客户的IT部门都要面临的运维风险。当生产系统出现问题却又得不到原厂售后服务支持的时候，是一个多么悲催的事情，其中的麻烦谁遇谁知道，所以说跟着原厂的步伐进行大版本更新升级乃上上策。这是一个软件生命周期管理的课题，软件大版本的升级迁移是客户IT运维部门都要接受的重大挑战，同时也是IT运维服务厂商的重大挑战，当然如果IT运维服务厂商有合适的解决方案，那将是重大机遇。
简而言之，促使客户进行大版本升级迁移的两个根本原因：
EOS风险，如果不升级将得不到原厂官方的技术支持。
新功能新特性的应用，对最新大版本中的某些新特性非常有兴趣。
大部分的金融行业客户使用得最多的是IBM DB2数据库。在网络上关于DB2大版本升级迁移方面的资料并不多，或者说具有指导性建议的文章不多。本文简单介绍一个基于CDC复制技术实现DB2大版本平稳升级的案例，希望能够起到抛砖引玉的作用，达到探讨交流的目的。
众所周知，金融行业的客户对系统要求是7*24小时，对于系统可用性要求非常高，客户对系统升级迁移一般会提出以下三个要求：
升级迁移时间窗口要求在分钟级别，新旧系统切换时间尽可能短，如5分钟至10分钟。
升级过程中对源数据库（原生产系统）的性能无影响，要保障原系统不会因为升级而导致业务影响。
升级失败后要求在分钟级别的时间窗口内回退至原版本运行，并且保障在新系统的变更数据同步回原系统。
如果要满足以上所有要求，传统的升级过程肯定是无法做到的，原因如下：
时间窗口无法满足，传统升级过程至少是30分钟，甚至更长。
低版本升级到高版本后不可回退，过程是不可逆的。
一旦应用切到新版本而且有数据入库，当要切回旧系统版本运行时新数据不能追平。
基于以上原因，那么只能采用IBM的数据复制方案。将常用的IBM数据复制/同步方案比较如下：
数据复制方案 | 可靠性/可行性分析 | 备注 |
HADR | 不适用升级迁移，源和目标的版本跨度太大时无法搭建HADR | |
SQL Replication | 无法满足上述要求，需要在源库上创建相应的CD表；首次全量复制对源库有性能影响 | |
Q Replication | 无法满足上述要求,首次全量复制对源库有性能影响，即使使用备份还原至目标服务器，后续增量同步时的日志LSN很难找到 | 这里的LSN是为了定位自上次备份以来的变更数据的事务起点 |
CDC | 完全适用，支持异构平台、大版本、双向复制等 | 通过bookmark技术，记录自上次备份以来的LSN号，下次CDC同步时仅需复制增量数据 |
综上所述，我们只能选用CDC软件技术实现。本文的重点就是探讨基于CDC技术如何实现DB2数据库大版本平稳升级迁移。CDC的技术突破在于以下两点：
当首次全量复制同步（源库-->目标库）时，可以通过将源库的备份文件传至目标端进行Restore. 而不是象传统方式（传统做法是每张表先定义然后通过远程导出/导入）做法，这样可以大大减少网络传输开销，以及减轻源库抽数带来的性能的影响。
CDC断点续传功能，即bookmark功能可以标识当前的复制断点，即使源库在“bookmark”操作后有了新变更，CDC可以捕捉到增量的变更数据，下次复制只要从断点开始复制数据即可，既节省了全量复制的时间，同时保证了事务的一致性和连续性。比其他复制方案更智能和先进。
CDC是什么？
CDC，现在叫IIDR（IBM Infosphere Data Replication），是一种基于DB2日志的高效复制解决方案，功能强大，使用灵活，可以实现多种方式、多种用途的数据复制，被广泛应用于企业报表、灾难恢复和高可用性环境中。下图为CDC的架构示意图：
技术实现
当了解和熟悉了CDC复制技术的架构和原理之后，就可以开始制定DB2大版本升级迁移的流程和步骤。为了保障文章的简洁性，流程步骤简单概述如下：
在源端(假设DB2版本为V9.1/V9.5/V9.7)和目标端(假设为V10.5)各自安装CDC相应软件。
将源端的最近一次online backup恢复到目标端相应的版本，或者通过DDL创建V10.5版本的空库。
在CDC管理控制台中配置源和目标端的复制关系（具体操作参阅CDC管理手册）。
导出Subscription定义，并且备份V10.5库中CDC的Metadata表(TS_开头的三张表)
在源数据库上执行dmmarkexternunloadstart，用来标记数据导出的起始点。
需要重新恢复一次带有CDC bookmark的全备至目标端，前一次恢复是仅仅为了定义复制关系，本次才是关键点。
在源数据库上执行dmmarkexternunloadend，用来标记数据导出的结束点。
导入步骤4中备份的Metadata表以及CDC的Subscription定义。
将目标端的DB2版本逐级升级至V10.5(ESE或PureScale)（假设源库的版本较低，如果为V9.7或以上则忽略此步骤）
定义反向复制关系（目标端至源端的方向），在CDC中定义两个方向的同步关系，用于可回退到原版本运行。
启动正向复制（源端至目标端的方向），开始进行增量数据的同步。
停止所有应用程序（停机的时间取决于应用程序的复杂程度）
验证源和目标端数据一致性（停机的时间取决于数据验证和校验的粒度，必须前期做好数据校验的计划和流程，否则无法保障数据库的完整性和一致性）
启动反向复制（目标端DB2高版本至源端DB2低版本的方向），当源和目标端数据完全同步后，启动双向复制，保障“双活”情况下数据能完全同步。
系统正式切割，启动所有应用程序，但必须保障应用程序要么连接老版本的数据库，要么连接是新版本的数据库。
回退机制和流程的启动，如果出现极端情况，应用程序完全可以退回原来版本，恢复如初。
迄今为止这应该是最完美的升级迁移方案了。
以上的流程和机制保障了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）
↓↓ 购票通道 ↓↓
长按识别二维码