使用 Q 复制实现 DB2 数据库系统的高可用性和双活

数据是现代企业最重要的业务资产之一，尤其是关键数据。如果数据不可用或者没有受到保护，企业可能会在每一小时的业务宕机时间内损失数百万美元，同时还会给企业形象带来负面影响。对于希望在瞬息万变的竞争环境中取得成功的企业来说，构建一个具有高可用性架构的数据中心至关重要。在本文笔者将介绍如何使用 IBM InfoSphere Data Replication 产品中的 Q 复制技术实现 DB2 数据库系统的高可用性和双活。

1. 概述

数据库是现代企业数据中心的核心，用于支持关键的企业应用。对于数据库的要求，除了高性能，高可靠性，功能丰富，易使用，易维护外，还要求有很好的灾备和高可用性方案配合，提高数据的安全和可用性。

1.1 数据库灾难恢复 (DR) 的概念

顾名思义，数据库灾难恢复方案为灾难事件准备的数据库备份和恢复方案，简称灾备方案。这里涵盖的灾难包括各种自然和人为灾难事件，如有洪水、地震、飓风、海啸等各种极端自然天气和现象，和爆炸、火灾、电网故障等人为异常事件。这些灾难会对数据中心的基础设施造成影响，毁坏数据中心的存储介质，导致数据库中的数据丢失。灾难的特征参数包括它影响的地理范围，持续的时间长短，以及对设施和数据的破坏程度。为了防止这些事件彻底毁灭企业的数据，企业需要设计有相应的灾备措施，在灾难影响范围之外部署备用数据中心和存放备份数据，这样当灾难真的发生时才能够在备份数据中心继续开展业务。

灾备方案需要根据针对的灾难特征来设计。比如对于影响范围局限在数据中心内部的灾难（范围几百米），同城的灾备中心就可以恢复业务。对于影响范围大到整座城市的灾难（范围为几十公里），就需要部署在异地甚至很远处的灾备中心来恢复业务运行。实际中经常听说的同城灾备中心和异地灾备中心就是指灾备节点处于同城范围或者异地范围。

对灾备方案，主要有两个技术指标：

1. 数据损失指标 RPO (Recovery Point Objective)，表示在该灾备方案下可能的数据丢失量，以时间单位来表示，比如丢失三个小时的业务数据。
2. 恢复时间指标 RTO (Recovery Time Objective)，表示在该灾备方案下重新恢复业务需要的时间，比如需要两个小时才能重新启动业务。

传统的灾备方案，多采用主机 - 备机（Active-Standby）的部署方式。可以部署在同城，或者异地。主机和主数据库用来处理业务，备机和备用数据库则处于待命状态，只有在主机遭遇灾难失效时才会在备机上启动数据库和恢复数据，继续提供服务。主机的数据库数据采用定期或者连续的方式复制到备机端，比如：

• 早期的很多灾备方案里，主机数据库的数据备份和归档日志备份会定期（如每天）传送到备机端
• 通过远程复制技术（如基于磁盘的复制技术等）复制到备机的存储设备上。这种复制技术可以是同步复制方式或者异步复制方式，具体选择取决于两个站点的距离和对主机业务影响的要求。

采用的数据复制技术决定了灾备方案的 RPO 指标。传送或者复制过来的数据不能立刻被备机数据库使用，需要经过一个恢复过程来恢复数据的一致性。故障检测时间、数据库恢复时间和其它服务恢复时间一起，决定了灾备方案的 RTO 指标。

1.2 高可用性 (HA) 的概念

业务系统的可用性是指业务的运行时间占全部时间的比例。可以用下面的公式来表示：

可用性 = 1 - 业务宕机时间 / ( 业务宕机时间 + 业务运行时间 )

业务的不可用程度直接和企业的经济损失数值相关，因此所有企业都非常关注业务可用性指标。可用性越高，就表示业务宕机的时间比例越小。高可用性即指可用性很高（如 99%），宕机时间很少。在高可用性之外还有一个术语叫连续可用性（Continuous Availability），指业务连续运转完全不宕机，可用性为 100%。

