(转) DB2 HADR

转自http://www.ibm.com/developerworks/cn/data/library/techarticles/dm-0508luojunkai/

原文：http://blog.csdn.net/deanza/article/details/8469447

在DB2的高可用性（HA，High Availability）技术中，Standby是其中之一（还有snapshot和mirror）。它的原理跟在Oracle的Data Guard相似，都是提供一种待机模式，让另外一台服务器接收来自“主”系统的日志，并更新至待机数据库中，以达到数据同步的目的。

DB2提供了两种切换选项给用户，即

• Idle standby（我把它译成被动待机模式），即主系统与备用系统无主从关系，备用系统只以备用状态启动，直到被手工激活；
• Mutual takeover（互为备份模式），即主系统与备用系统有主从关系，一方切换成主系统则另一方自动切换成备用系统，反之亦然

在传输日志的方式中，DB2提供了三种模式：

• 同步模式（SYNC），这是最高保护模式，主系统一定要等到备用系统完成了日志的写（要写进磁盘的哦）及数据更新并发回完成信号后才能响应下一个操作；
• 近乎同步（NEARSYNC），这是一种折衷的方式，主系统只要将日志传到备用系统的主内存（Main memory）中并收到备用系统的信号就能响应下一个操作（如果网络条件好的话，可以考虑这个）；
• 异步（ASYNC），这个比较简单，主系统完成日志写入磁盘并将日志发至主系统的TCP层就返回了（如果网络条件不好的话，只能用这个了）

DB2 HADR与Oracle dataguard有几分类似，这里实验采用手动切换主备，同时日志传送采用NEARSYNC的模式。

DB2 HADR概述

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

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

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

快速实例上手

要进行这个实例配置过程，你必须拥有DB2 UDB Enterprise Server Edition (ESE)，笔者使用的是DB2 ESE v8.2.2 for Linux 32bit（在v8.2的基础上打了Fixpack9a）。如果您没有这个版本，可以到IBM官方网站下载试用版（可能需要花点时间填写一些信息），下载链接：https://www14.software.ibm.com/webapp/iwm/web/preLogin.do?source=db2udbdl。

另外，笔者使用的是两台DELL PowerEdge 2850作为数据库服务器，安装Redhat linux Enterprise Server v4.0。这两台机器的主机名和IP地址分别为：DBSERV1（192.168.1.162）和DBSERV2（192.168.1.163）。在下面的配置过程中我们将DBSERV1作为主数据库服务器，其实HADR配置好之后，这两台服务器的角色是可以转换的。为简单起见，我们就采用DB2的样本数据库SAMPLE作为配置对象。

配置过程（以下命令均在DB2 CLP中执行）：

1. 在DBSERV1和DBSERV2上安装DB2，并创建缺省实例db2inst1，服务端口：50000，我们使用缺省的实例所有者用户db2inst1，密码：db2inst1

2. 使用db2sampl命令在DBSERV1上创建样本数据库SAMPLE

3. 修改SAMPLE数据库配置参数LOGRETAIN为ON，以使该数据库日志记录方式改为存档日志。

UPDATE DB CFG FOR SAMPLE USING LOGRETAIN ON
UPDATE DB CFG FOR SAMPLE USING TRACKMOD ON

4. 修改索引日志记录参数

UPDATE DB CFG FOR SAMPLE USING LOGINDEXBUILD ON
UPDATE DB CFG FOR SAMPLE USING INDEXREC RESTART

注：这一步并不是必须的。

5. 备份数据库SAMPLE

BACKUP DB SAMPLE TO /database/dbbak

其中"/database/dbbak"是笔者用来存放数据库备份文件的目录，你完全可以指定任何一个db2inst1有写入权限的其他目录。

备份完成之后，在/database/dbbak目录下我们会看到数据库备份映像文件：

SAMPLE.0.db2inst1.NODE0000.CATN0000.20050726122125.001

注：你所得到的文件名的时间标志部分肯定和我的不一样，在下面的恢复数据库命令中要注意做相应的修改。

6. 将得到的数据库映像文件复制到DB2SERV2对应的目录下（/database/dbbak）。

7. 在DBSERV2上恢复数据库SAMPLE：

RESTORE DATABASE SAMPLE FROM "/database/dbbak" TAKEN AT
20050726122125 REPLACE HISTORY FILE WITHOUT PROMPTING

8. 配置自动客户端重新路由：

在主数据库服务器（DBSERV1）上：

UPDATE ALTERNATE SERVER FOR DATABASE SAMPLE USING HOSTNAME 192.168.1.163 PORT 50000

在备用数据库服务器上（DBSERV2）：

UPDATE ALTERNATE SERVER FOR DATABASE SAMPLE USING HOSTNAME 192.168.1.162 PORT 50000

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

用vi编辑/etc/services文件（需要切换到root用户），加入下面两行：

DB2_HADR_1      55001/tcp
DB2_HADR_2      55002/tcp

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

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

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

UPDATE DB CFG FOR SAMPLE USING HADR_LOCAL_HOST 192.168.1.162
UPDATE DB CFG FOR SAMPLE USING HADR_LOCAL_SVC DB2_HADR_1
UPDATE DB CFG FOR SAMPLE USING HADR_REMOTE_HOST 192.168.1.163
UPDATE DB CFG FOR SAMPLE USING HADR_REMOTE_SVC DB2_HADR_2
UPDATE DB CFG FOR SAMPLE USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR SAMPLE USING HADR_SYNCMODE NEARSYNC
UPDATE DB CFG FOR SAMPLE USING HADR_TIMEOUT 120
CONNECT TO SAMPLE
QUIESCE DATABASE IMMEDIATE FORCE CONNECTIONS
UNQUIESCE DATABASE
CONNECT RESET

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

