用 DB2 9.5 实现高可用性：选择正确的解决方案保护数据

核心提示：简介高可用性是重要数据库应用程序的关键需求，IBM DB2 9.5 提供了很多特性来满足这一需求，用 DB2 9.5 实现高可用性：选择正确的解决方案保护数据，如果您对分布式平台上的 DB2 还不是很了解，或者已经使用过一阵子，并提高了应用程序的可用性，结束语有很多选项可用于创建运行良好、高度可用的 DB2 解决方案，

简介

高可用性是重要数据库应用程序的关键需求。IBM DB2 9.5 提供了很多特性来满足这一需求。如果您对分布式平台上的 DB2 还不是很了解，或者已经使用过一阵子，您可能会发现这组处理可用性的特性令人困惑。什么时候使用哪个特性，当使用特性时，您希望完成什么目标？

本文的目的就是总结这些特性，并指导您理解如何使用 DB2 技术构建高度可用的数据库系统。此外，发现每种解决方案的成本和优点。

在开始之前，我们先来定义术语高可用性（HA）的意义。HA 是指要求在依赖性应用程序需要数据时能够提供数据。其目的是消除或尽量避免停机。与 HA 相关的一个术语是灾难恢复（Disaster Recovery，DR），DR 与 HA 的不同之处在于，它侧重于保护数据，防止因灾难性故障导致数据丢失。本文只关注 HA。

术语和客户机/服务器数据库架构

术语和客户机/服务器数据库架构

我们首先讨论一些术语和概念，这对理解高可用性十分重要。

一个数据库解决方案包括三个部分的软件：

用户应用程序

客户机软件

数据库引擎

除了软件，要得到一个有效的解决方案，还必须拥有一些其他资源：

服务器硬件

网络连接

磁盘存储

操作系统

当设计一个 HA 解决方案时，必须考虑所有这些方面。仅仅使数据库引擎高度可用未必就能创建出一个 HA 解决方案。HA 解决方案的设计并不完全是一个技术问题，它还必须考虑其他一些因素，例如解决方案的成本、技能需求以及管理需求。

数据库应用程序是基于客户机/服务器的。应用程序能否产生一致的结果，取决于数据库软件的完整性。虽然这一点是显而易见的，但是它在选择和设计解决方案时十分重要。

SQL 事务可分为两种类型：读和写。读事务是不需要插入、更新或删除活动的选择语句。而写事务则要更改至少一个数据库。读事务需要数据的一致视图 —— 即当同时提交两个读事务时，如果它们选择相同的数据范围，那么应该产生一致的结果集。写事务要求提交的数据库更改被持久化，即使出现故障时也是如此。业务需求会影响到什么 HA 解决方案是可用的或者是最适合的。通常，HA 解决方案的设计由两个因素驱动，正常运行时间（uptime）需求和事务一致性。如果业务要求更高的可用性，并且读一致性不是很重要，那么选择异步可能是更经济的方法。另一方面，如果事务一致性是关键需求，那么则需要选择更加同步的解决方案。如果事务一致性和可用性都是必需的，那么将进一步缩小可选择的范围。

高可用性

有两种类型的高可用性可供选择：持续可用性（continuous availability）和故障转移可用性（failover availability）。

持续可用性

持续可用性要求数据库引擎随时可用，没有可觉察的停机时间。在这些场景中，停机时间以不存在、一秒或数秒来度量。传统上，只会在最关键的应用程序中实现这种类型的可用性。为实现这个目标，需要有高度的冗余。

对于这些类型的系统，有三种基本的设计 —— 编程式（programmatic）可用性、共享（shared）可用性和多重副本（multiple copy）可用性。

编程式可用性

编程式的设计实际上是一个用户编程解决方案，它不是在数据库级实现的，而是在用户应用程序级实现的。实际上，应用程序在多个系统上实现 SQL 事务。一个系统上出现故障不会导致其他系统上的事务被中断。应用程序逻辑使应用程序即使在一个数据库系统出现故障时仍可以继续执行工作。

