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

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

数据复制选项

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

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

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

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

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

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

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

图 3. 复制

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

日志传送选项

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

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

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

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