DB2的高可用性和灾难恢复概述

核心提示：【导读】数据的高可用性和灾难恢复的能力是对关键数据库系统的主要需求，本文概述了 DB2 UDB 的特性，DB2的高可用性和灾难恢复概述，这些特性提供了这些能力，并且让您知道它们的优缺点，结束语DB2 为构建高可用性和灾难恢复解决方案提供了出色的技术，您应该根据您的业务需求、可用选项和解决方案需求来做出选择，这样您就可以

【导读】数据的高可用性和灾难恢复的能力是对关键数据库系统的主要需求。本文概述了 DB2 UDB 的特性，这些特性提供了这些能力，并且让您知道它们的优缺点，这样您就可以判断哪种方法最适合您。简介

高可用性和灾难恢复是关键数据库应用程序的重要需求。IBM DB2 通用数据库（DB2）提供了许多特性来满足这些需求。如果您还不熟悉分布式平台上的 DB2，或者即使您已用了一段时间，您也许仍会觉得处理可用性和恢复的许多特性令人感到迷惑。您何时使用哪一种特性，当您使用它时，您可以希望完成什么？

本文旨在概述这些特性，并指导您理解如何使用 DB2 技术来构建高度可用和可恢复的数据库系统。此外，每种解决方案都有其成本以及独有的优点，因此我们将讨论它们的优缺点。

在开始之前，让我们先研究术语高可用性（high availability，HA）和灾难恢复（disaster recovery，DR）。在运用 HA 和 DR 的技术中，它们经常有相交的地方，但它们有两个不同的用途。

高可用性是这样一种需求：每当需要时，数据就可用于从属应用程序。其目的是消除或最小化停机时间。

灾难恢复防止由于毁灭性的故障而导致数据丢失。这类故障意味着由于不可恢复的情况而丢失数据。

术语和客户机／服务器数据库体系结构

我们将首先讨论一些术语和概念，当讨论高可用性和灾难恢复时，应该要理解这些术语和概念。

在数据库体系结构讨论中经常会用到术语 群集（cluster）。有两种类型的 DB2 数据库群集： 高可用性和 高可伸缩性（high scalability）。虽然在一个解决方案中可以结合这两种群集，但应该将它们看作是互斥的实体。高可伸缩性群集（也称作数据库分区）结合了多台服务器的聚集能力以产生高性能解决方案。该技术通常用于构建数据仓库或大型事务系统，而在这样的数据仓库或系统中，单个服务器是无法实现性能目标的。高可用性群集产生一个能最大化数据库正常运行时间的系统。在本文中，术语“群集”仅指高可用性群集。

HA 数据库解决方案有三个部分：

用户应用程序

客户机软件

数据库引擎

当设计 HA 解决方案时，应该考虑所有这三个方面。仅使数据库引擎成为高度可用并不一定能创建出 HA 解决方案。本文的重点是数据库引擎正常运行时间，但您应该将这一问题看作只是整体解决方案的一部分。

数据库应用程序是基于客户机／服务器的。应用程序依靠数据库软件的完整性来产生一致的结果。虽然这看起来似乎相当明显，但当选择和设计解决方案时理解如何实现这一点非常重要。

当应用程序提交 SQL 事务时，在可以假设事务完成之前它必须接收返回码。应用程序并不与数据库引擎直接交互。事务经由客户机软件传递到引擎。由客户机软件将响应返回给应用程序。正的返回码表示成功的情况，而负的返回码表示失败。应用程序如何处理这些情况对于整体 HA 解决方案很重要。通过包含返回码逻辑，尤其是关于事务失败的，应用程序可以使 HA 解决方案对于最终用户显得更加天衣无缝。

数据库引擎通过实现事务日志来确保完整性，事务日志存储了所有插入、更新和删除活动。事务日志确保了数据库更改只在应用程序发出提交语句后接收到正的返回码时才算完成。事务日志是 HA 和 DR 解决方案的基础部分。

在可以提交 SQL 事务之前，必须建立到数据库的连接。CONNECT 语句用于建立数据库连接，但有一些基本特性会影响连接被路由到哪里。客户机软件有两个目录告诉它如何路由数据库连接尝试：