实现高可用的关键在于采用冗余的设备或配置来减少系统中的单点失效环节。比如，建立高可用数据库管理系统集群可以去除数据库管理系统的单点失效，实现数据库管理系统的高可用性。采用具有数据冗余性的存储设备，可以提高数据库存储的高可用性。采用冗余的数据连接和网络连接，提高数据连接和网络连接的可用性。建立服务器集群，可以提高服务器高可用性。建立灾备站点，可以提高整个站点的可用性。

根据针对的失效类型，可以把高可用性方案分为几个等级：

1. 存储（或数据）高可用性，采用具有数据冗余性的存储设备保护磁盘数据
2. 部件高可用性，比如采用冗余的硬件设备或软件模块，保证某种部件的高可用性
3. 系统高可用性，通过建立系统集群，这可以保证系统上所有服务的高可用性
4. 站点高可用性，可以在整个站点发生故障时切换到备用站点

1）、2）和 3）是针对软硬件故障而设计的，这种高可用方案一般部署在单个数据中心站点里。4）不仅可以应付软硬件故障，还可以应付站点级的灾难，只要部署在相隔比较远的两个站点里。

传统上，数据库系统的高可用性可以通过构建集群来实现。可以构建专用的数据库集群（如 Oracle RAC，DB2 pureScale），不但提高可用性同时也扩展数据库处理能力。也可以利用系统集群软件构建整个系统的高可用集群。在各种主流操作系统上都有集群软件，可以支持构建各种数据库的高可用性集群，如：

• AIX: HACMP (High Availability Cluster Multi-Processing)
• HP-UX 和 Linux: HP Multi-Computer/ServiceGuard High Availability Software
• Solaris: Sun Cluster for Solaris
• Windows：Microsoft Cluster Server
• 适用于所有操作系统的通用集群软件：Tivoli System Automation，Veritas Cluster Server

在高可用系统集群中，多采用主机 - 备机（Active-Standby）的部署方式。主站点的数据库系统用来处理业务，备站点的数据库则处于待命状态。两个站点通过共享存储来共享数据（如图 1 所示）。在主站点发生故障时，集群软件可以通过心跳消息丢失迅速检测到故障，并自动将数据库服务在备用站点重新启动，完成故障切换过程。

图 1. 共享磁盘的服务器集群

1.3 数据库双活的概念

1.3.1 双活方案组成

所谓数据库双活（Active/Active），是指两个数据库系统，可以相隔非常远的距离（如几千公里），可以同时运行支持相同的应用负载，并且在一方出现故障时能够迅速切换到另一方。一个完整的数据库双活方案，一般需包括： - 两个数据中心 - 在两个数据中心的数据库之间双向复制应用级数据的异步复制软件 - 应用网关，负责负载均衡和分发 - 监控软件，监控所有部件的健康和性能状况 - 自动化的切换和回切工具

1.3.2 双活方案的优势

与传统的采用 Failover 模型的灾备或高可用方案相比，数据库双活方案具有如下优势： 1）提高了系统可用性。双活方案不但支持故障切换，而且由于两端数据库都处于工作模式下，切换时间会非常短（分钟级），保证了业务高可用性。 2）提高了容灾能力。双活方案里的两个数据中心可以相隔非常远，足以避免自然灾难造成的毁灭性后果。 3）扩展了系统处理能力。实现双活的两个数据中心具有负载均衡的配置，处理能力强于单一数据中心。 4）提高了资源利用率。两个数据中心的 IT 设施得到了充分利用，避免了传统模式下备机的资源闲置。

1.3.3 双活方案的不同配置方式

根据应用负载分配方式的不同，双活方案可以分成下面几种配置方式： - Active/Standby：主机处理读写类型的应用请求；备机完全处于闲置状态，不处理应用请求；数据从主机复制到备机 - Active/Query：主机处理读写类型的应用请求；备机处理只读类型的应用请求；数据从主机复制到备机 - Active/Active：主机和备机都处理读写类型的应用请求，这种情况下需要在应用设计层面尽量避免数据同时更改的冲突；数据在主机和备机间双向复制

