通过IBMDB2实现高可用性和灾难恢复.PDFVIP

通过 IBM DB2 实现高可用性和 灾难恢复 DB2 10.1 为 HADR 提供了全新的功能 英文原文： /2012/08/achieving-high-availability- and-disaster-recovery-with-ibm-db2/ 作者：Michael Schulz | 发布日期：2012 年 8 月 27 日 | 17 次阅读 打印 PDF IT 系统确实会发生故障。我们要关心的不是“是否”出现问题，而是“何时”出现问题。我们 必须时刻准备处理包含关键运营数据的当今企业环境中出现的这类故障。IBM® DB2® for Linux, UNIX and Windows 提供了许多防止数据可用性中断的方法。本文将介绍 DB2 的高可用性灾 难恢复 (HADR) 功能，包括最新的 DB2 10.1 版本中的各种新功能。 建立坚实的基础 所有最新 DB2 版本均包含 HADR 特性。这项技术成熟可靠，许多企业都使用它来提高数据库 可用性级别。HADR 是工作原理是实现主（热）服务器和备用（冷）服务器之间的数据同步。 借助 HADR，DBA 可以在出现故障或使用集群软件（比如 IBM Tivoli® System Automation 或 其他故障转移集群产品）时手动切换到备用服务器，以便自动检测故障，并将连接切换到备用服 务器。在 DB2 9.7.1 中，IBM 引入了从备用服务器提供读取操作的功能，提高了集群的利用率。 此功能使得示例报告能够运行当前的暖备用服务器，因此主数据库服务器不必再运行该负载。 DB2 10.1 当前支持三台备用服务器，这不仅可以提高同一数据中心内的高可用性，还可以提高 跨多个站点进行灾难恢复配置的能力。 人们不再需要单独运用 HADR 来实现高可用性，同时使用另一项解决方案来进行灾难恢复，您 可以使用 HADR 同时处理这两项工作，从而简化了软件堆栈。DBA 可以在与主数据库服务器 相同的位置上部署主备用数据库，以便快速实现故障转移，并提高本地网络传输速率。还可以远 程定位另外两台备用服务器（称为辅助服务器），防止出现影响整个站点的大型灾难。在出现影 响主服务器和主要备用服务器的站点范围中断时，DBA 可以从任意一台辅助服务器发出接管命 令，随后成为新的主服务器和主要备用服务器。所有备用服务器（无论是主服务器还是辅助服务 器）均支持读取操作。 提供针对应用程序错误的保护 有时候，应用程序会产生一些影响数据的错误。如果将这些错误复制到备用数据库，就会使问题 变得更加复杂。为避免复制错误，DB2 10.1 的 HADR 引入了延迟重播功能，帮助数据免受应 用程序错误的影响。通过在备用服务器上启用 hadr_replay_delay 选项，DBA 能够延迟对 数据所做的任何更改（例如，延迟 24 小时），为发现所有问题并从以前某个时间点进行恢复 提供足够的时间。 延迟重播会将主服务器上生成的日志流中的时间戳与备用服务器上的当前时间进行比较。因此， 主服务器和备用服务器上的时间必须始终保持同步。 事务提交将依据下面的等式在备用服务器上重播： (current time on the standby – value of the hadr_replay_delay configuration parameter = time stamp of the committed log record 将 hadr_replay_delay 参数设置为一个足够大的值是一个不错的主意，这样您就可以检测 主服务器上的任何错误事务并及时作出反应。由于 DB2 10.1 允许包含多台备用服务器，所以 现在您可以将一台备用服务器与主服务器保持同步，以实现高可用性，并获得使用延迟重播特性 来防止数据错误的一台备用服务器。 利用日志假脱机防止出现吞吐量峰值 根据集群的同步配置，可能出现以下情况：主服务器不得不等待备用服务器完成其事务，然后才 能继续执行处理操作。HADR 日志假脱机是 DB2 10.1 中的一项全新功能，它允许 DBA 指定 额外的空间，以便在备用服务器上对日志进行假脱机处理。此功能有助于避免因为辅助服务器上 的日志记录活动突然增加而导致的主服务器上的背压问题。 您可以通过使用 hadr_spool_limit 数据库配置参数来启用日志假脱机，这会上调日志接收 缓冲区已满时写入磁盘的 （或“假脱机”）数据量的上限。 备用服务器上的日志重播特性随后可以从磁盘读取日