节点目录（node directory）列出了服务器的位置（服务器的 IP 地址或主机名）和数据库服务器用于侦听数据库连接尝试的端口。

数据库目录（database directory）列出了数据库名称、数据库别名和节点目录中用于建立连接的对应项。

当应用程序发出 CONNECT 语句时，会搜索数据库目录来查看是否存在这个数据库名或数据库别名。如果这一项的类型是“indirect”，那么数据库是本地的，并通过共享存储段建立该连接。如果这一项的类型是“remote”，那么节点名用于指向节点目录中的正确项。节点目录信息允许客户机软件正确路由连接尝试。通过了解客户机如何通过目录结构建立数据库连接，在您规划 HA 解决方案时就可以规划资源移动。

高可用性

选择高可用性解决方案很大程度上取决于客户的业务需求。有两种类型的高可用性可供选择： 持续可用性（continuous availability）和 故障转移可用性（failover availability）。

持续可用性

持续可用性要求数据库引擎可随时用于处理 SQL 事务。这类可用性通常只在最关键的应用程序中实现。要实现这个目标，要求百分之百的冗余。那意味着您必须有两个完全互相独立（包括在硬件和软件方面）的系统。

基本上，SQL 事务在这两个系统上发生。一个系统发生故障不会造成其伙伴系统上事务的处理发生中断。要使这成为现实，应用程序必须知道这两个系统，并且将每个事务实现为跨两个系统的 分布式工作单元（distributed unit of work，DUOW）。DUOW 是作为在系统之间协调的一个事务而执行的一系列 SQL 语句。应用程序将事务提交给这两个系统，并从这两个系统接收关于成功或失败的返回码。然后应用程序可以继续处理另一个 DUOW 或执行另一种操作。如果发生故障，其中一个数据库系统不能再为应用程序提供服务，则应用程序（被编码为可以捕获该错误）可以利用另一个系统继续处理它的工作负载，而不会发生中断。

要实现 DUOW 需要类型 2 数据库连接和事务监视器。类型 2 数据库连接建立了适合于 DUOW 的环境。事务监视器负责实现 DUOW 并确保完成或回滚 DUOW 中的事务。DB2 可以充当事务监视器或者您可以使用另一家软件供应商（如 Microsoft 或 BEA）的事务监视器。

图 1说明了通过使用 DUOW 提供的持续可用性解决方案。

图 1. 分布式工作单元

表 1. 持续可用性解决方案的优缺点

优点：	缺点：
100％ 正常运行时间	需要重复的硬件
	需要额外的应用程序编码

现在，我们将转到下一个高可用性解决方案。

故障转移可用性

故障转移可用性与持续可用性的区别在于：数据库引擎会有一段时间（尽管时间很短暂）无法用于事务处理。这种解决方案的基本元素有：

主系统和辅助系统

故障检测

数据源移动

两个系统都有数据库数据的副本，当检测到故障时，就会发生 故障转移。在故障转移过程中，数据源从主系统移到辅助系统。

有两种故障转移可用性： 同步（synchronous）和 异步（asynchronous）。同步可用性保证了主系统和辅助系统上的数据源是一致的，而且在故障转移之后维持完整的连续性。异步可用性不保证主系统和辅助系统数据库是完全同步的。将数据库更改从主系统移到辅助系统的方法会不同，但这个过程会生成一个时间窗口，在这段时间内数据还没有从一个系统迁移到另一个系统。数据量也许会非常小，时间窗口可能会非常短，但您在决定解决方案时必须要考虑这一点。

让我们研究可以向您提供同步或异步故障转移可用性的选项。

专用的 HA 软件选项

同步方法涉及数据库软件与专用 HA 软件的紧密集成以产生 HA 群集。HA 软件支持由于操作系统平台的不同而不同。常用的 HA 解决方案有：

High Availability Cluster Multiprocessing（HACMP — AIX）

Microsoft Cluster Server（MSCS）— Windows

Sun Cluster — Sun

Steeleye 的 Lifekeeper — Linux 和 Windows

这些是我列出的针对各平台的最常见选项。还有其它一些 HA 软件解决方案，也可以使用它们。