1.3.4 双活方案常见切换场景

双活方案的切换不但包括传统的被动式的故障切换，还支持主动式的计划切换，以及由于性能指标变动引起的主动式切换。 - 计划外切换，如由部件故障引起的切换，发生时间不可预测 - 计划内切换，如由产品维护引起的切换，安排在预定的维护时间窗口中 - 基于性能原因的切换，如某端的数据复制延时过大或者处理能力下降，主动将部分应用负载切换到另一端，发生时间不可预测。这种切换只发生在 Active/Query 和 Active/Active 配置方式中。

2. 使用 Q 复制实现 DB2 高可用性和双活

本节我们讲述如何使用 IBM Q 复制技术来实现 DB2 数据库系统的双活。Q 复制将在这个双活方案中扮演数据库复制工具的角色。

2.1 Q 复制原理

Q 复制是 IBM 于 2004 年起推出的一种高性能的数据库间异步数据复制技术，主要支持 DB2 数据库，也支持 Oracle 数据库。它通过读取源数据库的日志记录来捕获数据变化，并将数据变化以数据库交易为单位通过 MQ 消息队列发送到目标服务器，最后在目标服务器将交易还原出来并提交至目标数据库。这个技术可以在以下产品中得到： - IBM InfoSphere Data Replication - InfoSphere Replication Server - IBM DB2 UDB - IBM InfoSphere Warehouse

下图 2 描述了 Q 复制中的关键组件：

图 2. IBM Q 复制部件

2.2 Q 复制特征

Q 复制技术具有如下技术特征：

1）高性能。在源端，Q 复制通过读取数据库日志来捕获记录变化，不使用数据库查询来获得数据。这样既避免了与源端的应用争抢访问数据库，减小了对应用的影响，又保证了变化捕获的高性能。在目标端，Q 复制使用了并发技术，保证了高性能地向目标数据库写入数据。 2）低延时。Q 复制通过 MQ 消息队列传输数据改动，减少了整个复制环节的 I/O 操作次数和等待时间，保证了数据复制的延时可以低到数秒之内。 3）保证目标端数据的交易一致性。Q 复制是以交易为复制的最小数据单位的，这样目标端数据总是处于交易一致性状态。 4）灵活的配置方式。Q 复制是表级复制技术，可以配置 Q 复制只复制特定应用负载所使用的表。还可以筛选需复制的行和列。 5）异步复制。Q 复制是一种异步复制技术，对应用影响小。需要注意的是，在源数据库出现故障时，异步复制可能会造成目标端数据丢失。 6）丰富的平台支持。Q 复制支持所有主流开放平台（AIX，HP-UX，Linux，SunOS，Windows）和大型机平台 z/OS。 7）支持异构数据库。Q 复制使用公开的标准接口访问数据库及日志，所以它支持在各种类型各种版本的 DB2 数据库和 Oracle 数据库间复制变动。 8）易于使用：Q 复制配套有图形化的配置工具复制中心，基于 WEB 的监控工具 Q 复制 Dashboard，和可编程式的命令行脚本工具 ASNCLP，使用非常灵活方便。

2.3 使用 Q 复制的双活方案

这个方案可以图示如下：

图 3. 使用 Q 复制的 DB2 数据库双活示意图

其中 Q 复制被用作在两个数据中心的 DB2 数据库之间的数据复制工具。在双活方案中使用 Q 复制有如下好处：

1）由于 Q 复制具有很低的复制延时，可以保证 RPO 比较低。如果是计划内停机情形，可以保证 RPO 为 0。 2）由于 Q 复制的目标数据库总是处于交易一致性状态，随时可用，可以保证切换时所需时间比较小，保证了 RTO 很低。 3）由于 Q 复制是异步复制技术，对 DB2 数据库的业务响应时间没有影响，距离的增大不会造成响应时间的增大，保证了远距离部署的可行性。 4）Q 复制的目标数据库随时可用且复制延时较低，所以不但可以用于执行对复制延时不敏感的报表型查询应用，还可以执行对数据延时比较敏感的只读或者读写型 OLTP 应用，提高了负载处理能力和资源利用率。 5）Q 复制支持所有的双活配置方式：Active/Standby，Active/Query，Active/Active。

