DB2 HADR概述 DB2 高可用 DB2 双机热备

本文格式为Word版，下载可任意编辑——DB2HADR概述DB2高可用DB2双机热备

DB2高可用

DB2HADR概述HighAvailabilityDisasterRecovery(HADR)是数据库级别的高可用性数据复制机制，最初被应用于Informix数据库系统中，称为HighAvailabilityDataReplication（HDR）。IBM收购Informix之后，这项技术就应用到了新的DB2发行版中。一个HADR环境需要两台数据库服务器：主数据库服务器（primary）和备用数据库服务器（standby）。当主数据库中发生事务操作时，会同时将日志文件通过TCP/IP协议传送到备用数据库服务器，然后备用数据库对接受到的日志文件进行重放（Replay），从而保持与主数据库的一致性。当主数据库发生故障时，备用数据库服务器可以接纳主数据库服务器的事务处理。此时，备用数据库服务器作为新的主数据库服务器进行数据库的读写操作，而客户端应用程序的数据库连接可以通过自动客户端重新路由（AutomaticClientReroute）机制转移到新的主服务器。当原来的主数据库服务器被修复后，又可以作为新的备用数据库服务器参与HADR。通过这种机制，DB2UDB实现了数据库的灾难恢复和高可用性，最大限度的避免了数据丢失。下图为DB2HADR的工作原理图：

注：处于备用角色的数据库不能被访问。

下面我们首先从一个配置实例入手来了解DB2HADR环境的基本配置过程，然后再对HADR环境涉及到的一些技术要点展开探讨。

回页首

快速实例上手

要进行这个实例配置过程，你必需拥有DB2UDBEnterpriseServerEdition(ESE)，笔者使用的是DB2ESEv8.2.2forLinux32bit（在v8.2的基础上打了Fixpack9a）。假使您没有这个版本，可以到IBM官方网站下载试用版（可能需要花点时间填写一些信息），下载链接：https://http://.77/webapp/iwm/web/preLogin.do?source=db2udbdl。另外，笔者使用的是两台DELLPowerEdge2850作为数据库服务器，安装RedhatLinuxEnterpriseServerv4.0。这两台机器的主机名和IP地址分别为：DBSERV1（62）和DBSERV2（63）。在下面的配置过程中我们将DBSERV1作为主数据库服

DB2高可用

9.配置HADR服务和侦听端口

用vi编辑/etc/services

文件（需要切换到root用户），参与下面两行：

对于Windows，编辑%SystemRoot%\system32\drivers\etc\services。

注：这一步不是必需的，由于在下面配置HADR_LOCAL_SVC和HADR_REMOTE_SVC数据库参数的时候您可以直接使用端口号来替代服务名。

10.修改主数据库（DBSER1-SAMPLE）的配置参数：

11.

修改备用数据库（DBSERV2-SAMPLE）的配置参数：

12.

启动HADR：

首先启动备用数据库服务器的HADR：

DB2高可用

然后启动主数据库服务器的HADR：

注：假使你先启动主数据库服务器HADR，那么你必需保证在HADR_TIMEOUT参数指定的时间内（单位为秒）启动备用数据库服务器HADR。否则将启动失败。

OK，到目前为止，我们已经成功配置并启动了DB2HADR。在下一节中我们将对这个配置好的HADR环境进行一些测试来验证它是否能依照我们预期的方式工作。

回页首

HADR测试

1.连接到主数据库，创立测试表HADRTEST，并插入几条测试数据：

2.使用备份数据库接纳主数据库

观测数据库主数据库和备用数据库的状态：

新的主数据库（原备用数据库）：

DB2高可用

备用数据库（原主数据库）：

3.连接到新的主数据库，并查询HADRTEST表：

显然，我们的HADR环境已经可以正常工作了。读者可以自己再针对数据的修改、删除等进行一些测试。自动客户端重新路由（AutomaticClientReroute）功能也留给读者自己测试。

回页首