这种类型的系统具有最大的灵活性，但同时也要求实现大量的工作。当编写这些类型的环境时，DB2 对分布式工作单元和事务监视器的支持可以提供一定的帮助，但是大部分工作仍有赖于应用程序开发小组。编写的所有应用程序都必须支持您的设计。“开箱即用” 应用程序将不能理解您的环境。另外还需要解决其他问题：

保持数据库系统的同步

非确定函数的使用

非原子存储过程的使用

非确定函数是指根据不同的运行环境可能产生不同的输出的函数。例如，由于系统时钟不同步，或者语句不可能完全在同一时间到达系统，DB2 专用寄存器 CURRENT TIMESTAMP 在不同的系统上会产生不同的输出。

非原子存储过程是指不作为一个整体一起提交或回滚的存储过程。根据运行的环境，存储过程中的事务可能产生不同的结果。

表 1. 编程式可用性

优点	缺点
灵活性	应用程序开发时间和成本
	缺乏对打包应用程序的支持
	复杂性

共享可用性

共享设计在共享关键资源的同时使用冗余系统。这种共享设计是这样工作的：如果有 2 个或更多的系统在工作，当其中一个系统出现故障时，其他的系统可以继续工作。成员之间并非完全独立，而必须通过共享机制或数据才能执行它们的工作。

最常见的共享资源是物理数据存储。图 1 演示了数据如何被存储在一个中央存储系统上，并被三个成员访问。

图 1. 共享可用性

为了让这种架构能够正确地运行，需要共享的资源不仅仅是共享存储。为了让每个系统执行工作，它们必须共享一些类型的锁和锁机制。锁机制使得每个系统可以在共享数据上执行工作，同时不会执行对其他成员正在执行的工作造成干扰。例如，如果一个成员正在更新一行数据，那么另一个成员就不能以未提交读（uncommitted read）以外的任何隔离级别读取这一行。为了防止这样的事情发生，成员之间必须共享锁机制。为了确保一致的视图时间，必须实现一个共享锁机制。

这种架构的特点是高度复杂，并且要求硬件和软件的高度集成。必须解决的问题有：锁机制、系统计时器集成、数据缓冲区共享或非共享以及日志记录机制。如何实现这些机制对于性能和可用性有很大的影响。如果成员不共享数据缓冲区，那么每个成员就有可能缓冲相同的数据。如果数据的所有关系可以简单地在成员之间划分，那么您将拥有更好的数据缓冲，但是有可能遇到事务路由问题。如果需要处理一个更新事务，而该事务由不拥有那部分数据的成员接收，那么需要将它路由到另一个成员。显然，这种路由会影响性能，您可能被迫通过在应用程序中实现代码来将事务路由给正确的成员。如果一个成员出故障，那么可用性可能受到影响，影响的大小取决于其他成员必须做什么事情才能继续工作。理想情况下，不需要做任何事情，其他成员可以继续执行工作，并且可用性不受影响。然而，一些共享设计要求挂起或停止所有事务，并重新初始化缓存和锁机制。这实际上造成了停机时间，直到这些任务被完成为止。

数据共享环境中的 DB2 for zOS 诠释了共享架构的理想目标。这个环境的基础是 z Parallel Sysplex，它提供了 sysplex 计时器和耦合设施（coupling facilities）。耦合设施是高度集成的组件，通过它们可以创建锁设施和缓冲池等共享资源。此外，成员之间的通信技术是非常高效的。一个成员出故障不会影响其他成员的事务工作负载。除了更好的可用性外，还可以得到更大的容量和更好的工作负载平衡。不需要对应用程序做出更改，就能有效地使用这个解决方案。

用于非 zOS 平台的 DB2 不支持这种类型的架构。

表 2. 共享可用性

优点	缺点
非常高的可用性	高成本
增加可伸缩性	需要专门化硬件
不需要更改应用程序	实现需要专门化技能

多重副本可用性

