简介

　　高可用性和灾难恢复是关键数据库应用程序的重要需求。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. 分布式工作单元
 

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

　　故障转移可用性

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

• 主系统和辅助系统


• 故障检测


• 数据源移动

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

　　有两种故障转移可用性： 同步（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 软件选项的优缺点

　　数据复制选项

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

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

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

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

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

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

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

图 3. 复制

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