服务器 频道

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

  专用的 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 软件选项的优缺点

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

  数据复制选项

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

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

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

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

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

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

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

  图 3. 复制

 

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

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

  

0
相关文章