多重副本设计利用数据库的多个副本，工作负载分布在这些副本上。当一个副本出现故障时，工作负载继续在其他数据库副本上运行。使用一个数据库的多个副本时要解决的最大问题是，如何保持它们同步，以及如何跨多个副本创建一致的查询结果。有些类型的复制解决方案是创建和同步这些副本的最简单方法。但是，由于传统复制解决方案固有的异步本性，我选择了在故障转移小节描述这个场景。

xkoto 中的 Gridscale 提供了另一种多重数据库副本解决方案，这种解决方案具有高级的同步过程和负载平衡。图 3 显示了 Gridscale 解决方案的基本架构。

Gridscale 在数据库解决方案中充当事务层。它可以根据可用性、系统利用率或同步状态将事务性工作发送到任何数据库副本。如果一个副本变得不可用，那么只需将工作转移到其他副本。它将根据系统负载将工作负载转移给其他副本。

写事务（插入、更新和删除）被同时发送到所有副本。Gridscale 跟踪在响应写事务时被同步的副本。当对写事务作出响应时，它们才有资格接收之后的读事务（选择）。这种机制确保事务性工作总是产生一致的结果。

可以集群化 Gridscale 系统来防止它成为故障点。Gridscale 实现了自己的可在几种条件下使用的缓存和事务日志记录。如果一个读事务被发送到一个出现故障或者在合理时间内未能返回的副本，那么可以将该事务路由到另一个副本。这个过程对应用程序是完全透明的。如果某种类型的故障或维护使一个副本不可用，那么可以根据 Gridscale 事务日志对它进行同步，这个过程完成后，它便可以开始参与分布式工作负载。要增加更多的副本以取得更大的可伸缩性，只需从一个副本恢复一个备份，并允许 Gridscale 将新的系统与其他副本同步。

DB2 和 Gridscale 解决方案的实现和管理非常简单。可以使用 Gridscale 管理工具来创建和同步副本。通过 Gridscale 工具，可以估计整个系统的工作负载，也可以估计每个副本的工作负载。您可以增加新的副本，并将工作从其他副本转移到新副本，以减轻其他副本的负载。这种灵活性使您可以执行滚动式系统维护。这里并不要求所有副本具有相同的修复包或发行版级别。您可以使副本下线，执行所需的软件或硬件维护，然后让 Gridscale 同步该系统，使之重新变得可用。

Gridscale 还解决了分布式副本遇到的很多其他问题。例如，非确定函数可以在 Gridscale 服务器中实现。在大多数场景中，Gridscale 不要求更改客户机应用程序。在客户端，DB2 驱动程序被一个 Gridscale 驱动程序替代，后者具有 Gridscale 特有的附加功能。对于 Java、DB2 CLI 和 .NET 应用程序，都有可用的 Gridscale 驱动程序。应用程序不知道 Gridscale 或事务层。

这种解决方案的总体效果是，不会因为单个或多个系统的故障而造成停机，具有更大的可伸缩性，而且成本更低。能降低成本的原因在于可以使用商用硬件，而不必购买大型的、更强大的机器或更高成本的存储系统。

图 2. 多重副本可用性


表 3. 多重副本可用性

优点	缺点
非常高的可用性	实现需要附加软件
增加可伸缩性	附加硬件管理
不需要更改应用程序
适度增加成本
易于实现和管理

故障转移可用性

故障转移可用性与持续可用性的不同之处在于，总有那么一段时间，不管这段时间有多么短，数据库引擎不能用于事务处理。这种解决方案的基本要素有：

主系统和辅助系统

故障检测

数据源移动

两个系统都有数据库数据的副本，或者都可以访问同一个副本，当检测到故障时，就会进行故障转移。在故障转移过程中，数据源从主系统移动到辅助系统。

有两种类型的故障转移可用性：同步和异步。同步可用性保证主系统和辅助系统上的数据源是一致的，完整的数据连续性是在故障转移之后维护的。而异步可用性则不保证主系统和辅助系统是完全同步的。将数据库从主系统移动到辅助系统的方法因情况而异，但是这个过程总会产生一个时间窗，在这个时间窗内，数据还没有完成从一个系统到另一个系统的迁移。这里的数据量可能很小，时间窗可能很短，但是在决定使用何种解决方案时必须考虑这一点。