2.4 双活切换场景

下面我们来描述一下 Q 复制在各种典型切换场景中是如何工作的。

2.4.1 故障切换场景

Active/Standby 方式

– 主站点 A 故障 在主站点 A 发生故障的情况下，备用站点 B 等待源端 Q 复制已经发送到站点 B 的数据都被应用到数据库上，然后就可以把原来分配到站点 A 的所有应用负载切换到备用站点 B。在备用站点 B 新发生的数据改动会被 Q 复制捕获并发送出去。由于主站点 A 不可用，所以改动的数据会被暂存在站点 B 的 MQ 消息队列中。 在主站点 A 恢复后，暂存在站点 B 的 MQ 消息队列中的数据会被传送到站点 A，并被站点 A 的 Q 复制程序应用到数据库上。完成后待 Q 复制延时较低时可以把所有应用切换回主站点 A，重新回到 Active/Standby 状态。 – 备用站点 B 故障 没有影响。在备用站点 B 恢复后，Q 复制会自动把期间主站点 A 上发生的数据改动复制到备用站点 B。

Active/Query 方式

– 主站点 A 故障 与 1) 的主站点 A 故障非常相像。 在主站点 A 发生故障的情况下，查询站点 B 等待源端 Q 复制已经发送到站点 B 的数据都被应用到数据库上，然后就可以把原来分配到站点 A 的所有应用负载切换到备用站点 B。这时站点 B 为所有的应用负载提供服务。在查询站点 B 新发生的数据改动会被 Q 复制捕获并发送出去。由于主站点 A 不可用，所以改动的数据会被暂存在站点 B 的 MQ 消息队列中。 在主站点 A 恢复后，暂存在站点 B 的 MQ 消息队列中的数据会被传送到站点 A，并被站点 A 的 Q 复制程序应用到数据库上。完成后待 Q 复制延时较低时可以把读写型应用切换回主站点 A，在站点 B 只留下查询型应用，重新回到 Active/Query 状态。 – 查询站点 B 故障 在查询站点 B 发生故障的情况下，可以把原来分配到站点 B 的所有查询型应用负载切换到主站点 A。这时站点 A 为所有的应用负载提供服务。在站点 A 发生的数据改动会被 Q 复制捕获并发送出去。由于查询站点 B 不可用，所以改动的数据会被暂存在站点 A 的 MQ 消息队列中。 在查询站点 B 恢复后，暂存在站点 A 的 MQ 消息队列中的数据会被传送到站点 B，并被站点 B 的 Q 复制程序应用到数据库上。完成后待 Q 复制延时较低时可以把最初分配给查询站点 B 的查询型应用负载切换回查询站点 B，重新回到 Active/Query 状态。

Active/Active 方式

– 站点 A 故障 与 1) 的主站点 A 故障非常相像。 在站点 A 发生故障的情况下，站点 B 等待源端 Q 复制已经发送到站点 B 的数据都被应用到数据库上，然后就可以把原来分配到站点 A 的所有应用负载切换到站点 B。这时站点 B 为所有的应用负载提供服务。在站点 B 新发生的数据改动会被 Q 复制捕获并发送出去。由于站点 A 不可用，所以改动的数据会被暂存在站点 B 的 MQ 消息队列中。 在站点 A 恢复后，暂存在站点 B 的 MQ 消息队列中的数据会被传送到站点 A，并被站点 A 的 Q 复制程序应用到数据库上。这时可以把最初分配到站点 A 的读写型应用切换回站点 A，在站点 B 只留下部分读写负载，重新回到 Active/Active 状态。