所有这些解决方案的工作方式基本相同。如果有故障，数据库服务器可以从一台机器移到备份系统上。要完成该任务，HA 软件会将所有必需的资源移到辅助系统。这些资源包括物理数据库的磁盘资源、网络资源和数据库服务器资源。

在 HA 群集解决方案中，单个物理数据库副本存储在共享存储系统上。在 DB2 环境中，一次只能有一个系统“拥有”存储器阵列。当检测到故障时，存储器的所有权就会从主系统转移到辅助系统。同时也会转移网络资源。最后，在辅助系统上启动数据库服务器资源，使数据库变为可用。

故障的检测由服务器之间的“心跳”连接执行。这个“心跳”是 HA 软件的一个功能，它可以察觉硬件和软件故障。

由于只有一个数据库的副本，所以它始终是同步的。数据库引擎的故障转移和重新启动的时间取决于以下因素：

检测故障所需的时间

移动数据库资源相关资源（存储阵列和联网资源等）所必需的时间长度

DB2 引擎执行崩溃恢复所需的时间

当数据库没有正确关闭时，DB2 总是会执行崩溃恢复。崩溃恢复是日志文件的处理，从而确保将所有已提交的事务都写到磁盘并且回滚未提交的事务。执行该操作所需的时间取决于发生故障时数据库日志中“打开”工作的量。整个故障转移可能只需要几秒钟，如果要从日志文件中处理的工作量很大，可能会需要更长时间。

这种可用性解决方案的一个优点是它不需要对应用程序或客户机配置目录做任何更改。HA 软件为数据库连接提供了一个虚拟的 IP 地址资源。当检测到故障时，该 IP 地址就会进行故障转移，应用程序可以使用它以前使用的同一条连接语句。发生故障转移时，所有应用程序都会断开连接，客户机会将通信错误情况返回给应用程序。一旦数据库服务器在辅助系统上运行之后，应用程序只要重新发出连接语句，就可以象以前一样继续处理工作了。

这也称作 热备用（hot standby）配置。但是，在等待故障转移时，辅助系统并不一直空闲。也可以以 相互接管（mutual takeover）配置来配置系统，在该配置中，这两个服务器都主动地主管不同的数据库。每台机器都准备在发生故障时接管其伙伴的工作负载。

图 2. 专用的 HA 软件选项

表 2. 专用 HA 软件选项的优缺点

优点：	缺点：
数据库始终是同步的	需要额外的软件来创建和配置解决方案
不需要更改应用程序或客户机	没有复制数据，因此提供较少的冗余
不需要用户交互来检测和初始化故障转移	需要必须符合一些 HA 标准的外部存储器
性能不受额外工作负载的干扰	由于硬件需求，限制了服务器之间的距离

数据复制选项

DB2 UDB 包含了集成复制能力。DB2 的复制实现包括两部分： Capture（捕获）和 Apply（应用）。复制管理员指定表中要复制的复制源，然后通过使用前一步中的复制源作为其来源，在目标数据库（辅助系统）上创建复制预订。Capture 进程监控事务日志以获取对复制源表的所有更改，然后将对这些表的任何更改放到登台表中。Apply 程序定期读取登台表并将更改转移到预订目标。

数据复制是一个异步过程。在已更改的数据还没有放到登台表中或者 Apply 程序还没有将更改复制到目标系统期间，这两个数据库不是同步的。这不一定是一段很长的时间或很大的数据量，但必须考虑这一可能性。

复制有几个好的特性。它允许：如果不需要整个副本，可以只复制数据的子集。只要有足够的网络带宽满足用户的需要，距离就不是问题。复制还允许在使用 IBM 的 Information Integrator 产品的情况下，可以在一个独立的平台或不同的数据库管理系统上托管辅助系统。这两个系统都是“活动的”，因此可以完成独立的工作。例如，一个系统可以用于处理事务，而辅助系统可以用于创建报告或运行备份。

复制只捕获对源表的更改。它不会捕获对系统目录的更改。例如，必须在两个系统上都执行对表许可权的更改，因为复制无法复制这项更改。