HADR管理操作汇总

1.启动和中止HADR

使用STARTHADR命令启动主数据库和备用数据库的HADR。启动主数据库使用AS

PRIMARY子句，启动备用数据库使用ASSTANDBY子句。假使想以其他用户启动HADR，可以通过USERuser-nameUSINGpassword子句指定用户名和密码：

例子：

在启动主数据库的HADR时，假使在数据库HADR_TIMEOUT所指定的时间内未能建立与备用数据库HADR的连接，启动将失败。这时候，你可以等排除故障并成功启动备用数据库HADR后再启动主数据库HADR，也可以通过指定BYFORCE子句强行启动主数据库。例如：

使用STOPHADR中止主数据库和备用数据库的HADR。

DB2高可用

假使在活动的主数据库上发出此命令，所有的数据库连接都被断开，数据库恢复为标准数据库（我们称没有启用HADR的数据库为标准数据库），并保持联机状态。

假使在活动的备用数据库上发出此命令，将中止失败。你必需先使用DEACTIVATEDATABASE命令取消激活，然后再中止HADR。

2.查看HARD的配置及运行状态

HADR连接状态：

当备用数据库的HADR启动时，它首先进入本地同步更新状态。并根据本地日志路径配置参数及日志归档方法的设置检索本地系统中的日志文件并重放。当本地日志文件重放完毕，备用数据库进入远程同步暂挂状态。当与主数据库建立连接之后，备用数据库进入远程同步更新状态。即主数据库将自己的日志文件通过TCPIP协议发送给备用数据库，备用数据库接收到日志文件并重放，直到所有日志文件都重放完毕，备用数据库和主数据库进入对等状态。见下图：

通过GETSNAPSHOT命令观测主数据库和备用数据库的连接状态。

通过GETDBCFG命令可以查看HADR的配置状况，即HADR相关的几个数据库参数值。

3.接纳/故障转移

当主数据库发生故障时，备用数据库可以接纳主数据库的服务，成为新的主数据库（称为故障转移）。当原主数据库修复后，又可以作为备用数据库参与HADR对。即使主数据库服务器没有故障，我们通过接纳命令（TAKEOVER）切换主数据库和备用数据库的角色。接纳命令只能用在备用数据库上。

HADR提供两种接纳方式：

紧急接纳：

当主数据库发生故障时，可以在备用数据库上使用紧急接纳，使备用数据库成为新的主数据库。紧急接纳必需指定TAKEOVER命令的BYFORCE子句，例如：

DB2高可用

普通接纳：

普通接纳就是没有使用BYFORCE子句的接纳，例如：

这种接纳必需在主数据库和备用数据库都正常运行的状况下使用。假使主数据库发生故障，普通接纳将失败，这时候必需使用上面的紧急接纳。

4.同步方式

在上面的配置实例中我们将主数据库和备用数据库的HADR_SYNCMODE参数值设置为NEARSYNC，当主数据库和备用数据库处于对等状态时，HADR采用NEARSYNC（接近同步）同步方式管理日志写入。DB2提供了三种日志同步方式：

SYNC（同步）：

采用SYNC方式时，仅当主数据库日志写入成功，并收到备用数据库的应答，确保备用数据库的日志也成功写入的状况下，才认为日志写入成功。

这种方式下的事务响应时间最长，但最大限度的确保不发生事务丢失。

NEARSYNC（接近同步）：

采用NEARSYNC方式时，当主数据库日志写入成功，并收到备用数据库的应答，确定备用数据库已经接收到日志时，即认为日志写入成功。也就是说，备用数据库接收到的日志并不一定能成功写入持久存储设备上的日志文件。

这种方式下的事务响应时间比SYNC方式短，且仅当两台服务器同时发生故障时，才会发生事务丢失。

ASYNC（异步）：

采用ASYNC方式时，当主数据库日志写入成功，并将日志发送出去之后，即认为日志写入成功。此方式并不保证备用数据库能收到日志，这要依靠于TCP/IP网络状况。