2.4.2 运维切换场景

Active/Standby 方式

- 主站点 A 计划内系统维护 在维护开始后，首先主站点 A 暂停接受应用负载。等待主站点 A 上的所有数据改动都已被 Q 复制应用到备用站点 B 的数据库上，然后就可以停止主站点 A 的数据库和 Q 复制程序（包括 MQ），把原来分配到站点 A 的所有应用负载切换到备用站点 B。在备用站点 B 新发生的数据改动会被 Q 复制捕获并发送出去。由于主站点 A 不可用，所以改动的数据会被暂存在站点 B 的 MQ 消息队列中。在主站点 A 维护完成后重新启动数据库和 Q 复制程序（包括 MQ），暂存在站点 B 的 MQ 消息队列中的数据会被传送到站点 A，并被站点 A 的 Q 复制程序应用到数据库上。完成后待 Q 复制延时较低时可以把原来分配到站点 A 的所有应用负载切换回主站点 A，重新回到 Active/Standby 状态。 - 备用站点 B 计划内系统维护 只需要停止备用站点 B 的数据库和 Q 复制程序（包括 MQ），等维护结束后重新启动即可。Q 复制会自动把维护期间主站点 A 上发生的数据改动复制到备用站点 B。

Active/Query 方式

- 主站点 A 计划内系统维护 与 1) 的主站点 A 计划内系统维护非常相像。 在维护开始后，首先主站点 A 暂停接受应用负载。等待主站点 A 上的所有数据改动都已被 Q 复制应用到查询站点 B 的数据库上，然后就可以停止主站点 A 的数据库和 Q 复制程序（包括 MQ），把原来分配到站点 A 的所有应用负载切换到备用站点 B。在查询站点 B 新发生的数据改动会被 Q 复制捕获并发送出去。由于主站点 A 不可用，所以改动的数据会被暂存在站点 B 的 MQ 消息队列中。 在主站点 A 维护完成后重新启动数据库和 Q 复制程序（包括 MQ），暂存在站点 B 的 MQ 消息队列中的数据会被传送到站点 A，并被站点 A 的 Q 复制程序应用到数据库上。 完成后待 Q 复制延时较低时可以把原来分配到站点 A 的所有应用负载切换回主站点 A，在站点 B 只留下查询型应用，重新回到 Active/Query 状态。 - 查询站点 B 计划内系统维护 在维护开始后，把原来分配到站点 B 的所有查询型应用负载切换到主站点 A，然后停止查询站点 B 的数据库和 Q 复制程序（包括 MQ）。这时站点 A 为所有的应用负载提供服务。在站点 A 发生的数据改动会被 Q 复制捕获并发送出去。由于查询站点 B 不可用，所以改动的数据会被暂存在站点 A 的 MQ 消息队列中。 等查询站点 B 维护结束后重新启动数据库和 Q 复制程序（包括 MQ）。暂存在站点 A 的 MQ 消息队列中的数据会被传送到站点 B，并被站点 B 的 Q 复制程序应用到数据库上。完成后待 Q 复制延时较低时可以把最初分配给查询站点 B 的查询型应用负载切换回查询站点 B，重新回到 Active/Query 状态。

Active/Active 方式

- 站点 A 计划内系统维护 与 1) 主站点 A 计划内系统维护非常相像。 在维护开始后，首先站点 A 暂停接受应用负载。等待站点 A 上的所有数据改动都已被 Q 复制应用到站点 B 的数据库上，然后就可以停止站点 A 的数据库和 Q 复制程序（包括 MQ），把原来分配到站点 A 的所有应用负载切换到站点 B。在站点 B 新发生的数据改动会被 Q 复制捕获并发送出去。由于站点 A 不可用，所以改动的数据会被暂存在站点 B 的 MQ 消息队列中。 在站点 A 维护完成后重新启动数据库和 Q 复制程序（包括 MQ），暂存在站点 B 的 MQ 消息队列中的数据会被传送到站点 A，并被站点 A 的 Q 复制程序应用到数据库上。完成后待 Q 复制延时较低时可以把原来分配到站点 A 的所有应用负载切换回站点 A，重新回到 Active/Active 状态。