我们来看看同步或异步故障转移可用性提供的一些选项。

同步故障转移可用性有两种类型：专门化的 HA 软件和同步复制。

专门化的 HA 软件

同步方法要求数据库软件与专门化的 HA 软件紧密集成，以产生一个 HA 集群。HA 软件支持因操作系统平台而异。常见的可用 HA 解决方案有：

Tivoli® System Automation（TSA） - Linux - AIX

Veritas Cluster Server - Windows®, AIX, and Linux

High Availability Cluster Multiprocessing（HACMP - AIX）

Microsoft Cluster Server（MSCS） - Windows

Sun Cluster - Sun

Steeleye Lifekeeper - Linux and Windows

这些是我所列出的平台上最常见的选项。还有其他一些 HA 软件解决方案可供使用。

所有这些解决方案实际上都是以相同的方式工作。如果出现故障，数据库服务器可以从一台机器转移到一个备份系统。为完成这项任务，HA 软件将所有需要的资源移动到辅助系统上。这些资源包括物理数据库的磁盘资源、网络资源和数据库服务器资源。

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

故障的检测是由服务器之间的一个 “heartbeat” 连接来执行的。这个 “heartbeat” 是 HA 软件的一个功能，它能识别硬件和软件故障。

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

检测故障所需的时间

移动数据库资源依赖项（存储阵列、网络资源等）所需的时间

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

当没有适当地关数据库闭时，DB2 会总是执行崩溃恢复。崩溃恢复是对日志文件进行处理，确保所有已提交的事务被写到磁盘，所有未提交的事务被回滚。执行这项操作所需的时间取决于出现故障时数据库日志中 “打开的” 工作量。如果需要从日志文件中处理较大的工作负载，那么整个故障转移需要数秒或更长的时间。

这种类型的可用性解决方案的一个优点是：不需要对应用程序或客户机配置目录进行任何更改。HA 软件为数据库连接提供一个虚拟 IP 地址资源。当检测到故障时，这个 IP 地址将在故障转移过程中发生转移，相同的连接语句仍可以被之前使用它的应用程序使用。当发生故障转移时，所有应用程序被断开连接，客户机将一个通信错误条件返回给应用程序。一旦数据库服务器在辅助系统上运行，应用程序只需重新发出连接语句，就能像之前一样继续处理工作。自动化客户机重路由的互补技术将在后面的一个小节中讨论。

辅助系统在等待故障转移时可以执行其他任务。可以将两个系统配置为相互接管的配置，使两个服务器都处于活动状态，分别容纳不同的数据库。每个机器都准备在出现故障时接管其伙伴的工作负载。图 3 是 HA 软件解决方案的一个例子。

图 3. HA 软件可用性


表 3. HA 软件可用性

优点	缺点
数据库总是同步	需要额外软件创建和配置解决方案
不需要更改应用程序或客户机	需要额外技能来设置和管理 HA 软件
不需要用户交互就能检测和初始化故障转移	不复制数据，减少了冗余
不会因为 HA 解决方案的设计降低性能	需要能满足某些 HA 标准的外部存储
数据库总是同步	存储需求会带来距离限制

同步复制有两种可用的实现方法：磁盘存储复制和 DB2 High Availability Disaster Recover（HADR）。

磁盘存储复制

磁盘存储复制利用专门的存储硬件和/或软件在辅助位置上执行主 DB2 服务器的同步磁盘写。当在主站点出现故障时，数据库资源在辅助位置上启动。辅助硬件/软件必须在两个位置上都执行同步磁盘块写，否则辅助位置可能与主位置不同步。图 4 演示了利用 IBM Peer to Peer Remote Copy（PPRC）的这种设计的一个例子。由于所有数据存储写必须在两个位置上同步地执行，这种解决方案的设计必须考虑主站点与辅助站点之间所需的 IO 带宽。