此外，故障转移过程不是自动的。发生故障后，系统管理员必须在客户机上进行更改，这样他们才可以针对辅助系统工作；或者在辅助系统上做更改，使它可以模拟主系统。这将允许应用程序按以前那样继续工作，而不必更改应用程序编码。一个替代方法是使用诸如 IBM 的 Edge Server 之类的产品来管理服务器连接。如果应用程序是用户应用程序，那么用户只要连接到辅助数据库，而不必对客户机配置或数据库服务器做任何实际的更改。

运行复制有一些开销。额外的工作量取决于对源表的插入、更新和删除活动的量。不需要对基本表进行额外的锁定，因为复制只分析日志文件，而不会分析基本表。但登台表（更改表）的填充和这些事务的日志记录需要数据库资源。

图 3说明了用于高可用性的复制选项。

图 3. 复制

表 3. 复制解决方案的优缺点

优点：	缺点：
集成能力，不需要额外的软件	过程是异步的，可能会因故障而丢失数据
在两个地方复制数据，冗余更大	不会自动进行故障转移，需要手工处理（或使用 Websphere Edge Server）
灵活的体系结构	不能复制所有数据库更改
距离限制较少	主系统上有额外的工作负载
辅助系统可以执行第二份工作负载

日志传送选项

所有数据库更改（插入、更新或删除）都记录在 DB2 事务日志中。事务日志主要用于崩溃恢复和在故障之后恢复系统。正如我们已经讨论的，它们在复制中发挥作用。此外，它们还可用于另一个高可用性解决方案 日志传送（log shipping）。该 HA 方案类似于数据复制选项。它要求辅助系统准备好在主系统发生故障时进行接管。管理员通过恢复主系统数据库的备份来创建这个辅助系统。通过恢复主系统的数据库备份，备份系统将处于前滚暂挂状态。事务日志从主系统转移到辅助系统，并用于使数据库前滚以完成事务。如果发生故障，管理员应停止前滚过程，并且使数据库联机。

可以用几种方式完成转移日志文件的过程。主要方法是使用 DB2 的 用户出口（user exit）工具。用户出口是当事务日志已满并准备归档时调用的可执行应用程序。数据库引擎将日志文件传递给用户出口，用户出口逻辑将执行所有必需的工作。用户出口可以制作日志的副本、将它发送到磁带设备、调用另一个程序或执行它被编码来处理的任何例程。一个可能的选项是将日志文件复制到辅助系统可以读取日志并应用日志中包含的事务的位置。

与复制选项相同，日志传送是一个异步过程。只要主系统上有活动日志文件并且还有未应用且未完成的日志文件，辅助系统就处于不同步状态。

DB2 确实有执行双日志记录的能力。这允许数据库在不同卷上创建复制日志文件，从而增加冗余。此外，该方法不会在数据库服务器上产生额外的开销。与使用复制不同，该方法不会创建两个活动的系统，因为备份系统在被管理员停止前滚暂挂状态之前一直处于不可用状态。

图 4说明了日志传送过程。

图 4. 日志传送

表 4. 日志传送的优缺点

优点：	缺点：
集成能力，不需要额外的软件	过程是异步的，可能会因故障而丢失数据
在两个地方复制数据，冗余更大	不会自动进行故障转移，需要手工处理
距离限制较少	辅助系统是被动的，只提供备份能力
活动系统上没有额外工作负载

高级存储选项

现代的存储子系统提供了许多高级特性。DB2 已经能够利用这些高级特性来创建高可用性和灾难恢复系统。虽然这些技术可能会不同，但高级存储选项的基本要素就是能够快速创建磁盘卷的相同副本。然后可以将这些卷安装到辅助系统上。辅助系统可以充当备份系统或执行其它一些类型的工作负载。允许实现这一功能的 DB2 特性叫作 暂挂 I/O（suspended I/O）。

暂挂 I/O 这项技术允许数据库引擎使数据库处于一致状态，同时又保持联机。暂挂 I/O 状态暂挂写 I/O 操作，以防止对数据表空间和日志的写操作。在数据库离开暂挂 I/O 状态之前，该数据库仍可用于所有应用程序，处理只读语句和延迟写语句（插入、更新和删除）。通过 SET WRITE SUSPEND 命令将数据库置为暂挂状态。暂挂数据库之后，就可以制作数据库的物理文件的副本。将需要数据库目录、日志文件和数据库容器的副本。存储硬件和软件通过分割镜像卷或其它高级复制技术，可以非常快地创建大量数据的副本。然后，所复制的卷可以用于创建备份系统。制作了副本之后，可以使用 SET WRITE RESUME 命令来继续处理主系统上的所有事务。

