db2 v97 高可用性灾难恢复中的备机可读.docx

前言在最新的 DB2 V9.7.1 中，引入了一项高可用性灾难恢复（High Availability Disaster Recovery，简称 HADR）环境下的新功能：备机可读（Reads On Standby，简称 RoS）。利用该功能，能够有效分担主机数据库（Primary DB）的工作负载，充分利用备机数据库（Standby DB）运行一些读操作的应用，以达到资源更加优化的目的。为了更好理解备机可读这一新功能，我们先从高可用性灾难恢复的基本概念开始。高可用性灾难恢复基础从 V8.2（当时称作 DB2 Universal Database， DB2 通用数据库）开始，DB2 引入了一种新的、源自于 Informix 的高可用性解决方案：高可用性灾难恢复（即 HADR）。在高可用性灾难恢复环境中，通常有两台物理的数据库服务器，即主数据库（Primary DB）和备机数据库（Standby DB），它们分别位于两个有一定距离间隔的数据中心（如图 1 所示）。图 1. 高可用性灾难恢复的组织结构?主数据库（Primary DB），能够接受日常的增删改查等应用操作，这些操作产生的数据库日志（Log）通过 TCP/IP 协议传送给备机数据库（Standby DB）。由于数据库事务都是基于日志的，备机数据库通过重做（Replay）这些日志，就能够重现主数据库服务器上相应的操作，从而使得两个数据库中的数据能够基本保持在一致的状态。在主数据库出现宕机，如地震、火灾、断电等灾难或问题，导致数据库不可访问或者损坏的时候，备机数据库能够很快接管（Takeover）主数据库的工作和任务，成为新的主机数据库（如图 2 所示）。由于备机数据库中的数据在主数据库出现问题之前一致保持着与主数据库相接近状态，因此应用程序能够直接连接到新的主数据库（即旧的备机数据库）上，这样就能把业务中断够减小到最低限度。图 2. 接管之后的高可用性灾难恢复组织结构?最初在引入 HADR 作为高可用性方案的时候，备机数据库仅仅是作为主数据库的备用设备，其唯一功能就是重做主数据库传递来的数据库日志，使其数据状态跟主数据库保持一致，以便在主数据库出现问题的时候接管应用。所以，备机数据库一直处于脱机（offline）状态，也就是说，在接管之前，不允许用任何应用程序连接，这样在一定程度上导致了资源的浪费。因此，在最新的 DB2 LUW V9.7.1（DB2 Linux Unix and Windows, Version 9.7 Fix Pack 1）中，引入了备机可读的功能，提高了备机数据库的利用率，这正是本文要讨论的主题。回页首备机可读上文已经提到，在最新的 DB2 版本中，在备机上已经支持可读操作，原先在主数据库上的只读应用，例如生成报告、决策支持、商业智能应用等，现在都可以迁移到备机数据库上进行，这样，即在一定程度上减轻了主数据库的负载，又提高了备机数据库的利用率。如图 3 所示。图 3. 备机可读的高可用灾难恢复组织结构?高可用性灾难恢复中的备机可读环境的设置接下来，让我们来快速配置一个备机可读的环境，体验一下这项令人激动的新功能吧！1. 安装 DB2 V9.7.1，并配置高可用性灾难恢复环境。这并不是本文讨论的重点，请读者参考相应文档。2. 打开高可用性灾难恢复的备机可读功能。这需要在备机数据库上设置一个 DB2 的注册变量（Registry Variable）—— DB2_HADR_ROS。将该变量设置为 1，或者 yes，或者 on，可将备机可读功能打开；设置为空，或者不设置该注册变量的值，则表示不启用备机可读功能，这时候备机数据库跟之前版本 DB2 中的备机数据库一样，只进行数据库日志重做，不接受任何应用连接。清单 1. 启用高可用性灾难恢复中的备机可读 $ db2set DB2_HADR_ROS=1 小窍门：设置DB2中的注册变量注意：跟其他DB2注册变量一样，设置DB2_HADR_ROS（静态变量）之后，需要重新启动DB2数据库实例（Instance），以使其生效。要重启数据库实例，使用db2stop命令停止DB2数据库实例，然后用db2start启动DB2数据库实例：清单 2. 重新启动DB2实例$ db2stop SQL1064N DB2STOP processing was successful.$ db2startSQL1063N DB2START processing was successful.3. 激活备机数据库要激活备机数据库，使用 ACTIVATE DB 命令（这里使用名为 HADRDB 的数据库作为例子）：清单 3. 激活备机数据库 $ db2 ACTIVATE DB hadrdb DB20000I The ACTIVATE D