内容


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

Comments

概述

DB2 数据库升级是指把使用的 DB2 数据库从低版本转化为高版本。DB2 数据库的新版本一般提供了很多新的功能特性、缺陷修复以及性能增强。另外,随着新版本数据库的出现与成熟,一些 DB2 旧版本已进入 EOS(End Of Support) 状态。所以,很多用户需要将 DB2 数据库从旧版本升级到新版本。数据库升级是一项至关重要且具挑战性的任务。一般升级 DB2 需要花费较长的时间,而且具有一定的风险。

Q 复制是 IBM 于 2004 年起推出的一种高性能的数据库间异步数据复制技术,主要支持 DB2 数据库,也支持 Oracle 数据库。它通过读取源数据库的日志记录来捕获数据变化,并将数据变化以数据库交易为单位通过 MQ 消息队列发送到目标服务器,最后在目标服务器将交易还原出来并提交至目标数据库。Q 复制具有无距离限制、无严格系统配置、多备份站点可同时使用等特点。下图 1 描述了 Q 复制中的关键组件。

图 1. IBM Q 复制部件
图 1. IBM Q 复制部件
图 1. IBM Q 复制部件

传统的数据库升级过程中,在数据库升级期间,业务应用必须停下来,对 7x24 类型的业务来说会产生比较严重的影响。而利用 Q 复制在数据库服务器升级时进行主备系统切换,可以有效降低数据库升级过程中的业务停顿,将停顿时间降为 30 分钟左右,大大减轻 DB2 数据库升级对业务的影响。

传统数据库升级的过程和缺陷

传统的单机数据库服务器升级的流程如图 2 所示。

图 2. 传统数据库升级过程
图 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. 利用 Q 复制的数据库升级过程
图 3. 利用 Q 复制的数据库升级过程

从图 3 中可以看到,当 A 站点需要进行数据库服务器升级时,利用 Q 复制的数据库升级过程如下:

  1. 完成升级前的准备工作,制定升级计划和测试计划等。
  2. 主站点 A 暂停接受应用负载。
  3. 等待主站点 A 上的所有数据改动都已被 Q 复制应用到备用站点 B 的数据库上。
  4. 停止主站点 A 的数据库和 Q 复制程序(包括 MQ)。
  5. 把主站点 A 的所有应用负载切换到备用站点 B。在备用站点 B 新发生的数据改动会被 Q 复制捕获并发送出去。由于主站点 A 不可用,所以改动的数据会被暂存在站点 B 的 MQ 消息队列中。
  6. 升级主站点 A 的数据库服务器,并进行数据完整性测试和系统测试。
  7. 主站点 A 完成数据库升级后重新启动数据库。
  8. 站点 B 停应用。
  9. 主站点 A 重新启动 Q 复制程序(包括 MQ),暂存在站点 B 的 MQ 消息队列中的数据会被传送到站点 A,并被站点 A 的 Q 复制程序应用到数据库上。等待备用站点 B 上的所有数据改动都已被 Q 复制应用到主站点 A 的数据库上。
  10. 复制完成后把所有应用负载切换回主站点 A。
  11. 此时就完成了数据库升级和应用恢复。这时站点 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 分钟左右,并且非常有效的降低了数据库升级的实施风险,提高了业务处理能力等。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Information Management
ArticleID=1030235
ArticleTitle=利用 Q 复制减少 DB2 数据库升级期间的业务停顿时间
publish-date=04202016