利用 Q 复制减少 DB2 数据库升级期间的业务停顿时间

look_w

概述DB2 数据库升级是指把使用的 DB2 数据库从低版本转化为高版本。DB2 数据库的新版本一般提供了很多新的功能特性、缺陷修复以及性能增强。另外，随着新版本数据库的出现与成熟，一些 DB2 旧版本已进入 EOS(End Of Support) 状态。所以，很多用户需要将 DB2 数据库从旧版本升级到新版本。数据库升级是一项至关重要且具挑战性的任务。一般升级 DB2 需要花费较长的时间，而且具有一定的风险。
Q 复制是 IBM 于 2004 年起推出的一种高性能的数据库间异步数据复制技术，主要支持 DB2 数据库，也支持 Oracle 数据库。它通过读取源数据库的日志记录来捕获数据变化，并将数据变化以数据库交易为单位通过 MQ 消息队列发送到目标服务器，最后在目标服务器将交易还原出来并提交至目标数据库。Q 复制具有无距离限制、无严格系统配置、多备份站点可同时使用等特点。下图 1 描述了 Q 复制中的关键组件。
图 1. IBM Q 复制部件
传统的数据库升级过程中，在数据库升级期间，业务应用必须停下来，对 7x24 类型的业务来说会产生比较严重的影响。而利用 Q 复制在数据库服务器升级时进行主备系统切换，可以有效降低数据库升级过程中的业务停顿，将停顿时间降为 30 分钟左右，大大减轻 DB2 数据库升级对业务的影响。
传统数据库升级的过程和缺陷传统的单机数据库服务器升级的流程如图 2 所示。
图 2. 传统数据库升级过程
数据库升级是一项系统性工程，升级前需要做好一系列的准备工作，比如检查数据库升级条件，操作系统、磁盘和内存等是否满足 DB2 新版本的要求，备份系统配置文件和环境变量文件，制定升级计划和测试计划等等。准备工作完成后，停止所有应用和业务；停数据库服务器；开始执行数据库升级程序，数据库服务器升级完成后，测试数据库新版本；升级完成并且测试通过后，启动数据库服务器；恢复业务。
从图 2 中可以看到，开始运行数据库升级程序之前，必须停掉在该数据库上的所有应用和业务。比如传统的银行业务系统，数据库升级期间就不能使用网银和 ATM 了。并且在整个数据库升级期间，业务都无法进行，业务停顿时间涵盖整个升级过程。
传统数据库服务器升级往往造成长时间的业务停顿，如表 1 所示。
表 1. 传统的数据库升级造成的业务停顿
No.操作业务状态业务停顿时间1升级前准备工作正常-2停应用停顿2 分钟3停数据库服务器停顿2 分钟4升级数据库服务器；并进行数据完整性验证测试，系统测试等。停顿3~4 个小时5启动数据库服务器停顿5 分钟6启应用停顿5 分钟7应用恢复之后正常-从表 1 中我们可以看到，传统的数据库升级过程造成了 3-4 个小时的业务停顿，如果升级过程中遇到了问题，还会停顿更长时间。这严重影响了用户的业务需求，缺陷如下：

• 业务停顿长，严重影响用户的业务需求。
• 业务风险高，升级过程中可能会遇到预料之外的问题或者突发事件，这时要启动一个紧急修复流程，严重的话可能会再产生计划之外的业务停顿！并且一旦升级失败，只能重新安排到下一次升级周期，通常要推迟到三四个月之后。
• 升级必须安排在业务最不受影响的时间段，比如，半夜零点至凌晨 4 点，但是事实上永远也没有真正的业务空闲时段。
• 难以评估数据库升级之后对应用程序的影响，无法判断数据库升级之后，应用程序的行为是否跟数据库升级之前保持一致。比如，应用程序是否会出现过分消耗资源等问题。
• 难以防范数据库升级过程中人为造成的失误。
• 受升级时间限制，无法计划和执行完整详尽的测试。

利用 Q 复制减少 DB2 数据库升级期间的业务停顿Q 复制在数据库灾备方案，多套系统之间的数据整合与同步，数据库服务器升级时主备系统切换等需求中发挥着至关重要的作用。其中，利用 Q 复制在数据库服务器升级时进行主备系统切换，降低业务停顿时间，是企业中每隔几个月就会面临的重要需求。
利用 Q 复制的数据库升级过程利用 Q 复制的数据库服务器升级的流程如图 3 所示。
图 3. 利用 Q 复制的数据库升级过程
从图 3 中可以看到，当 A 站点需要进行数据库服务器升级时，利用 Q 复制的数据库升级过程如下：