图 4. 磁盘存储复制


表 4. 磁盘存储复制

优点	缺点
数据库总是同步	需要满足解决方案标准的外部存储
不需要更改应用程序或客户机	存储复制需求会带来距离限制
	辅助系统不能用于数据库工作负载
	所有写活动必须在辅助站点上以正确的顺序回放

DB2 HADR 和 DB2 HA 特性

DB2 High Availability Disaster Recovery（HADR）是基于 DB2 日志记录机制的一种高性能数据库复制系统。一个 DB2 HADR 场景由两个 DB2 系统组成，一个是主系统，一个是备用系统。主系统执行所有事务性工作，并将任何数据库更改复制到备用系统。当出现故障时，通过一个命令将备用系统的角色切换为主系统的角色。

HADR 提供所有被日志记录的 DB2 操作的同步复制。要使两个 DB2 系统参与 DB2 HADR 对的基本要求是，它们具有 TCP/IP 连接。HADR 的设置和管理非常简单，DB2 提供向导帮助完成这些任务。

HADR 复制数据的基本方法是将 DB2 日志写同时发送到本地磁盘和备用系统。备用系统收到日志写后，将确认通知发送到主系统。当从备用系统收到本地写 IO 和接收确认通知后，主系统可以考虑提交的事务。客户机或应用程序并不知道这项操作。必须在两个系统之间发送的数据量只受到日志记录的操作的限制。数据存储页的实际更改是在两个系统上独立地执行的 —— 这样大大减少了实际所需的带宽。

运行 HADR 的开销非常小。默认的复制方法（也有其他可用的方法）只要求在将确认通知返回给主系统之前，备用系统的内存中收到一个日志写。通常，执行本地写 IO 的同步操作大于通过 TCP/IP 传输到备用系统的数据量。由于只需复制被更改的数据，所以读事务不受 HADR 实现的影响。在这些环境中，运行 HADR 时受到的影响很小。当执行大量的被日志记录的事务时，HADR 受到的影响由系统之间的网络带宽和延迟决定。如果网络带宽大于期望的日志记录活动，性能应该不会受到明显的影响。

如果这对系统之间的连接丢失，那么可以设置一个超时值，以便自动关闭 HADR。HADR 关闭后，主系统可以继续正常地处理事务。等到连接恢复时，就可以重新打开 HADR，而备用系统将与主系统通信，并执行 “catch-up” 操作，直到它返回到同步状态。图 5 演示了同步主系统和备用系统的 HADR 过程。

图 5. HADR 过程

HADR 的故障转移操作可以通过 HA 软件实现自动化。DB2 9.5 for AIX and Linux 包括了 DB2 High Availability（HA）特性。

DB2 HA 特性是通过高度集成 TSA 和 DB2 集群管理器应用程序编程接口（API）来实现的。当在 AIX 或 Linux 上安装 DB2 时，可以选择安装这个特性，这样就会自动安装 TSA。TSA 和 DB2 的配置是通过 DB2 High Availability Configuration Utility（db2haicu）实现的，db2haicu 大大简化了 HA 集群的配置。HA 特性的另一个非常重要的优点是，它实现了集群管理器 API。集群管理器 API 使 DB2 可以感知集群。由于能感知集群，将会自动处理影响到 HA 集群的 DB2 系统更改。一个例子就是停止 DB2 引擎。DB2 会让 HA 集群知道管理员停止了引擎，不需要因为停止事件而采取行动来重新启动或传输资源。

DB2 HADR 还允许执行滚动升级，从而增加了可用性。只要主系统和备用系统保持同步状态，它们之间的角色可以随意切换。当需要执行某种类型的系统维护任务、升级或安装 DB2 修复包时，可以关闭 HADR。在备用系统上执行维护时，主系统继续正常运行。一旦维护任务完成，便可以打开 HADR，系统自动重新同步，必要时可以切换角色，以便在原先的主系统上执行维护。

表 5. HADR