这种方式下的事务响应时间最短，但产生事务丢失的可能性也最大

5.自动客户端重新路由（AutomaticClientReroute）

要配置自动客户端重新路由，使用UPDATEALTERNATESERVER命令设置备用数据库信息（使用方法参考上面的配置实例），这些信息将被存放在数据库的系统目录中。请注意：必需使用此命令来设置备用数据库，而不是HADR_REMOTE_HOST和

HADR_REMOTE_SVC数据库配置参数，自动客户端重新路由不使用这两个参数。

当客户端与数据库建立连接时，备用数据库的配置信息（主机/IP及端口号）也同时被发送给DB2客户端。当客户端与主数据库的连接被中断时，客户端就使用这些信息连接到备用数据库，从而最小限度的降低了数据库故障所造成的影响。需要强调的是，这个过程由DB2客户端自动完成，不需要用户用程序干扰。见下图：

DB2高可用

通过LISTDBDIRECOTRY命令可以查看系统数据库目录中自动客户端重新路由的配置。

6.使用控制中心管理HADR

在上面的探讨中我们主要通过DB2CLP命令来创立和管理DB2HADR。实际上DB2的控制中心也提供了创立和管理HADR的图形界面，例如：工具-〉向导-〉设置高可用性灾难恢复（HADR）数据库。这些功能使用起来都十分简单，在这里我们就不详细探讨了。但是，笔者猛烈建议尽量多使用DB2CLP命令来管理DB2（不仅仅是针对HADR），不要过于依靠DB2控制中心，由于好多服务器环境都担忧装控制中心，这时候你假使没有把握DB2CLP命令，那可就麻烦大了。

7.关于索引日志记录

索引的创立、重建、重组也是HADR环境中需要考虑的一个方面，DB2通过数据库配置参数LOGINDEXBUILD和CREATETABLE或ALTERTABLE语句中的LOGINDEXBUILD选项来控制是否对索引的相关操作进行详细的日志记录。我们在上面的HADR配置实例中将LOGINDEXBUILD数据库参数配置为ON，意为让DB2记录索引创立、重建、重组的完整日志。这显然会降低主数据库的运行效率并占用更多的日志空间。但由于备用数据库可以通过重放日志来重新构建索引，所以当主数据库发生故障，备用数据库的索引依旧可用。用户可以通过CREATETABLE或ALTERTABLE语句的LOGINDEXBUILD选项来对单个表设定索引日志记录级别。LOGINDEXBUILD选项有三个可选参数：

NULL：这是缺省值，当使用此参数时，表的索引日志记录级别由数据库配置参数LOGINDEXBUILD的值决定。

ON：使用此参数，数据库配置参数LOGINDEXBUILD的值将被忽略，DB2将记录这个表上所有索引维护的详细日志。

OFF：使用此参数时，数据库配置参数LOGINDEXBUILD的值将被忽略，DB2将不记录这个表上索引维护的日志。

假使表选项LOGINDEXBUILD设置为OFF，或者LOGINDEXBUILD设置为NULL但数据库配置参数LOGINDEXBUILD设置为OFF，DB2将不记录这些表的索引维护日志，备用数据库也就无法重放索引维护操作，致使这些索引在备用数据库上变为无效状态。当主数据库发生故障，备用数据库切换为新主数据库后，这些无效的索引必需重建才能被使用。DB2通过数据库配置参数INDEXREC来指定在什么时候检查并重建无效索引。INDEXREC参数有三个可选值：

RESTART：DB2将在显式或隐式重启数据库（RESTARTDATABASE）的时候检查并重新构建无效索引。

ACCESS：DB2将在无效索引第一次被访问的时候才会重新构建它。

DB2高可用

SYSTEM：使用数据库管理器配置参数（DatabaseManagerConfiguration）

INDEXREC的值。

在上面的配置实例中，我们将INDEXREC