所复制的卷可以与 DB2INIDB 实用程序一起用来创建辅助系统。该实用程序有三个实现：SNAPSHOT、STANDBY 和 MIRROR：

SNAPSHOT 实现只允许数据库执行崩溃恢复。创建了一个复制的数据库，但在恢复期间不回滚任何事务。该方法适用于创建测试环境或报告机器。它不提供用于数据库恢复的方法，因此不应用作 HA 选项。

STANDBY 和 MIRROR 方法允许创建恢复实现。在这两种情况下，DB2INIDB 工具使数据库处于前滚暂挂状态。然后可以将主系统中的日志文件应用到备份系统。如果主系统发生故障，那么辅助系统将离开前滚暂挂状态并联机，准备处理事务。用 STANDBY 还是用 MIRROR 方法取决于如何应用日志以及如何使数据库恢复联机。

STANDBY 方法使数据库在独立于主系统的位置恢复联机，并允许在主系统处于暂挂状态时，在辅助系统上进行数据库备份。

MIRROR 方法用所复制的卷替换原来的卷，而处理将在相同的位置中发生。

如我在日志传送部分所提到的，DB2 能够生成双日志。通过将日志放在不同的卷上，该能力可以与高级存储选项一起使用来确保日志的完整性。DB2 用户出口程序可以用于存储和检索日志文件，并管理已归档日志文件的位置。可以对用户出口进行编码，以将日志放到辅助系统或另一个可用位置上。

图 5显示了高级存储选项。

图 5. 高级存储

表 5. 高级存储的优缺点

优点：	缺点：
集成能力，不需要额外的软件	过程是异步的，可能会因故障而丢失数据（这可以用双日志记录来弥补）
在两个地方复制数据，冗余更大	不会自动进行故障转移，需要手工处理
能够迅速地复制大量数据	辅助系统处于前滚暂挂状态，不可用
捕获所有数据库更改	需要高级硬件

灾难恢复

建立灾难恢复计划对于现代企业至关重要。企业数据库中的信息对于进行业务活动是极其重要的。保护该数据以及在灾难之后确保其“生命”是很重要的活动。当构建 DR 计划时，有三个关键问题：

需要防止的故障级别

可接受的数据丢失量

允许用于恢复的时间量。

要防止的故障级别通常是近似性问题。原始数据与其备份之间在物理上有多紧密？备份数据可以在不同的驱动器上、在独立的机器上、在独立的楼层上或在不同的建筑物里。不可能预测所有可能的灾难。火灾、水灾或甚至用户的恶作剧都可能是企业必须面对的问题。解决方案的设计应该包括公司希望防止最坏情况的方案。

所有企业都不希望在故障之后丢失任何数据。虽然不丢失数据是可能的，但由于可能需要的复杂性和费用（尤其是如果所防止的故障级别非常高），这通常是不实际的。可接受的数据丢失量取决于数据对公司有多重要以及有什么资源可用于确保其生命。

恢复所需的时间量类似于高可用性的目标。它与高可用性解决方案之间的差异在于所防止的故障类型以及通常认为合理的时间长度。HA 故障转移通常以秒和分钟来衡量，而灾难恢复则可能以小时和天来进行衡量。不过并非总是这样，但这个差异区分了对这些解决方案的相对期望。

备份和恢复

数据库备份创建了数据库的时间点映象，它是灾难恢复解决方案的基本组件。DB2 提供了几种备份，包括脱机备份、联机备份和增量备份。从备份恢复所需的时间取决于数据库的大小和可用于执行恢复的硬件资源。

由于数据库备份只捕获时间点的数据，因此无法通过一个简单恢复来恢复备份之后发生的任何数据更改。要恢复备份之后完成的事务，就需要应用日志文件。可以从备份和日志文件（通过在日志文件中进行“前滚”来应用）来恢复数据库。这允许恢复到某个时间点或恢复到日志文件结束。