优点	缺点
数据库总是同步	附加的服务器和存储需求
不需要更改应用程序或客户机	备用系统不能同时用于数据库工作负载
易于安装和维护	不复制无日志记录的操作
对于 AIX 和 Linux，自动化故障转移是 “开箱即用” 的
对性能的影响非常小
可执行滚动升级

DB2 复制

DB2 复制可分为两种风格，传统的复制和基于队列的复制。这两种复制在本质上是类似的，但用于产生每个解决方案的复制方法有所不同，并且各有优点。

复制是一个异步的过程，不能保证故障转移期间两个副本之间所有数据都是一致的。复制是高度可配置的，但必须是将数据库表的更改从一个位置复制到另一个位置。复制这种可配置的特性为我们提供了很多选项，包括选择只复制一部分表和/或数据库范围、复制期间进行数据转换以及有多个复制目的地。只要有足够的网络带宽满足客户需要，距离不是问题。

复制还允许系统在不同的 OS 平台或不同的数据库管理系统上。复制的源和目标是 “活动的”，所以工作可以在每个系统上同时完成。例如，可以用一个系统来处理事务，而用另一个系统创建报告或运行备份。复制只限于用户定义的表。系统目录的更改不能复制。例如，对表权限的更改必须在所有系统上执行，因为这种更改是不能复制的。

DB2 传统复制，也称 SQL 复制，是一个集成的 DB2 特性。它由两部分组成：捕获和应用。复制管理员指定作为复制源的表，然后在目标数据库（即辅助系统）上使用前一步中的复制源作为源创建复制子描述。一个捕获进程监视事务日志，以发现对复制源表的任何更改，并将对这些表的更改放入到 staging 表中。一个应用（apply）程序则每隔一段时间读取 staging 表，并将更改移动到子描述目标上。

运行传统复制会导致一些开销。额外工作的量取决于源表上的插入、更新和删除活动的量。基表上不需要额外的锁，因为复制只分析日志文件，而不是分析基表。但是填充 staging 表（更改表）和在日志中记录这些事务则需要数据库资源。图 6 表示了传统复制场景的基础。

图 6. 传统复制

DB2 队列复制类似于传统复制；但是，这种复制没有使用 staging 表。相反，更改被直接放在消息队列中。这些队列由 Websphere® Replication Server 提供，可以在一个单独的服务器上创建队列，也可以在主数据库服务器或辅助数据库服务器上创建队列。队列为将更改传送到目标提供了一个快速的、有保证的传送机制。DB2 队列复制没有传统复制的那些开销，并且提供更大的吞吐率，此外，队列的实现也增加了冗余。

图 7. 队列复制


表 6. 复制

优点	缺点
极度灵活	固有的异步性
多个活动副本	附加的性能开销（传统复制）
没有距离限制	附加设置和管理
	不是所有的数据库更改都被复制

自动客户机重路由

当数据库服务器上发生故障时，将停止客户机连接。自动客户机重路由（Automatic client reroute，ACR）使 DB2 客户机可以自动重新连接到原始的或备用的服务器上，从而减少客户机停机时间。用于 ACR 的备用服务器信息是在数据库服务器上指定的一个参数。在客户机第一次连接到数据库服务器并从服务器端参数中提取信息之后，备用服务器信息被缓存在客户机上。当检测到通信错误时，ACR 轮流尝试到原始服务器和备用服务器的连接。ACR 不会重放正在运行的事务，建立客户机连接后，所有未提交的工作必须重新执行。ACR 为使用 ACR 的所有应用程序生成一条警告消息，以允许应用程序采取其他必要的行动。图 8 显示了在包含多个客户机和应用服务器的环境下工作的 ACR。

图 8. ACR

有些产品，例如 WebSphere 中间件，是 ACR 感知的（ACR-aware）。这进一步降低了复杂性，并提高了应用程序的可用性。

结束语

有很多选项可用于创建运行良好、高度可用的 DB2 解决方案。本文为您选择最适合自己的环境的解决方案提供了指南。