• 完成升级前的准备工作，制定升级计划和测试计划等。
• 主站点 A 暂停接受应用负载。
• 等待主站点 A 上的所有数据改动都已被 Q 复制应用到备用站点 B 的数据库上。
• 停止主站点 A 的数据库和 Q 复制程序（包括 MQ）。
• 把主站点 A 的所有应用负载切换到备用站点 B。在备用站点 B 新发生的数据改动会被 Q 复制捕获并发送出去。由于主站点 A 不可用，所以改动的数据会被暂存在站点 B 的 MQ 消息队列中。
• 升级主站点 A 的数据库服务器，并进行数据完整性测试和系统测试。
• 主站点 A 完成数据库升级后重新启动数据库。
• 站点 B 停应用。
• 主站点 A 重新启动 Q 复制程序（包括 MQ），暂存在站点 B 的 MQ 消息队列中的数据会被传送到站点 A，并被站点 A 的 Q 复制程序应用到数据库上。等待备用站点 B 上的所有数据改动都已被 Q 复制应用到主站点 A 的数据库上。
• 复制完成后把所有应用负载切换回主站点 A。
• 此时就完成了数据库升级和应用恢复。这时站点 A 上的数据改动源源不断被复制到站点 B，站点 B 可以用作热备或者查询用途。

利用 Q 复制的数据库升级过程中的各个阶段的业务停顿情况如表 2 所示。
表 2. 利用 Q 复制的数据库升级造成的业务停顿
No.操作站点 A
业务状态站点 B
业务状态业务停顿时间1升级前准备工作正常--2站点 A 停应用停顿-2 分钟3站点 A 到站点 B 的数据复制完成停顿-5 分钟4站点 A 停数据库服务器和停 Q 复制停顿-5 分钟5站点 B 启应用停顿-5 分钟6站点 A 升级数据库服务器；
并进行数据完整性验证测试，系统测试等。停顿
（3~5 个小时）正常-7站点 A 启动数据库服务器停顿正常-8站点 B 停应用停顿停顿2 分钟9站点 A 重新启动 Q 复制；
等待站点 B 到站点 A 的数据复制完成。停顿停顿10~30 分钟10站点 A 启应用停顿停顿5 分钟11站点 A 应用恢复之后正常--从图 3 和表 2 中可以看到，利用 Q 复制的数据库升级过程，在主站点 A 升级数据库服务器期间，业务和应用程序正常运行在站点 B 上，所以业务停顿时间只发生在两个小阶段。第一个小阶段是主站点 A 停应用到备份站点 B 启应用的过程；第二个小阶段是主站点 A 的数据库服务器升级完成后，备份站点 B 停应用到主站点 A 启应用的过程。这两个时间段都很短，大概只有十几分钟，从而整体的业务停顿时间由 3~5 个小时降低到 30 分钟左右。
与传统升级过程相比的优势利用 Q 复制的数据库升级过程有着显著的优势，因数据库升级引起的停机能在数分钟内完成站点间应用切换，可以实现很短的计划内停机时间，并且没有数据丢失。优势如下：

• 数据库服务器升级期间，业务正常运行，满足了用户的迫切需求。

• 业务停顿时间短，整体的业务停顿时间由 3~5 个小时降低到 30 分钟左右。
• 非常有效的降低了数据库升级的实施风险，提高了业务处理能力。如果升级过程中遇到预料之外的问题或者突发事件，可以让业务继续运行在站点 B 上，客户不会受损失。这样客户可以有更宽裕的时间和更好的灵活性来处理紧急事件。这个优势对于客户来说至关重要。
• 升级计划安排更加灵活。并且可以根据风险评估，计划和执行更为详尽的测试。
• 提高了客户业务的持续可用性。
• 减少了计划外业务停顿时间。
• 提高了运营业务的服务质量。

结束语本文先介绍了传统的数据库服务器升级的过程和缺陷，然后详细阐述了利用 Q 复制在数据库服务器升级时进行主备系统切换，有效降低业务停顿时间的工作原理和优势所在。利用 Q 复制的数据库升级过程有着显著的优势，使得整体的业务停顿时间由 3~5 个小时降低到 30 分钟左右，并且非常有效的降低了数据库升级的实施风险，提高了业务处理能力等。