2.4.3 性能切换场景

如果从一个站点向另一个站点的 Q 复制延时过大，那么运行在目标站点的应用负载运行结果的有效性就会受到影响，这时候也需要启动切换。

Active/Query 方式 - 查询站点 B 数据复制延时过大 在查询站点 B 观察到复制延时过大的情况下，可以把原来分配到站点 B 的所有查询型应用负载切换到主站点 A。这时站点 A 为所有的应用负载提供服务。在站点 A 发生的数据改动会被 Q 复制捕获并发送出去，并最终应用到站点 B。 在查询站点 B 的复制延时恢复到较低时，可以让站点 A 暂停接受最初分配给站点 B 的那部分查询应用的请求，等站点 A 此前发生的所有变化都已经由 Q 复制应用到站点 B 的数据库上， 然后就可以把最初分配到站点 B 的查询型应用负载切换回查询站点 B，重新回到 Active/Query 状态。

2) Active/Active 方式 - 站点 B 数据处理延时过大 在站点 B 观察到复制延时过大的情况下，可以让站点 B 暂停接受应用请求，等站点 B 发生的所有变化都已经由 Q 复制应用到站点 A 的数据库上，然后就可以把最初分配到站点 B 的所有 应用负载切换到站点 A。这时站点 A 为所有的应用负载提供服务。在站点 A 新发生的数据改动会被 Q 复制捕获并发送出去，并最终应用到站点 B。 在站点 B 的复制延时恢复到较低时，可以让站点 A 暂停接受最初分配给站点 B 的那部分应用的请求，等站点 A 此前发生的所有变化都已经由 Q 复制应用到站点 B 的数据库上， 然后就可以把最初分配到站点 B 的所有应用负载切换回站点 B。重新回到 Active/Active 状态。

3. 基于 Q 复制的双活方案与 HADR 方案的对比

DB2 数据库自身还带有一个 HADR（High Availability Disaster Recovery）特性，也可以用来实现 DB2 数据库的灾备和高可用性。如图 4 所示：

图 4. DB2 HADR 示意图

DB2 HADR 是一个数据库级的复制方案。如图 4 所示，HADR 的主节点通过 log shipping 技术将 log 记录发送到目标节点，目标节点通过不断前滚这些 log 记录，保证和主节点的数据一致性。只有主节点才能处理读写型应用负载，备用节点可以工作在 standby 状态下或者处理只读型的查询。DB2 HADR 要求两端的 DB2 数据库的版本及操作系统平台版本必须一致，并且不支持 DB2 分区数据库。 DB2 HADR 支持多种复制模式：同步，近同步，异步，超异步。同步复制方式可以用来构建距离比较近的灾备节点，异步和超异步复制方式则可以用来构建距离比较远的高可用节点。虽然和 Q 复制一样可以用于高可用性方案，但 DB2 HADR 和 Q 复制有很多区别，需要根据实际的需求和场景来选择合适的技术。下表 1 列出了 Q 复制和 DB2 HADR 的对比：

表 1：Q 复制和 DB2 HADR 的对比

事实上 Q 复制可以和 DB2 HADR 结合使用以构 R 构建同数据中心或者同城高可用集群，而使用 Q 复制构建异地甚至异构高可用方案。

4. 总结

数据库双活是一个比较新的概念，可以同时满足企业在业务高可用、数据容灾、性能扩展和提高资源利用率方面的需求。IBM Q 复制技术是一种高性能低延时的应用级异步数据库复制方案，非常适合于构建数据库双活系统。

本文作者：

刘 亚, IBM 中国开发实验室的软件工程师, IBM

刘 艳, IBM 中国开发实验室的软件工程师, IBM

张 荷芳, IBM 中国开发实验室的软件工程师, IBM

声明： 此文观点不代表本站立场；转载须要保留原文链接；版权疑问请联系我们。