UPDATE DB CFG FOR SAMPLE USING HADR_LOCAL_HOST 192.168.1.163
UPDATE DB CFG FOR SAMPLE USING HADR_LOCAL_SVC DB2_HADR_2
UPDATE DB CFG FOR SAMPLE USING HADR_REMOTE_HOST 192.168.1.162
UPDATE DB CFG FOR SAMPLE USING HADR_REMOTE_SVC DB2_HADR_1
UPDATE DB CFG FOR SAMPLE USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR SAMPLE USING HADR_SYNCMODE NEARSYNC
UPDATE DB CFG FOR SAMPLE USING HADR_TIMEOUT 120

12. 启动HADR：

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

DEACTIVATE DATABASE SAMPLE
START HADR ON DATABASE SAMPLE AS STANDBY

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

DEACTIVATE DATABASE SAMPLE
START HADR ON DATABASE SAMPLE AS PRIMARY

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

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

HADR测试

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

CONNECT TO SAMPLE USER db2inst1 USING db2inst1
CREATE TABLE HADRTEST(ID INTEGER NOT NULL WITH DEFAULT,NAME VARCHAR(10),PRIMARY KEY (ID))
INSERT INTO HADRTEST (ID,NAME) VALUES (1,'张三')
INSERT INTO HADRTEST (ID,NAME) VALUES (2,'李四')

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

TAKEOVER HADR ON DATABASE SAMPLE USER db2inst1 USING db2inst1

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

GET SNAPSHOT FOR DB ON SAMPLE

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

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

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

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

HADR管理操作汇总

1. 启动和停止HADR

使用START HADR命令启动主数据库和备用数据库的HADR。启动主数据库使用AS PRIMARY子句，启动备用数据库使用AS STANDBY 子句。如果想以其他用户启动HADR，可以通过USER user-name USING password子句指定用户名和密码：

例子：

START HADR ON DATABASE SAMPLE USING db2inst1 USING db2inst1 AS STANDBY

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

例如：

START HADR ON DATABASE SAMPLE AS PRIMARY BY FORCE

使用STOP HADR 停止主数据库和备用数据库的HADR。

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

如果在活动的备用数据库上发出此命令，将停止失败。你必须先使用DEACTIVATE DATABASE命令取消激活，然后再停止HADR。

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

HADR连接状态：

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

通过GET SNAPSHOT命令观察主数据库和备用数据库的连接状态。

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

3. 接管/故障转移

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

HADR提供两种接管方式：

紧急接管：

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

TAKEOVER HADR ON DATABASE SAMPLE BY FORCE

普通接管：

普通接管就是没有使用BY FORCE子句的接管，例如：

TAKEOVER HADR ON DATABASE SAMPLE

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

4. 同步方式

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

SYNC（同步）：

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

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

NEARSYNC（接近同步）：

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

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

ASYNC（异步）：

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

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

5. 自动客户端重新路由（Automatic Client Reroute）

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

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

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

6. 使用控制中心管理HADR

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

7. 关于索引日志记录

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

用户可以通过CREATE TABLE或ALTER TABLE语句的LOG INDEX BUILD选项来对单个表设定索引日志记录级别。LOG INDEX BUILD选项有三个可选参数：

• NULL：这是缺省值，当使用此参数时，表的索引日志记录级别由数据库配置参数LOGINDEXBUILD的值决定。
• ON：使用此参数，数据库配置参数LOGINDEXBUILD的值将被忽略，DB2将记录这个表上所有索引维护的详细日志。
• OFF：使用此参数时，数据库配置参数LOGINDEXBUILD的值将被忽略，DB2将不记录这个表上索引维护的日志。

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

• RESTART：DB2将在显式或隐式重启数据库（RESTART DATABASE）的时候检查并重新构建无效索引。
• ACCESS：DB2将在无效索引第一次被访问的时候才会重新构建它。
• SYSTEM：使用数据库管理器配置参数（Database Manager Configuration）INDEXREC的值。

在上面的配置实例中，我们将INDEXREC的值设为RESTART，备用数据库将在接管为新的主数据库时检查并重新构建所有无效索引。

DB2 HADR的使用限制

• 只有DB2 UDB Enterprise Server Edition（ESE）支持HADR，但HADR不能支持分区数据库（Database Partitioning Feature，DPF）。
• 主数据库和备用数据库必须运行在相同的操作系统版本上，并且DB2 UDB的版本也必须一致，除非短暂的软件升级过程。
• 主数据库和备用数据库的位大小必须一致（32位或64位）。
• 不能在备用数据库上进行备份操作
• 备用数据库是不能访问的，客户端程序无法连接备用数据库。
• 日至归档操作只能在主数据库上进行。
• 带有COPY NO选项的LOAD命令是不支持的
• 主数据库和备用数据库必须是一对一的。
• HADR不能使用循环日志
• HADR不复制数据库配置参数、共享库、DLLs、UDFs或存储过程

结束语

你也可以通过一些专门的HA软件来实现高可用性和灾难恢复，但这些HA软件一般都很昂贵，而DB2 HADR是包含在DB2 ESE里的，不需要额外的费用，另外，DB2 HADR配置和管理也很简单，而且功能也很不错，所以笔者一直喜欢将它推荐给客户。