因此，如果 DR 解决方案必须恢复自上次备份以来的事务，那么保留日志文件是非常关键的。有两个提高日志保留的 DB2 特性：双日志记录和用户出口工具，已在关于数据库复制 HA 选项的部分中进行了讨论。

灾难恢复方案

灾难恢复方案可以分成三类：

简单备份

备份和日志保留

高级存储备份

虽然不是每个解决方案都清晰地被划入这三类中的某一类，但它们确实为您理解灾难恢复选项提供了合理的框架。

简单备份

只创建数据库备份确实创建了一个 DR 解决方案。它也许是非常有限的，这取决于您的环境。通过从“活动”的系统上移走所创建的备份，可以提高保护的级别。增加数据库备份的频率也降低了数据丢失的风险。

备份软件对于创建和维护 DB2 备份可能非常有帮助。例如，IBM 的 Tivoli Storage Manager 和 Veritas 的 Net Backup® 都提供了允许在其软件控制的设备上直接备份和维护 DB2 数据库的解决方案。这些设备可以是磁带库或另一种存储设备。

简单备份适合于只读数据库或由能轻松重新创建的批处理作业填充的数据库，或者在备份之间不必维护数据库更改的情况下。

表 6. 简单备份的优缺点

	优点：	缺点：
保护级别：	数据库备份可以转移到外部位置，以提高保护级别
数据丢失的风险：		备份之间的数据更改可能会丢失（运行增量备份来降低风险的影响）
恢复所需的时间：		数据库恢复需要很长时间

备份和日志保留

保留数据库日志文件与数据库备份一起创建了更完善的 DR 解决方案。日志文件允许恢复备份之间发生的数据更改。

该解决方案的真正复杂性在于保护日志文件以确保它们在恢复期间的可用性。如果选择实现双日志记录，DB2 可以将日志文件放在不同的位置，如果确保这些位置在不同的存储器阵列上，那么保护级别就会得到提高。

但是，日志文件仍面临存储子系统故障。如在高可用性的日志传送选项中所提到的，用户出口程序可以提供重定位日志文件的替代方法。用户出口可以将已关闭的日志文件移到当前系统可用存储阵列之外的位置，从而提高保护级别。这里的告诫是它只移动已关闭的日志文件。即使已实现了双日志记录，包含活动事务的日志文件仍面临因阵列丢失或存储设备故障而产生的丢失。

该解决方案适合于大多数面向商业事务的环境。它均衡了最小化数据丢失风险的需要和维护 DR 解决方案所需的成本。

表 7. 备份加日志保留的优缺点

	优点：	缺点：
保护级别：	数据库备份可以转移到外部位置，以提高保护级别
数据丢失的风险：	如果使用适当的步骤来维护日志文件，会大大降低数据丢失的风险
恢复所需的时间：		数据库恢复需要时间，应用日志文件将增加恢复时间

高级存储备份

我们在高可用性下的高级存储选项部分中讨论过这个主题，相同的原则在这里也适用。正如在那部分中所见的，STANDBY 方法允许当数据库副本处于暂挂状态时在辅助系统上执行数据库备份。

创建数据库副本已经创建了 DR 解决方案的一部分。备份副本提高了保护级别。如果用双日志记录和用户出口程序正确实现了这个高级存储备份，那么它就为核心企业数据库生成了最好的 DR 解决方案。

该解决方案最适合处于企业活动核心的数据库系统。示例可能包含了供应链管理和在线代理系统。

表 8. 用于灾难恢复的高级存储备份优缺点

	优点：	缺点：
保护级别：	保护级别本来就很高，而且可以通过耦合存储子系统来提高保护级别。
数据丢失的风险：	如果采用双日志记录和用户出口程序，会大大降低数据丢失的风险
恢复所需的时间：	恢复所需的时间非常短。

结束语

DB2 为构建高可用性和灾难恢复解决方案提供了出色的技术。您应该根据您的业务需求、可用选项和解决方案需求来做出选择。本文中讨论的这些要点为进一步研究和评估提供了一个很好的框架。