DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（5）-sdccf-ChinaUnix博客

HADR 设置中包括两台机器：主机器和辅助机器。源数据库存储在主机器上。当源数据库中在处理事务时，数据库日志被自动传送到辅助服务器中。辅助服务器存储着从源数据库克隆而来的一个数据库。它可以使用数据库恢复和分割镜像进行初始化。当 HADR 被启动时，辅助机器上收到日志文件，并重演这些日志。通过不断地重演日志，复制数据库始终是主数据库的复制品，并充当一个备用数据库的角色。

当主数据库发生故障时，备用数据库接管事务型工作负载，并成为新的主数据库。如果出故障的机器又重新可以使用，那么可以使之重新同步，跟上新的主数据库。于是，原来的主数据库就变成了新的备用数据库。

为了设置 HADR 环境，要更新一些数据库配置参数。

首先，必须启用主数据库上的归档日志记录。请参阅备份和恢复教程，以了解如何启用归档日志记录。

表 1 列出了与 HADR 相关的数据库配置参数的描述。本教程后面将给出一个关于如何更新这些参数的例子。

与 HADR 相关的数据库配置参数	描述
HADR_LOCAL_HOST	指定 HADR TCPIP 通信的本地主机。主机名和 IP 地址都可以使用
HADR_LOCAL_SVC	指定 TCPIP 服务名和端口号，HADR 进程将在本地主机上接受该服务或端口的连接。这个端口不能与 HADR 实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_HOST	指定远程 HADR 节点的 TCPIP 主机名或 IP 地址
HADR_REMOTE_SVC	指定 TCPIP 服务名或端口号，HADR 进程将在远程节点上接受该服务或端口的连接。这个端口不能与远程实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_INST	指定远程服务器的实例名。DB2 Control Center 之类的管理工具将使用这个参数与远程服务器联系
HADR_TIMEOUT	HADR 进程在认为一次通信尝试失败之前所等待的时间（以秒为单位）。默认值为 120 秒
HADR_SYNCMODE	指定同步模式。它决定当系统处于对等状态时，主日志写与备用数据库如何同步。有效值有 SYNC、NEARSYNC 和 ASYNC。默认值为 NEARSYNC。（本节后面将讨论对等状态）。
HADR_DB_ROLE	指定一个数据库当前的角色。有效值有 STANDARD、PRIMARY 和 STANDBY。STANDARD 意味着数据库没有启用 HADR。

当备用数据库第一次启动时，它进入 local catch-up 状态。本地日志路径中的日志文件（如果有的话）将被读取，并应用到备用数据库。

当到达本地日志文件的最后时，备用数据库进入 remote catch-up 状态。它重演主数据库的归档日志和活动日志，直到备用数据库应用了最近的活动日志。

当主系统上的所有日志文件都已经被重演时，主数据库和备用数据库就进入对等（peer）状态。

在对等状态中，每当主数据库将日志页刷新到磁盘，这些日志页就被传送并应用到备用数据库。这时应该指定三种同步模式中的一种，以免丢失数据。下一节中将详细讨论同步模式。

还记得吗，当 HADR 对处于对等状态时，主数据库将日志页刷新到磁盘上的日志文件中，然后这些日志文件被传送并应用到备用数据库。为规定如何管理主数据库与备用数据库之间的日志写，需要指定一种同步模式。一共有三种同步模式：SYNC（同步）、NEARSYNC（近似同步）和 ASYNC（异步）。

在同步模式中，日志写只有在以下情况下才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库的日志文件中。

主数据库与备用数据库中的日志记录几乎（或近似）是同步的，因为只有在以下情况下，日志写才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库上的主存中。

在这种模式下，主数据库不等待收到备用数据库的通知。只有在以下情况下，日志写才被认为是成功的：

日志记录已经被写到主数据库上的日志文件中。
日志记录已经被传送到备用数据库；不需要通知。

HADR 是通过以下三个简单的命令来管理的：

START HADR
STOP HADR
TAKENOVER HADR

这些命令的语法如下：

START HADR ON DATABASE database-alias
[USER userid] [USING password] 
AS PRIMARY | STANDBY [BY FORCE]

STOP HADR ON DATABASE database-alias 
[USER userid] [USING password] 

TAKEOVER HADR ON DATABASE database-alias
[USER userid] [USING password] 
[BY FORCE]

带 AS PRIMARY 或 AS STANDBY 选项发出 START HADR 命令时，如果数据库还没有处于选项指定的角色，那么该命令将使数据库变为选项指定的角色。如果数据库尚未激活，那么这个命令还激活数据库。

STOP HADR 命令将 HADR 数据库（不管是主数据库还是备用数据库）变为标准数据库。任何与 HADR 相关的数据库配置参数都保持不变，以便将来重新将数据库激活为 HADR 数据库。

TAKEOVER HADR 命令只能在备用数据库上发出，该命令将备用数据库变为主数据库。如果不指定 BY FORCE 选项，则主数据库与备用数据库都切换角色。如果指定 BY FORCE 选项，则只有备用数据库变为主数据库（主数据库不变为备用数据库）。在这种情况下，备用数据库尝试停止原来的主数据库上的事务处理。然而，事务处理不一定会停止。只有在故障转移的条件下才使用 BY FORCE 选项强制接管事务。在带 BY FORCE 选项发出 TAKEOVER HADR 命令之前，应尽可能确保当前的主数据库肯定已经不能用，或者将其关闭。

您已经学习了 HADR 的概念，现在可以学习如何设置 HADR 环境。

在表 2 中，您将为名为 TEST1 的数据库设置一个 HADR 环境。TEST1 在数据库服务器 server1.torolab.ibm.com 上，位于实例 DB2INST1 之下。DB2INST1 的服务端口号或 SVCENAME 是 50000。

使用另一个数据库服务器 server2.torolab.ibm.com 作为备用服务器。TEST1 当前不在备用服务器上。

服务名	实例名	SVCENAME 或端口号	数据库名
server1.torolab.ibm.com	DB2INST1	50000	TEST1
server2.torolab.ibm.com	DB2INST1	50000	--

第一次初始化 HADR 时，执行图 13 所示的五个步骤：

确定主服务器和备用服务器。决定主机名、主机 IP 地址和每个 HADR 数据库的服务名或端口号。
您已经确定了主服务器和备用服务器。主服务器是 server1。备用服务器是 server2。

确保这两个服务器是通过 TCPIP 相互通信的。尝试用主机名在这两个服务器上相互 ping 对方。应确保输出没有错误。如果主机名不能使用，那么尝试使用它们的 TCPIP 地址。选用两者中最好用的一种用于 HADR 配置。

通过克隆主数据库创建备用数据库。

有两种方案可用于克隆主数据库：

一种方案是为主数据库做一个备份，并在备用数据库上恢复这个数据库备份。这种方案使用标准备份和恢复方法。
克隆主数据库的另一种方案是使用分割镜像。为主数据库做一个分割镜像，然后在备用服务器上初始化该分割镜像。当初始化分割镜像时，必须在 db2inidb 命令中使用 standby 选项，以便使用 mirror 和 snapshot 选项。

在这个例子种，使用备份/恢复方法来创建备用数据库。

首先为 server1 上的主数据库 TEST1 做一个备份：

接着，通过 ftp 将备份镜像传送到备用服务器，并恢复该备份镜像。

在备用数据库上，表空间和容器配置必须与主数据库严格对称。容器的名称、路径和大小必须与主数据库匹配。数据库的名称必须相同。如果有任何配置不匹配，HADR 就可能无法将数据复制到备用数据库。因此，在恢复数据库之前，应确保备用服务器与主服务器有相同的架构设置。

将备份镜像恢复到与主服务器上相同的位置。在主服务器上，发出 LIST DB DIRECTORY 命令将显示：

数据库位于主服务器上的 C: 盘上。当在备用服务器上恢复备份镜像时，也将它恢复到 C: 盘。在备用服务器 server2 上，发出以下命令来恢复 TEST1 数据库：

恢复完成之后，数据库处于 rollforward pending 状态。这是因为备份是从启用了归档日志记录的数据库中得到的。不要发出 ROLLFORWARD 命令使数据库脱离 rollforward pending 状态。数据库必须保持在这个状态，以便能够正确地以备用数据库启动 HADR。

在主数据库和备用数据库上设置以下 HADR 配置参数：

HADR_LOCAL_HOST
HADR_LOCAL_SVC
HADR_REMOTE_HOST
HADR_REMOTE_SVC
HADR_REMOTE_INST
HADR_SYNCMODE
LOGINDEXBUILD

在 HADR 环境中，将数据库配置参数 LOGINDEXBUILD 设置为 ON。否则，在当前或未来的主数据库服务器上进行的任何索引创建、重建或重组操作，都不能在使用 HADR 的当前或未来的备用数据库服务器上进行恢复。那些不能被恢复的索引被标记为无效，并且在 HADR 接管过程的最后，或者在即将访问底层表之前进行的 HADR 接管过程之后，这些索引将被隐式地重建。

在每个服务器上，为 HADR 分配一个没有被使用的 TCPIP 端口。对于用于 HADR 的端口号的选择没有严格的限制，只要它没有被另一个应用程序使用，并且不等于 SVCENAME 或 SVCENAME+1，那么就可以使用。

在主服务器上，为 HADR 使用端口号 70000。更新 Windows\System32\drivers\etc\services 文件，在其中添加以下一行：

在备用服务器上，为 HADR 使用 80000。（如果端口 70000 符合表 1 中描述的规则，那么也可以使用这个端口。出于演示的目的，我们选择端口 80000，因为更容易区分主服务器端口和备用服务器端口。）

在备用服务器上的 services 文件中添加以下一行：

为 HADR_SYNCMODE 使用默认值，即 NEARSYNC。

您已经有了配置 HADR 参数所需的所有信息。发出以下命令来配置备用服务器上的参数：

在主数据库服务器上，配置相同的一组参数：

在备用数据库上使用 START HADR 命令启动 HADR：
START HADR ON DB test1 AS STANDBY
在启动主数据库之前启动备用数据库。如果先启动主数据库，那么，如果没有在 HADR_TIMEOUT 数据库配置参数指定的期限内启动备用数据库，那么主数据库的启动过程就会失败。
在主数据库上启动 HADR，如下面的例子所示：
START HADR ON DB test1 AS PRIMARY
HADR 现在已经在主数据库和备用数据库上启动了。

当第一次启动主服务器时，它等待备用服务器与它联系。如果在指定期限内备用服务器没有与主服务器联系，那么 HADR 将不启动。这个期限可以用 HADR_TIMEOUT 配置参数（见表 1）来配置。这样做的目的是避免两个系统在偶然的情况下与主服务器同时启动。

在 HADR 启动过程中，数据库经历以下状态：local catch-up、remote catch-up pending、remote catch-up 和对等状态。日志被自动从主服务器传送到备用服务器，然后在备用服务器上重演。这是为了确保备用数据库跟上主数据库的变化。

强烈建议在主数据库和备用数据库所在的系统上使用相同的数据库配置参数和数据库管理器配置参数。否则，备用数据库就不会像主数据库一样执行。

一个例外是 LOGFILSIZ 数据库配置参数。这个参数的值被备用服务器所忽略。备用服务器自动创建与主数据库上的日志文件大小相匹配的日志文件。这保证了两个数据库上的日志文件是一致的。

您已经设置好一个 HADR 环境。当主数据库变得不能使用时，需要执行一个 HADR 接管操作，让备用数据库接管主数据库的角色，尽量减少连接到数据库的用户被中断的时间。通过以下两种方式中的一种执行 HADR 接管：

在主数据库与备用数据库之间切换数据库角色，也就是说，备用数据库变成主数据库，主数据库变成备用数据库。
从主数据库故障转移到备用数据库。

切换数据库角色的这种方案会导致连接到 HADR 主数据库的任何应用程序被迫断开连接。这种方案是设计用来与 DB2 自动客户机重路由特性一起使用的。如果启用了自动客户机重路由，那么在接管期间已有的连接将被断开，然后在接管完成之后重新建立与新的主服务器之间的连接。与原来的主数据库的新的客户机连接被自动路由到新的主服务器。（后面会详细讨论自动客户机重路由。）

为了切换数据库角色，在备用数据库上发出 TAKEOVER HADR 命令。该命令只能在备用数据库上发出，并且只能在对等状态下发出。可以使用 GET SNAPSHOT 命令来获得一个数据库的 HADR 状态。例如：

   GET SNAPSHOT FOR DATABASE ON test1

下面的命令在备用数据库 TEST1 上开始 HADR 数据库切换角色操作：

   TAKEOVER HADR ON DB test1

故障转移方案不切换数据库角色。在故障转移操作期间，备用数据库接管主数据库角色，但是主数据库不会变成备用数据库。

只有在主数据库变得不能使用，并且希望当前的备用数据库变为新的主数据库时，才能使用这种方案。如果主数据库仍然是活动的，而您又执行了 HADR 故障转移，那么最后就有了两个主数据库，从而导致数据可能被丢失。

在发出 TAKEOVER 命令之前，确保出故障的主数据库被完全禁用。当一个数据库碰到内部错误时，一般的 shutdown 命令并不能完全关闭它。因此，可能需要使用操作系统命令来删除进程、共享内存或网络连接之类的资源。

如果主数据库没有被完全禁用，那么备用数据库仍然会发送一条消息给主数据库，要求它关闭。然后，不管是否收到主数据库的确认而被告知主数据库已经关闭，备用数据库都切换为主数据库的角色。

为执行 HADR 故障转移，在备用数据库上带 BY FORCE 选项发出 TAKEOVER HADR 命令。注意，该命令只能在备用数据库上发出，并且只有当它处于对等状态或 remote catch-up pending 状态时才能发出。

下面的命令在数据库 TEST1 上开始一个 HADR 故障转移操作：

   TAKEOVER HADR ON DB test1 BY FORCE

表 3 和 4 总结了在备用数据库上发出的 TAKEOVER HADR 命令的行为，以及备用数据库所处的对应的 HADR 状态：

备用数据库的状态	接管行为
对等	主数据库和备用数据库都切换角色
Local catch-up or remote catch-up	错误
Remote catch-up pending	错误

备用数据库的状态	接管行为
对等	备用数据库通知主数据库关闭。备用数据库停止接收来自主数据库的日志，完成它已经收到的日志的重演，然后变成主数据库。备用数据库不用等到主数据库发来通知确认它受到接管通知或者它已经关闭
Local catch-up OR remote catch-up	错误
Remote catch-up pending	备用数据库变成主数据库

您已经看到了如何设置 HADR 环境，以及如何使用数据库角色切换和故障转移方案执行接管。

您学习了如何使用 HADR 使数据库具有高可用性。如果主数据库停机，那么它的备用数据库将接管，并成为新的主数据库。

然而，这并不意味着客户机应用程序自动知道这次的接管，并且能够聪明地在接管完成之后连接到新的主服务器，而不是连接到原来的主服务器。实际上，如果只是启用 HADR 的话，客户机并不会在接管完成之后自动连接到新的主数据库。它们仍然尝试连接到原来的主数据库，由于原来的主服务器已经变成备用服务器（数据库角色切换），或者原来的主服务器已经被禁用（故障转移），这样的连接尝试将遭到失败。

这就是为什么需要 DB2 自动客户机重路由特性。当一个 HADR 环境启用了自动客户机重路由特性时，在接管完成之后，所有当前的和新的客户机连接都自动被路由到新的主服务器，所以应用程序在很短的中断之后又可以继续它们的工作。

为了启用自动客户机重路由特性，在主数据库上发出 UPDATE ALTERNATE SERVER 命令。该命令的语法如下：

UPDATE ALTERNATE SERVER FOR DATABASE database-alias
USING HOSTNAME alternate-server-hostname PORT port-number

为了在 server1 上的 TEST1 数据库上启用客户机重路由特性，以便在接管之后已有的和新的客户机连接被重新路由到 server2，在 server1 上发出以下命令：

UPDATE ALTERNATE SERVER FOR DATABASE test1 USING 
HOSTNAME server2.torolab.ibm.com PORT 50000

在这个例子中，50000 是 SVCENAME 端口，而不是 HADR 端口。

备用服务器信息存储在 server1 的数据库目录中。如果发出一个 LIST DB DIRECTORY 命令，那么可以注意到备用服务器信息（主机名和端口号）已经被添加：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

当一个远程客户机应用程序连接到这个数据库时，客户机获得备用服务器信息并将其存储在本地的数据库目录中。当主服务器 server1 变得不能使用时，该客户机就通过备用服务器信息知道要连接到哪个服务器。

由于客户机只有在建立与主数据库服务器的连接时才能得到备用服务器信息，因此，在执行接管操作之前应该发出 ALTERNATE SERVER 命令，确保在接管之前客户机至少成功地建立过一次连接。

现在让我们来看一个关于如何在启用了自动客户机重路由特性的数据库上执行接管的例子。

您已经使用 “初始化 HADR” 小节中讨论的步骤为 TEST1 数据库设置了 HADR 环境，并且还在 server1 上运行了 UPDATE ALTERNATE SERVER 命令来指定 server2 作为它的备用服务器。

为了演示客户机重路由特性如何在 HADR 环境中工作，首先建立到 server1 上的 TEST1 数据库的一个远程客户机连接，然后在备用数据库服务器 server2 上执行接管。如果 HADR 和客户机重路由特性工作正常，那么在接管完成之后，应该可以看到客户机连接被自动重新路由到 server2。

在这个例子中，不带 BY FORCE 选项执行一个接管。

首先，建立到 server1 上的 TEST1 数据库的一个远程客户机连接。为此，只需在一个远程 DB2 客户机上发出一条 CONNECT TO DATABASE 命令：

CONNECT TO DB test1 USER user1

为了建立那样的连接，客户机必须已经被配置为连接到 server1。关于如何配置远程客户机连接的信息，请参考本系列中的第一篇教程。

在建立连接之后，主服务器上的备用服务器信息被获取并存储在客户机的数据库目录中：

 Database alias                       = TEST1
 Database name                        = TEST1
 Node name                            = server1
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Remote
 Catalog database partition number    = -1
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

确保该连接已成功建立，并且可以查询 TEST1 数据库。在 server1 上发出一条 LIST APPLICATION 命令，它应该显示数据库 TEST1 上的远程客户机连接：

D:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      8          9.26.94.149.24336.060601000305
                                                         TEST1    1

接着，在 TEST1 数据库上执行接管。在备用服务器 server2 上发出以下命令：

TAKEOVER HADR ON DB test1

让我们看看这次接管完成后远程客户机连接有什么变化。

再次尝试从客户机查询 TEST1 数据库。对 TEST1 数据库的任何查询应该都会返回一个错误消息。例如，从客户机连接发出一条 LIST TABLES 命令：

D:\Programs\IBM\SQLLIB\BIN>db2 list tables
SQL30108N A connection failed but has been re-established. 
The hostname or IP address is "server2" and the service name or port number is "50000". 
Special registers may or may not be re-attempted (Reason code = "1").  
SQLSTATE=08506

这条消息告诉我们，到 server1 的已有连接已经失效。但是，该连接已经被重新建立，并且是连接到主机名为 'server2' 的一个服务器，也就是我们的备用服务器。

这证明客户机重路由特性在起作用。现在您已经连接到新的主服务器，即 server2。

在 server2 上发出一条 LIST APPLICATIONS 命令。您可以看到，远程客户机连接已经被重新路由到那里：

H:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      55         9.26.94.149.29200.060601001803
                                                         TEST1    1

如果再次查询数据库，那么可以从新的主服务器得到一个响应。而且，到原来主服务器的新连接也被重新路由到新的主服务器。

使用 GET SNAPSHOT 命令可以获得数据库的 HADR 状态。在 server2 上发出以下命令，应该可以看到 server2 已经接管了主数据库角色：

db2 "get snapshot for database on test1"

  HADR Status
  Role                   = Primary
  State                  = Peer
  Synchronization mode   = Nearsync
  Connection status      = Connected , 05/31/2006 20:17:24.989618
  Heartbeats missed      = 0
  Local host             = server2.torolab.ibm.com
  Local service          = 80000
  Remote host            = server1.torolab.ibm.com
  Remote service         = 70000
  Remote instance        = db2inst1
  timeout(seconds)       = 120
  Primary log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Standby log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Log gap running average(bytes) = 0

在执行接管操作之后，如果出故障的数据库又可以使用，它不会自动恢复主数据库的角色。

通过以下步骤可以使之重新成为主数据库：

修复原来的主数据库所在的系统。这包括修复有问题的硬件或者重新启动崩溃的操作系统。
重新启动出故障的主数据库，使之成为一个备用数据库。
执行一个接管操作，使之接管主数据库的角色。

如果数据库的两个版本中有不兼容的日志流，那么重新整合就会失败。具体来说，HADR 要求，原来的主数据库没有应用在其接管成为新的主数据库之前没有反映到原来的备用数据库上的任何已日志记录的操作。如果已经发生这样的事情，那么通过恢复新的主数据库的备份镜像，或者通过初始化一个分割镜像，那么重新启动原来的主数据库，使之成为备用数据库。

当原来的主数据库重新以备用数据库的角色加入 HADR 对之后，执行一个接管操作来切换数据库的角色，使原来的主数据库再次成为主数据库。

使用 STOP HADR 命令可以停止主数据库或备用数据库上的 HADR 操作。您可以停止其中一个数据库上的 HADR，也可以同时停止两个数据库上的 HADR。如果要在备用系统上执行维护操作，那么只需停止备用数据库上的 HADR。如果要完全停用 HADR，那么应该停止两个数据库上的 HADR。

如果您想停止指定的数据库，但是又想维持它作为 HADR 主数据库或备用数据库的角色，那么就不要发出 STOP HADR 命令。如果发出该命令，那么数据库将成为一个标准数据库，之后如果要恢复它的 HADR 数据库的角色，就需要重新初始化。相反，这时应该发出 DEACTIVATE DATABASE 命令。

为了停止 TEST1 数据库上的 HADR，发出：

STOP HADR ON DB test1

您可以看到，HADR 是实现高可用性解决方案的一个强大的特性。提供了一个名为 HADR 向导的图形化用户界面工具，以帮助您设置和配置 HADR。

该向导将指导您完成设置 HADR 环境、停止和启动 HADR 以及切换 HADR 下的数据库角色这些过程所需的任务。要启动该向导，可以进入 Control Center 并在数据库上单击右键。选择 High Availability Disaster Recovery。选择设置或管理 HADR：

如果选择 Set Up，那么就会打开一个如图 15 所示的逐步向导。

如果使用 Control Center 设置 HADR 环境，则会自动启用自动客户机重路由特性。

阅读(23826) | 评论(0) | 转发(0) |

上一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（4）

下一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（6）

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

16024965号-6

高可用性灾难恢复（HADR）

DB2 高可用性灾难恢复（HADR）是一种数据库复制特性，它提供了一种高可用性解决方案。目前，HADR 只用于单分区数据库环境。

为了设置 HADR 环境，要更新一些数据库配置参数。

首先，必须启用主数据库上的归档日志记录。请参阅备份和恢复教程，以了解如何启用归档日志记录。

表 1 列出了与 HADR 相关的数据库配置参数的描述。本教程后面将给出一个关于如何更新这些参数的例子。

与 HADR 相关的数据库配置参数	描述
HADR_LOCAL_HOST	指定 HADR TCPIP 通信的本地主机。主机名和 IP 地址都可以使用
HADR_LOCAL_SVC	指定 TCPIP 服务名和端口号，HADR 进程将在本地主机上接受该服务或端口的连接。这个端口不能与 HADR 实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_HOST	指定远程 HADR 节点的 TCPIP 主机名或 IP 地址
HADR_REMOTE_SVC	指定 TCPIP 服务名或端口号，HADR 进程将在远程节点上接受该服务或端口的连接。这个端口不能与远程实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_INST	指定远程服务器的实例名。DB2 Control Center 之类的管理工具将使用这个参数与远程服务器联系
HADR_TIMEOUT	HADR 进程在认为一次通信尝试失败之前所等待的时间（以秒为单位）。默认值为 120 秒
HADR_SYNCMODE	指定同步模式。它决定当系统处于对等状态时，主日志写与备用数据库如何同步。有效值有 SYNC、NEARSYNC 和 ASYNC。默认值为 NEARSYNC。（本节后面将讨论对等状态）。
HADR_DB_ROLE	指定一个数据库当前的角色。有效值有 STANDARD、PRIMARY 和 STANDBY。STANDARD 意味着数据库没有启用 HADR。

当备用数据库第一次启动时，它进入 local catch-up 状态。本地日志路径中的日志文件（如果有的话）将被读取，并应用到备用数据库。

当到达本地日志文件的最后时，备用数据库进入 remote catch-up 状态。它重演主数据库的归档日志和活动日志，直到备用数据库应用了最近的活动日志。

当主系统上的所有日志文件都已经被重演时，主数据库和备用数据库就进入对等（peer）状态。

在同步模式中，日志写只有在以下情况下才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库的日志文件中。

主数据库与备用数据库中的日志记录几乎（或近似）是同步的，因为只有在以下情况下，日志写才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库上的主存中。

在这种模式下，主数据库不等待收到备用数据库的通知。只有在以下情况下，日志写才被认为是成功的：

日志记录已经被写到主数据库上的日志文件中。
日志记录已经被传送到备用数据库；不需要通知。

HADR 是通过以下三个简单的命令来管理的：

START HADR
STOP HADR
TAKENOVER HADR

这些命令的语法如下：

START HADR ON DATABASE database-alias
[USER userid] [USING password] 
AS PRIMARY | STANDBY [BY FORCE]

STOP HADR ON DATABASE database-alias 
[USER userid] [USING password] 

TAKEOVER HADR ON DATABASE database-alias
[USER userid] [USING password] 
[BY FORCE]

您已经学习了 HADR 的概念，现在可以学习如何设置 HADR 环境。

使用另一个数据库服务器 server2.torolab.ibm.com 作为备用服务器。TEST1 当前不在备用服务器上。

服务名	实例名	SVCENAME 或端口号	数据库名
server1.torolab.ibm.com	DB2INST1	50000	TEST1
server2.torolab.ibm.com	DB2INST1	50000	--

第一次初始化 HADR 时，执行图 13 所示的五个步骤：

确定主服务器和备用服务器。决定主机名、主机 IP 地址和每个 HADR 数据库的服务名或端口号。
您已经确定了主服务器和备用服务器。主服务器是 server1。备用服务器是 server2。

确保这两个服务器是通过 TCPIP 相互通信的。尝试用主机名在这两个服务器上相互 ping 对方。应确保输出没有错误。如果主机名不能使用，那么尝试使用它们的 TCPIP 地址。选用两者中最好用的一种用于 HADR 配置。

通过克隆主数据库创建备用数据库。

有两种方案可用于克隆主数据库：

一种方案是为主数据库做一个备份，并在备用数据库上恢复这个数据库备份。这种方案使用标准备份和恢复方法。
克隆主数据库的另一种方案是使用分割镜像。为主数据库做一个分割镜像，然后在备用服务器上初始化该分割镜像。当初始化分割镜像时，必须在 db2inidb 命令中使用 standby 选项，以便使用 mirror 和 snapshot 选项。

在这个例子种，使用备份/恢复方法来创建备用数据库。

首先为 server1 上的主数据库 TEST1 做一个备份：

BACKUP DB test1

接着，通过 ftp 将备份镜像传送到备用服务器，并恢复该备份镜像。

将备份镜像恢复到与主服务器上相同的位置。在主服务器上，发出 LIST DB DIRECTORY 命令将显示：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            =
 Alternate server port number         =

数据库位于主服务器上的 C: 盘上。当在备用服务器上恢复备份镜像时，也将它恢复到 C: 盘。在备用服务器 server2 上，发出以下命令来恢复 TEST1 数据库：

RESTORE DB test1 ON C:

在主数据库和备用数据库上设置以下 HADR 配置参数：

HADR_LOCAL_HOST
HADR_LOCAL_SVC
HADR_REMOTE_HOST
HADR_REMOTE_SVC
HADR_REMOTE_INST
HADR_SYNCMODE
LOGINDEXBUILD

在主服务器上，为 HADR 使用端口号 70000。更新 Windows\System32\drivers\etc\services 文件，在其中添加以下一行：

Hadr_port 	70000/tcp

在备用服务器上的 services 文件中添加以下一行：

Hadr_port 	80000/tcp

为 HADR_SYNCMODE 使用默认值，即 NEARSYNC。

您已经有了配置 HADR 参数所需的所有信息。发出以下命令来配置备用服务器上的参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在主数据库服务器上，配置相同的一组参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在备用数据库上使用 START HADR 命令启动 HADR：
START HADR ON DB test1 AS STANDBY
在启动主数据库之前启动备用数据库。如果先启动主数据库，那么，如果没有在 HADR_TIMEOUT 数据库配置参数指定的期限内启动备用数据库，那么主数据库的启动过程就会失败。
在主数据库上启动 HADR，如下面的例子所示：
START HADR ON DB test1 AS PRIMARY
HADR 现在已经在主数据库和备用数据库上启动了。

当第一次启动主服务器时，它等待备用服务器与它联系。如果在指定期限内备用服务器没有与主服务器联系，那么 HADR 将不启动。这个期限可以用 HADR_TIMEOUT 配置参数（见表 1）来配置。这样做的目的是避免两个系统在偶然的情况下与主服务器同时启动。

在 HADR 启动过程中，数据库经历以下状态：local catch-up、remote catch-up pending、remote catch-up 和对等状态。日志被自动从主服务器传送到备用服务器，然后在备用服务器上重演。这是为了确保备用数据库跟上主数据库的变化。

强烈建议在主数据库和备用数据库所在的系统上使用相同的数据库配置参数和数据库管理器配置参数。否则，备用数据库就不会像主数据库一样执行。

一个例外是 LOGFILSIZ 数据库配置参数。这个参数的值被备用服务器所忽略。备用服务器自动创建与主数据库上的日志文件大小相匹配的日志文件。这保证了两个数据库上的日志文件是一致的。

在主数据库与备用数据库之间切换数据库角色，也就是说，备用数据库变成主数据库，主数据库变成备用数据库。
从主数据库故障转移到备用数据库。

   GET SNAPSHOT FOR DATABASE ON test1

下面的命令在备用数据库 TEST1 上开始 HADR 数据库切换角色操作：

   TAKEOVER HADR ON DB test1

故障转移方案不切换数据库角色。在故障转移操作期间，备用数据库接管主数据库角色，但是主数据库不会变成备用数据库。

下面的命令在数据库 TEST1 上开始一个 HADR 故障转移操作：

   TAKEOVER HADR ON DB test1 BY FORCE

表 3 和 4 总结了在备用数据库上发出的 TAKEOVER HADR 命令的行为，以及备用数据库所处的对应的 HADR 状态：

备用数据库的状态	接管行为
对等	主数据库和备用数据库都切换角色
Local catch-up or remote catch-up	错误
Remote catch-up pending	错误

备用数据库的状态	接管行为
对等	备用数据库通知主数据库关闭。备用数据库停止接收来自主数据库的日志，完成它已经收到的日志的重演，然后变成主数据库。备用数据库不用等到主数据库发来通知确认它受到接管通知或者它已经关闭
Local catch-up OR remote catch-up	错误
Remote catch-up pending	备用数据库变成主数据库

您已经看到了如何设置 HADR 环境，以及如何使用数据库角色切换和故障转移方案执行接管。

您学习了如何使用 HADR 使数据库具有高可用性。如果主数据库停机，那么它的备用数据库将接管，并成为新的主数据库。

为了启用自动客户机重路由特性，在主数据库上发出 UPDATE ALTERNATE SERVER 命令。该命令的语法如下：

UPDATE ALTERNATE SERVER FOR DATABASE database-alias
USING HOSTNAME alternate-server-hostname PORT port-number

为了在 server1 上的 TEST1 数据库上启用客户机重路由特性，以便在接管之后已有的和新的客户机连接被重新路由到 server2，在 server1 上发出以下命令：

UPDATE ALTERNATE SERVER FOR DATABASE test1 USING 
HOSTNAME server2.torolab.ibm.com PORT 50000

在这个例子中，50000 是 SVCENAME 端口，而不是 HADR 端口。

备用服务器信息存储在 server1 的数据库目录中。如果发出一个 LIST DB DIRECTORY 命令，那么可以注意到备用服务器信息（主机名和端口号）已经被添加：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

现在让我们来看一个关于如何在启用了自动客户机重路由特性的数据库上执行接管的例子。

在这个例子中，不带 BY FORCE 选项执行一个接管。

首先，建立到 server1 上的 TEST1 数据库的一个远程客户机连接。为此，只需在一个远程 DB2 客户机上发出一条 CONNECT TO DATABASE 命令：

CONNECT TO DB test1 USER user1

为了建立那样的连接，客户机必须已经被配置为连接到 server1。关于如何配置远程客户机连接的信息，请参考本系列中的第一篇教程。

在建立连接之后，主服务器上的备用服务器信息被获取并存储在客户机的数据库目录中：

 Database alias                       = TEST1
 Database name                        = TEST1
 Node name                            = server1
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Remote
 Catalog database partition number    = -1
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

确保该连接已成功建立，并且可以查询 TEST1 数据库。在 server1 上发出一条 LIST APPLICATION 命令，它应该显示数据库 TEST1 上的远程客户机连接：

D:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      8          9.26.94.149.24336.060601000305
                                                         TEST1    1

接着，在 TEST1 数据库上执行接管。在备用服务器 server2 上发出以下命令：

TAKEOVER HADR ON DB test1

让我们看看这次接管完成后远程客户机连接有什么变化。

再次尝试从客户机查询 TEST1 数据库。对 TEST1 数据库的任何查询应该都会返回一个错误消息。例如，从客户机连接发出一条 LIST TABLES 命令：

D:\Programs\IBM\SQLLIB\BIN>db2 list tables
SQL30108N A connection failed but has been re-established. 
The hostname or IP address is "server2" and the service name or port number is "50000". 
Special registers may or may not be re-attempted (Reason code = "1").  
SQLSTATE=08506

这证明客户机重路由特性在起作用。现在您已经连接到新的主服务器，即 server2。

在 server2 上发出一条 LIST APPLICATIONS 命令。您可以看到，远程客户机连接已经被重新路由到那里：

H:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      55         9.26.94.149.29200.060601001803
                                                         TEST1    1

如果再次查询数据库，那么可以从新的主服务器得到一个响应。而且，到原来主服务器的新连接也被重新路由到新的主服务器。

使用 GET SNAPSHOT 命令可以获得数据库的 HADR 状态。在 server2 上发出以下命令，应该可以看到 server2 已经接管了主数据库角色：

db2 "get snapshot for database on test1"

  HADR Status
  Role                   = Primary
  State                  = Peer
  Synchronization mode   = Nearsync
  Connection status      = Connected , 05/31/2006 20:17:24.989618
  Heartbeats missed      = 0
  Local host             = server2.torolab.ibm.com
  Local service          = 80000
  Remote host            = server1.torolab.ibm.com
  Remote service         = 70000
  Remote instance        = db2inst1
  timeout(seconds)       = 120
  Primary log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Standby log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Log gap running average(bytes) = 0

在执行接管操作之后，如果出故障的数据库又可以使用，它不会自动恢复主数据库的角色。

通过以下步骤可以使之重新成为主数据库：

修复原来的主数据库所在的系统。这包括修复有问题的硬件或者重新启动崩溃的操作系统。
重新启动出故障的主数据库，使之成为一个备用数据库。
执行一个接管操作，使之接管主数据库的角色。

当原来的主数据库重新以备用数据库的角色加入 HADR 对之后，执行一个接管操作来切换数据库的角色，使原来的主数据库再次成为主数据库。

为了停止 TEST1 数据库上的 HADR，发出：

STOP HADR ON DB test1

您可以看到，HADR 是实现高可用性解决方案的一个强大的特性。提供了一个名为 HADR 向导的图形化用户界面工具，以帮助您设置和配置 HADR。

如果选择 Set Up，那么就会打开一个如图 15 所示的逐步向导。

如果使用 Control Center 设置 HADR 环境，则会自动启用自动客户机重路由特性。

阅读(23825) | 评论(0) | 转发(0) |

上一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（4）

下一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（6）

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

16024965号-6

高可用性灾难恢复（HADR）

DB2 高可用性灾难恢复（HADR）是一种数据库复制特性，它提供了一种高可用性解决方案。目前，HADR 只用于单分区数据库环境。

为了设置 HADR 环境，要更新一些数据库配置参数。

首先，必须启用主数据库上的归档日志记录。请参阅备份和恢复教程，以了解如何启用归档日志记录。

表 1 列出了与 HADR 相关的数据库配置参数的描述。本教程后面将给出一个关于如何更新这些参数的例子。

与 HADR 相关的数据库配置参数	描述
HADR_LOCAL_HOST	指定 HADR TCPIP 通信的本地主机。主机名和 IP 地址都可以使用
HADR_LOCAL_SVC	指定 TCPIP 服务名和端口号，HADR 进程将在本地主机上接受该服务或端口的连接。这个端口不能与 HADR 实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_HOST	指定远程 HADR 节点的 TCPIP 主机名或 IP 地址
HADR_REMOTE_SVC	指定 TCPIP 服务名或端口号，HADR 进程将在远程节点上接受该服务或端口的连接。这个端口不能与远程实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_INST	指定远程服务器的实例名。DB2 Control Center 之类的管理工具将使用这个参数与远程服务器联系
HADR_TIMEOUT	HADR 进程在认为一次通信尝试失败之前所等待的时间（以秒为单位）。默认值为 120 秒
HADR_SYNCMODE	指定同步模式。它决定当系统处于对等状态时，主日志写与备用数据库如何同步。有效值有 SYNC、NEARSYNC 和 ASYNC。默认值为 NEARSYNC。（本节后面将讨论对等状态）。
HADR_DB_ROLE	指定一个数据库当前的角色。有效值有 STANDARD、PRIMARY 和 STANDBY。STANDARD 意味着数据库没有启用 HADR。

当备用数据库第一次启动时，它进入 local catch-up 状态。本地日志路径中的日志文件（如果有的话）将被读取，并应用到备用数据库。

当到达本地日志文件的最后时，备用数据库进入 remote catch-up 状态。它重演主数据库的归档日志和活动日志，直到备用数据库应用了最近的活动日志。

当主系统上的所有日志文件都已经被重演时，主数据库和备用数据库就进入对等（peer）状态。

在同步模式中，日志写只有在以下情况下才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库的日志文件中。

主数据库与备用数据库中的日志记录几乎（或近似）是同步的，因为只有在以下情况下，日志写才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库上的主存中。

在这种模式下，主数据库不等待收到备用数据库的通知。只有在以下情况下，日志写才被认为是成功的：

日志记录已经被写到主数据库上的日志文件中。
日志记录已经被传送到备用数据库；不需要通知。

HADR 是通过以下三个简单的命令来管理的：

START HADR
STOP HADR
TAKENOVER HADR

这些命令的语法如下：

START HADR ON DATABASE database-alias
[USER userid] [USING password] 
AS PRIMARY | STANDBY [BY FORCE]

STOP HADR ON DATABASE database-alias 
[USER userid] [USING password] 

TAKEOVER HADR ON DATABASE database-alias
[USER userid] [USING password] 
[BY FORCE]

您已经学习了 HADR 的概念，现在可以学习如何设置 HADR 环境。

使用另一个数据库服务器 server2.torolab.ibm.com 作为备用服务器。TEST1 当前不在备用服务器上。

服务名	实例名	SVCENAME 或端口号	数据库名
server1.torolab.ibm.com	DB2INST1	50000	TEST1
server2.torolab.ibm.com	DB2INST1	50000	--

第一次初始化 HADR 时，执行图 13 所示的五个步骤：

确定主服务器和备用服务器。决定主机名、主机 IP 地址和每个 HADR 数据库的服务名或端口号。
您已经确定了主服务器和备用服务器。主服务器是 server1。备用服务器是 server2。

确保这两个服务器是通过 TCPIP 相互通信的。尝试用主机名在这两个服务器上相互 ping 对方。应确保输出没有错误。如果主机名不能使用，那么尝试使用它们的 TCPIP 地址。选用两者中最好用的一种用于 HADR 配置。

通过克隆主数据库创建备用数据库。

有两种方案可用于克隆主数据库：

一种方案是为主数据库做一个备份，并在备用数据库上恢复这个数据库备份。这种方案使用标准备份和恢复方法。
克隆主数据库的另一种方案是使用分割镜像。为主数据库做一个分割镜像，然后在备用服务器上初始化该分割镜像。当初始化分割镜像时，必须在 db2inidb 命令中使用 standby 选项，以便使用 mirror 和 snapshot 选项。

在这个例子种，使用备份/恢复方法来创建备用数据库。

首先为 server1 上的主数据库 TEST1 做一个备份：

BACKUP DB test1

接着，通过 ftp 将备份镜像传送到备用服务器，并恢复该备份镜像。

将备份镜像恢复到与主服务器上相同的位置。在主服务器上，发出 LIST DB DIRECTORY 命令将显示：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            =
 Alternate server port number         =

数据库位于主服务器上的 C: 盘上。当在备用服务器上恢复备份镜像时，也将它恢复到 C: 盘。在备用服务器 server2 上，发出以下命令来恢复 TEST1 数据库：

RESTORE DB test1 ON C:

在主数据库和备用数据库上设置以下 HADR 配置参数：

HADR_LOCAL_HOST
HADR_LOCAL_SVC
HADR_REMOTE_HOST
HADR_REMOTE_SVC
HADR_REMOTE_INST
HADR_SYNCMODE
LOGINDEXBUILD

在主服务器上，为 HADR 使用端口号 70000。更新 Windows\System32\drivers\etc\services 文件，在其中添加以下一行：

Hadr_port 	70000/tcp

在备用服务器上的 services 文件中添加以下一行：

Hadr_port 	80000/tcp

为 HADR_SYNCMODE 使用默认值，即 NEARSYNC。

您已经有了配置 HADR 参数所需的所有信息。发出以下命令来配置备用服务器上的参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在主数据库服务器上，配置相同的一组参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在备用数据库上使用 START HADR 命令启动 HADR：
START HADR ON DB test1 AS STANDBY
在启动主数据库之前启动备用数据库。如果先启动主数据库，那么，如果没有在 HADR_TIMEOUT 数据库配置参数指定的期限内启动备用数据库，那么主数据库的启动过程就会失败。
在主数据库上启动 HADR，如下面的例子所示：
START HADR ON DB test1 AS PRIMARY
HADR 现在已经在主数据库和备用数据库上启动了。

当第一次启动主服务器时，它等待备用服务器与它联系。如果在指定期限内备用服务器没有与主服务器联系，那么 HADR 将不启动。这个期限可以用 HADR_TIMEOUT 配置参数（见表 1）来配置。这样做的目的是避免两个系统在偶然的情况下与主服务器同时启动。

在 HADR 启动过程中，数据库经历以下状态：local catch-up、remote catch-up pending、remote catch-up 和对等状态。日志被自动从主服务器传送到备用服务器，然后在备用服务器上重演。这是为了确保备用数据库跟上主数据库的变化。

强烈建议在主数据库和备用数据库所在的系统上使用相同的数据库配置参数和数据库管理器配置参数。否则，备用数据库就不会像主数据库一样执行。

一个例外是 LOGFILSIZ 数据库配置参数。这个参数的值被备用服务器所忽略。备用服务器自动创建与主数据库上的日志文件大小相匹配的日志文件。这保证了两个数据库上的日志文件是一致的。

在主数据库与备用数据库之间切换数据库角色，也就是说，备用数据库变成主数据库，主数据库变成备用数据库。
从主数据库故障转移到备用数据库。

   GET SNAPSHOT FOR DATABASE ON test1

下面的命令在备用数据库 TEST1 上开始 HADR 数据库切换角色操作：

   TAKEOVER HADR ON DB test1

故障转移方案不切换数据库角色。在故障转移操作期间，备用数据库接管主数据库角色，但是主数据库不会变成备用数据库。

下面的命令在数据库 TEST1 上开始一个 HADR 故障转移操作：

   TAKEOVER HADR ON DB test1 BY FORCE

表 3 和 4 总结了在备用数据库上发出的 TAKEOVER HADR 命令的行为，以及备用数据库所处的对应的 HADR 状态：

备用数据库的状态	接管行为
对等	主数据库和备用数据库都切换角色
Local catch-up or remote catch-up	错误
Remote catch-up pending	错误

备用数据库的状态	接管行为
对等	备用数据库通知主数据库关闭。备用数据库停止接收来自主数据库的日志，完成它已经收到的日志的重演，然后变成主数据库。备用数据库不用等到主数据库发来通知确认它受到接管通知或者它已经关闭
Local catch-up OR remote catch-up	错误
Remote catch-up pending	备用数据库变成主数据库

您已经看到了如何设置 HADR 环境，以及如何使用数据库角色切换和故障转移方案执行接管。

您学习了如何使用 HADR 使数据库具有高可用性。如果主数据库停机，那么它的备用数据库将接管，并成为新的主数据库。

为了启用自动客户机重路由特性，在主数据库上发出 UPDATE ALTERNATE SERVER 命令。该命令的语法如下：

UPDATE ALTERNATE SERVER FOR DATABASE database-alias
USING HOSTNAME alternate-server-hostname PORT port-number

为了在 server1 上的 TEST1 数据库上启用客户机重路由特性，以便在接管之后已有的和新的客户机连接被重新路由到 server2，在 server1 上发出以下命令：

UPDATE ALTERNATE SERVER FOR DATABASE test1 USING 
HOSTNAME server2.torolab.ibm.com PORT 50000

在这个例子中，50000 是 SVCENAME 端口，而不是 HADR 端口。

备用服务器信息存储在 server1 的数据库目录中。如果发出一个 LIST DB DIRECTORY 命令，那么可以注意到备用服务器信息（主机名和端口号）已经被添加：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

现在让我们来看一个关于如何在启用了自动客户机重路由特性的数据库上执行接管的例子。

在这个例子中，不带 BY FORCE 选项执行一个接管。

首先，建立到 server1 上的 TEST1 数据库的一个远程客户机连接。为此，只需在一个远程 DB2 客户机上发出一条 CONNECT TO DATABASE 命令：

CONNECT TO DB test1 USER user1

为了建立那样的连接，客户机必须已经被配置为连接到 server1。关于如何配置远程客户机连接的信息，请参考本系列中的第一篇教程。

在建立连接之后，主服务器上的备用服务器信息被获取并存储在客户机的数据库目录中：

 Database alias                       = TEST1
 Database name                        = TEST1
 Node name                            = server1
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Remote
 Catalog database partition number    = -1
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

确保该连接已成功建立，并且可以查询 TEST1 数据库。在 server1 上发出一条 LIST APPLICATION 命令，它应该显示数据库 TEST1 上的远程客户机连接：

D:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      8          9.26.94.149.24336.060601000305
                                                         TEST1    1

接着，在 TEST1 数据库上执行接管。在备用服务器 server2 上发出以下命令：

TAKEOVER HADR ON DB test1

让我们看看这次接管完成后远程客户机连接有什么变化。

再次尝试从客户机查询 TEST1 数据库。对 TEST1 数据库的任何查询应该都会返回一个错误消息。例如，从客户机连接发出一条 LIST TABLES 命令：

D:\Programs\IBM\SQLLIB\BIN>db2 list tables
SQL30108N A connection failed but has been re-established. 
The hostname or IP address is "server2" and the service name or port number is "50000". 
Special registers may or may not be re-attempted (Reason code = "1").  
SQLSTATE=08506

这证明客户机重路由特性在起作用。现在您已经连接到新的主服务器，即 server2。

在 server2 上发出一条 LIST APPLICATIONS 命令。您可以看到，远程客户机连接已经被重新路由到那里：

H:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      55         9.26.94.149.29200.060601001803
                                                         TEST1    1

如果再次查询数据库，那么可以从新的主服务器得到一个响应。而且，到原来主服务器的新连接也被重新路由到新的主服务器。

使用 GET SNAPSHOT 命令可以获得数据库的 HADR 状态。在 server2 上发出以下命令，应该可以看到 server2 已经接管了主数据库角色：

db2 "get snapshot for database on test1"

  HADR Status
  Role                   = Primary
  State                  = Peer
  Synchronization mode   = Nearsync
  Connection status      = Connected , 05/31/2006 20:17:24.989618
  Heartbeats missed      = 0
  Local host             = server2.torolab.ibm.com
  Local service          = 80000
  Remote host            = server1.torolab.ibm.com
  Remote service         = 70000
  Remote instance        = db2inst1
  timeout(seconds)       = 120
  Primary log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Standby log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Log gap running average(bytes) = 0

在执行接管操作之后，如果出故障的数据库又可以使用，它不会自动恢复主数据库的角色。

通过以下步骤可以使之重新成为主数据库：

修复原来的主数据库所在的系统。这包括修复有问题的硬件或者重新启动崩溃的操作系统。
重新启动出故障的主数据库，使之成为一个备用数据库。
执行一个接管操作，使之接管主数据库的角色。

当原来的主数据库重新以备用数据库的角色加入 HADR 对之后，执行一个接管操作来切换数据库的角色，使原来的主数据库再次成为主数据库。

为了停止 TEST1 数据库上的 HADR，发出：

STOP HADR ON DB test1

您可以看到，HADR 是实现高可用性解决方案的一个强大的特性。提供了一个名为 HADR 向导的图形化用户界面工具，以帮助您设置和配置 HADR。

如果选择 Set Up，那么就会打开一个如图 15 所示的逐步向导。

如果使用 Control Center 设置 HADR 环境，则会自动启用自动客户机重路由特性。

阅读(23824) | 评论(0) | 转发(0) |

上一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（4）

下一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（6）

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

16024965号-6

高可用性灾难恢复（HADR）

DB2 高可用性灾难恢复（HADR）是一种数据库复制特性，它提供了一种高可用性解决方案。目前，HADR 只用于单分区数据库环境。

为了设置 HADR 环境，要更新一些数据库配置参数。

首先，必须启用主数据库上的归档日志记录。请参阅备份和恢复教程，以了解如何启用归档日志记录。

表 1 列出了与 HADR 相关的数据库配置参数的描述。本教程后面将给出一个关于如何更新这些参数的例子。

与 HADR 相关的数据库配置参数	描述
HADR_LOCAL_HOST	指定 HADR TCPIP 通信的本地主机。主机名和 IP 地址都可以使用
HADR_LOCAL_SVC	指定 TCPIP 服务名和端口号，HADR 进程将在本地主机上接受该服务或端口的连接。这个端口不能与 HADR 实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_HOST	指定远程 HADR 节点的 TCPIP 主机名或 IP 地址
HADR_REMOTE_SVC	指定 TCPIP 服务名或端口号，HADR 进程将在远程节点上接受该服务或端口的连接。这个端口不能与远程实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_INST	指定远程服务器的实例名。DB2 Control Center 之类的管理工具将使用这个参数与远程服务器联系
HADR_TIMEOUT	HADR 进程在认为一次通信尝试失败之前所等待的时间（以秒为单位）。默认值为 120 秒
HADR_SYNCMODE	指定同步模式。它决定当系统处于对等状态时，主日志写与备用数据库如何同步。有效值有 SYNC、NEARSYNC 和 ASYNC。默认值为 NEARSYNC。（本节后面将讨论对等状态）。
HADR_DB_ROLE	指定一个数据库当前的角色。有效值有 STANDARD、PRIMARY 和 STANDBY。STANDARD 意味着数据库没有启用 HADR。

当备用数据库第一次启动时，它进入 local catch-up 状态。本地日志路径中的日志文件（如果有的话）将被读取，并应用到备用数据库。

当到达本地日志文件的最后时，备用数据库进入 remote catch-up 状态。它重演主数据库的归档日志和活动日志，直到备用数据库应用了最近的活动日志。

当主系统上的所有日志文件都已经被重演时，主数据库和备用数据库就进入对等（peer）状态。

在同步模式中，日志写只有在以下情况下才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库的日志文件中。

主数据库与备用数据库中的日志记录几乎（或近似）是同步的，因为只有在以下情况下，日志写才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库上的主存中。

在这种模式下，主数据库不等待收到备用数据库的通知。只有在以下情况下，日志写才被认为是成功的：

日志记录已经被写到主数据库上的日志文件中。
日志记录已经被传送到备用数据库；不需要通知。

HADR 是通过以下三个简单的命令来管理的：

START HADR
STOP HADR
TAKENOVER HADR

这些命令的语法如下：

START HADR ON DATABASE database-alias
[USER userid] [USING password] 
AS PRIMARY | STANDBY [BY FORCE]

STOP HADR ON DATABASE database-alias 
[USER userid] [USING password] 

TAKEOVER HADR ON DATABASE database-alias
[USER userid] [USING password] 
[BY FORCE]

您已经学习了 HADR 的概念，现在可以学习如何设置 HADR 环境。

使用另一个数据库服务器 server2.torolab.ibm.com 作为备用服务器。TEST1 当前不在备用服务器上。

服务名	实例名	SVCENAME 或端口号	数据库名
server1.torolab.ibm.com	DB2INST1	50000	TEST1
server2.torolab.ibm.com	DB2INST1	50000	--

第一次初始化 HADR 时，执行图 13 所示的五个步骤：

确定主服务器和备用服务器。决定主机名、主机 IP 地址和每个 HADR 数据库的服务名或端口号。
您已经确定了主服务器和备用服务器。主服务器是 server1。备用服务器是 server2。

确保这两个服务器是通过 TCPIP 相互通信的。尝试用主机名在这两个服务器上相互 ping 对方。应确保输出没有错误。如果主机名不能使用，那么尝试使用它们的 TCPIP 地址。选用两者中最好用的一种用于 HADR 配置。

通过克隆主数据库创建备用数据库。

有两种方案可用于克隆主数据库：

一种方案是为主数据库做一个备份，并在备用数据库上恢复这个数据库备份。这种方案使用标准备份和恢复方法。
克隆主数据库的另一种方案是使用分割镜像。为主数据库做一个分割镜像，然后在备用服务器上初始化该分割镜像。当初始化分割镜像时，必须在 db2inidb 命令中使用 standby 选项，以便使用 mirror 和 snapshot 选项。

在这个例子种，使用备份/恢复方法来创建备用数据库。

首先为 server1 上的主数据库 TEST1 做一个备份：

BACKUP DB test1

接着，通过 ftp 将备份镜像传送到备用服务器，并恢复该备份镜像。

将备份镜像恢复到与主服务器上相同的位置。在主服务器上，发出 LIST DB DIRECTORY 命令将显示：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            =
 Alternate server port number         =

数据库位于主服务器上的 C: 盘上。当在备用服务器上恢复备份镜像时，也将它恢复到 C: 盘。在备用服务器 server2 上，发出以下命令来恢复 TEST1 数据库：

RESTORE DB test1 ON C:

在主数据库和备用数据库上设置以下 HADR 配置参数：

HADR_LOCAL_HOST
HADR_LOCAL_SVC
HADR_REMOTE_HOST
HADR_REMOTE_SVC
HADR_REMOTE_INST
HADR_SYNCMODE
LOGINDEXBUILD

在主服务器上，为 HADR 使用端口号 70000。更新 Windows\System32\drivers\etc\services 文件，在其中添加以下一行：

Hadr_port 	70000/tcp

在备用服务器上的 services 文件中添加以下一行：

Hadr_port 	80000/tcp

为 HADR_SYNCMODE 使用默认值，即 NEARSYNC。

您已经有了配置 HADR 参数所需的所有信息。发出以下命令来配置备用服务器上的参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在主数据库服务器上，配置相同的一组参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在备用数据库上使用 START HADR 命令启动 HADR：
START HADR ON DB test1 AS STANDBY
在启动主数据库之前启动备用数据库。如果先启动主数据库，那么，如果没有在 HADR_TIMEOUT 数据库配置参数指定的期限内启动备用数据库，那么主数据库的启动过程就会失败。
在主数据库上启动 HADR，如下面的例子所示：
START HADR ON DB test1 AS PRIMARY
HADR 现在已经在主数据库和备用数据库上启动了。

当第一次启动主服务器时，它等待备用服务器与它联系。如果在指定期限内备用服务器没有与主服务器联系，那么 HADR 将不启动。这个期限可以用 HADR_TIMEOUT 配置参数（见表 1）来配置。这样做的目的是避免两个系统在偶然的情况下与主服务器同时启动。

在 HADR 启动过程中，数据库经历以下状态：local catch-up、remote catch-up pending、remote catch-up 和对等状态。日志被自动从主服务器传送到备用服务器，然后在备用服务器上重演。这是为了确保备用数据库跟上主数据库的变化。

强烈建议在主数据库和备用数据库所在的系统上使用相同的数据库配置参数和数据库管理器配置参数。否则，备用数据库就不会像主数据库一样执行。

一个例外是 LOGFILSIZ 数据库配置参数。这个参数的值被备用服务器所忽略。备用服务器自动创建与主数据库上的日志文件大小相匹配的日志文件。这保证了两个数据库上的日志文件是一致的。

在主数据库与备用数据库之间切换数据库角色，也就是说，备用数据库变成主数据库，主数据库变成备用数据库。
从主数据库故障转移到备用数据库。

   GET SNAPSHOT FOR DATABASE ON test1

下面的命令在备用数据库 TEST1 上开始 HADR 数据库切换角色操作：

   TAKEOVER HADR ON DB test1

故障转移方案不切换数据库角色。在故障转移操作期间，备用数据库接管主数据库角色，但是主数据库不会变成备用数据库。

下面的命令在数据库 TEST1 上开始一个 HADR 故障转移操作：

   TAKEOVER HADR ON DB test1 BY FORCE

表 3 和 4 总结了在备用数据库上发出的 TAKEOVER HADR 命令的行为，以及备用数据库所处的对应的 HADR 状态：

备用数据库的状态	接管行为
对等	主数据库和备用数据库都切换角色
Local catch-up or remote catch-up	错误
Remote catch-up pending	错误

备用数据库的状态	接管行为
对等	备用数据库通知主数据库关闭。备用数据库停止接收来自主数据库的日志，完成它已经收到的日志的重演，然后变成主数据库。备用数据库不用等到主数据库发来通知确认它受到接管通知或者它已经关闭
Local catch-up OR remote catch-up	错误
Remote catch-up pending	备用数据库变成主数据库

您已经看到了如何设置 HADR 环境，以及如何使用数据库角色切换和故障转移方案执行接管。

您学习了如何使用 HADR 使数据库具有高可用性。如果主数据库停机，那么它的备用数据库将接管，并成为新的主数据库。

为了启用自动客户机重路由特性，在主数据库上发出 UPDATE ALTERNATE SERVER 命令。该命令的语法如下：

UPDATE ALTERNATE SERVER FOR DATABASE database-alias
USING HOSTNAME alternate-server-hostname PORT port-number

为了在 server1 上的 TEST1 数据库上启用客户机重路由特性，以便在接管之后已有的和新的客户机连接被重新路由到 server2，在 server1 上发出以下命令：

UPDATE ALTERNATE SERVER FOR DATABASE test1 USING 
HOSTNAME server2.torolab.ibm.com PORT 50000

在这个例子中，50000 是 SVCENAME 端口，而不是 HADR 端口。

备用服务器信息存储在 server1 的数据库目录中。如果发出一个 LIST DB DIRECTORY 命令，那么可以注意到备用服务器信息（主机名和端口号）已经被添加：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

现在让我们来看一个关于如何在启用了自动客户机重路由特性的数据库上执行接管的例子。

在这个例子中，不带 BY FORCE 选项执行一个接管。

首先，建立到 server1 上的 TEST1 数据库的一个远程客户机连接。为此，只需在一个远程 DB2 客户机上发出一条 CONNECT TO DATABASE 命令：

CONNECT TO DB test1 USER user1

为了建立那样的连接，客户机必须已经被配置为连接到 server1。关于如何配置远程客户机连接的信息，请参考本系列中的第一篇教程。

在建立连接之后，主服务器上的备用服务器信息被获取并存储在客户机的数据库目录中：

 Database alias                       = TEST1
 Database name                        = TEST1
 Node name                            = server1
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Remote
 Catalog database partition number    = -1
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

确保该连接已成功建立，并且可以查询 TEST1 数据库。在 server1 上发出一条 LIST APPLICATION 命令，它应该显示数据库 TEST1 上的远程客户机连接：

D:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      8          9.26.94.149.24336.060601000305
                                                         TEST1    1

接着，在 TEST1 数据库上执行接管。在备用服务器 server2 上发出以下命令：

TAKEOVER HADR ON DB test1

让我们看看这次接管完成后远程客户机连接有什么变化。

再次尝试从客户机查询 TEST1 数据库。对 TEST1 数据库的任何查询应该都会返回一个错误消息。例如，从客户机连接发出一条 LIST TABLES 命令：

D:\Programs\IBM\SQLLIB\BIN>db2 list tables
SQL30108N A connection failed but has been re-established. 
The hostname or IP address is "server2" and the service name or port number is "50000". 
Special registers may or may not be re-attempted (Reason code = "1").  
SQLSTATE=08506

这证明客户机重路由特性在起作用。现在您已经连接到新的主服务器，即 server2。

在 server2 上发出一条 LIST APPLICATIONS 命令。您可以看到，远程客户机连接已经被重新路由到那里：

H:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      55         9.26.94.149.29200.060601001803
                                                         TEST1    1

如果再次查询数据库，那么可以从新的主服务器得到一个响应。而且，到原来主服务器的新连接也被重新路由到新的主服务器。

使用 GET SNAPSHOT 命令可以获得数据库的 HADR 状态。在 server2 上发出以下命令，应该可以看到 server2 已经接管了主数据库角色：

db2 "get snapshot for database on test1"

  HADR Status
  Role                   = Primary
  State                  = Peer
  Synchronization mode   = Nearsync
  Connection status      = Connected , 05/31/2006 20:17:24.989618
  Heartbeats missed      = 0
  Local host             = server2.torolab.ibm.com
  Local service          = 80000
  Remote host            = server1.torolab.ibm.com
  Remote service         = 70000
  Remote instance        = db2inst1
  timeout(seconds)       = 120
  Primary log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Standby log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Log gap running average(bytes) = 0

在执行接管操作之后，如果出故障的数据库又可以使用，它不会自动恢复主数据库的角色。

通过以下步骤可以使之重新成为主数据库：

修复原来的主数据库所在的系统。这包括修复有问题的硬件或者重新启动崩溃的操作系统。
重新启动出故障的主数据库，使之成为一个备用数据库。
执行一个接管操作，使之接管主数据库的角色。

当原来的主数据库重新以备用数据库的角色加入 HADR 对之后，执行一个接管操作来切换数据库的角色，使原来的主数据库再次成为主数据库。

为了停止 TEST1 数据库上的 HADR，发出：

STOP HADR ON DB test1

您可以看到，HADR 是实现高可用性解决方案的一个强大的特性。提供了一个名为 HADR 向导的图形化用户界面工具，以帮助您设置和配置 HADR。

如果选择 Set Up，那么就会打开一个如图 15 所示的逐步向导。

如果使用 Control Center 设置 HADR 环境，则会自动启用自动客户机重路由特性。

阅读(23823) | 评论(0) | 转发(0) |

上一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（4）

下一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（6）

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

16024965号-6

高可用性灾难恢复（HADR）

DB2 高可用性灾难恢复（HADR）是一种数据库复制特性，它提供了一种高可用性解决方案。目前，HADR 只用于单分区数据库环境。

为了设置 HADR 环境，要更新一些数据库配置参数。

首先，必须启用主数据库上的归档日志记录。请参阅备份和恢复教程，以了解如何启用归档日志记录。

表 1 列出了与 HADR 相关的数据库配置参数的描述。本教程后面将给出一个关于如何更新这些参数的例子。

与 HADR 相关的数据库配置参数	描述
HADR_LOCAL_HOST	指定 HADR TCPIP 通信的本地主机。主机名和 IP 地址都可以使用
HADR_LOCAL_SVC	指定 TCPIP 服务名和端口号，HADR 进程将在本地主机上接受该服务或端口的连接。这个端口不能与 HADR 实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_HOST	指定远程 HADR 节点的 TCPIP 主机名或 IP 地址
HADR_REMOTE_SVC	指定 TCPIP 服务名或端口号，HADR 进程将在远程节点上接受该服务或端口的连接。这个端口不能与远程实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_INST	指定远程服务器的实例名。DB2 Control Center 之类的管理工具将使用这个参数与远程服务器联系
HADR_TIMEOUT	HADR 进程在认为一次通信尝试失败之前所等待的时间（以秒为单位）。默认值为 120 秒
HADR_SYNCMODE	指定同步模式。它决定当系统处于对等状态时，主日志写与备用数据库如何同步。有效值有 SYNC、NEARSYNC 和 ASYNC。默认值为 NEARSYNC。（本节后面将讨论对等状态）。
HADR_DB_ROLE	指定一个数据库当前的角色。有效值有 STANDARD、PRIMARY 和 STANDBY。STANDARD 意味着数据库没有启用 HADR。

当备用数据库第一次启动时，它进入 local catch-up 状态。本地日志路径中的日志文件（如果有的话）将被读取，并应用到备用数据库。

当到达本地日志文件的最后时，备用数据库进入 remote catch-up 状态。它重演主数据库的归档日志和活动日志，直到备用数据库应用了最近的活动日志。

当主系统上的所有日志文件都已经被重演时，主数据库和备用数据库就进入对等（peer）状态。

在同步模式中，日志写只有在以下情况下才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库的日志文件中。

主数据库与备用数据库中的日志记录几乎（或近似）是同步的，因为只有在以下情况下，日志写才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库上的主存中。

在这种模式下，主数据库不等待收到备用数据库的通知。只有在以下情况下，日志写才被认为是成功的：

日志记录已经被写到主数据库上的日志文件中。
日志记录已经被传送到备用数据库；不需要通知。

HADR 是通过以下三个简单的命令来管理的：

START HADR
STOP HADR
TAKENOVER HADR

这些命令的语法如下：

START HADR ON DATABASE database-alias
[USER userid] [USING password] 
AS PRIMARY | STANDBY [BY FORCE]

STOP HADR ON DATABASE database-alias 
[USER userid] [USING password] 

TAKEOVER HADR ON DATABASE database-alias
[USER userid] [USING password] 
[BY FORCE]

您已经学习了 HADR 的概念，现在可以学习如何设置 HADR 环境。

使用另一个数据库服务器 server2.torolab.ibm.com 作为备用服务器。TEST1 当前不在备用服务器上。

服务名	实例名	SVCENAME 或端口号	数据库名
server1.torolab.ibm.com	DB2INST1	50000	TEST1
server2.torolab.ibm.com	DB2INST1	50000	--

第一次初始化 HADR 时，执行图 13 所示的五个步骤：

确定主服务器和备用服务器。决定主机名、主机 IP 地址和每个 HADR 数据库的服务名或端口号。
您已经确定了主服务器和备用服务器。主服务器是 server1。备用服务器是 server2。

确保这两个服务器是通过 TCPIP 相互通信的。尝试用主机名在这两个服务器上相互 ping 对方。应确保输出没有错误。如果主机名不能使用，那么尝试使用它们的 TCPIP 地址。选用两者中最好用的一种用于 HADR 配置。

通过克隆主数据库创建备用数据库。

有两种方案可用于克隆主数据库：

一种方案是为主数据库做一个备份，并在备用数据库上恢复这个数据库备份。这种方案使用标准备份和恢复方法。
克隆主数据库的另一种方案是使用分割镜像。为主数据库做一个分割镜像，然后在备用服务器上初始化该分割镜像。当初始化分割镜像时，必须在 db2inidb 命令中使用 standby 选项，以便使用 mirror 和 snapshot 选项。

在这个例子种，使用备份/恢复方法来创建备用数据库。

首先为 server1 上的主数据库 TEST1 做一个备份：

BACKUP DB test1

接着，通过 ftp 将备份镜像传送到备用服务器，并恢复该备份镜像。

将备份镜像恢复到与主服务器上相同的位置。在主服务器上，发出 LIST DB DIRECTORY 命令将显示：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            =
 Alternate server port number         =

数据库位于主服务器上的 C: 盘上。当在备用服务器上恢复备份镜像时，也将它恢复到 C: 盘。在备用服务器 server2 上，发出以下命令来恢复 TEST1 数据库：

RESTORE DB test1 ON C:

在主数据库和备用数据库上设置以下 HADR 配置参数：

HADR_LOCAL_HOST
HADR_LOCAL_SVC
HADR_REMOTE_HOST
HADR_REMOTE_SVC
HADR_REMOTE_INST
HADR_SYNCMODE
LOGINDEXBUILD

在主服务器上，为 HADR 使用端口号 70000。更新 Windows\System32\drivers\etc\services 文件，在其中添加以下一行：

Hadr_port 	70000/tcp

在备用服务器上的 services 文件中添加以下一行：

Hadr_port 	80000/tcp

为 HADR_SYNCMODE 使用默认值，即 NEARSYNC。

您已经有了配置 HADR 参数所需的所有信息。发出以下命令来配置备用服务器上的参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在主数据库服务器上，配置相同的一组参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在备用数据库上使用 START HADR 命令启动 HADR：
START HADR ON DB test1 AS STANDBY
在启动主数据库之前启动备用数据库。如果先启动主数据库，那么，如果没有在 HADR_TIMEOUT 数据库配置参数指定的期限内启动备用数据库，那么主数据库的启动过程就会失败。
在主数据库上启动 HADR，如下面的例子所示：
START HADR ON DB test1 AS PRIMARY
HADR 现在已经在主数据库和备用数据库上启动了。

当第一次启动主服务器时，它等待备用服务器与它联系。如果在指定期限内备用服务器没有与主服务器联系，那么 HADR 将不启动。这个期限可以用 HADR_TIMEOUT 配置参数（见表 1）来配置。这样做的目的是避免两个系统在偶然的情况下与主服务器同时启动。

在 HADR 启动过程中，数据库经历以下状态：local catch-up、remote catch-up pending、remote catch-up 和对等状态。日志被自动从主服务器传送到备用服务器，然后在备用服务器上重演。这是为了确保备用数据库跟上主数据库的变化。

强烈建议在主数据库和备用数据库所在的系统上使用相同的数据库配置参数和数据库管理器配置参数。否则，备用数据库就不会像主数据库一样执行。

一个例外是 LOGFILSIZ 数据库配置参数。这个参数的值被备用服务器所忽略。备用服务器自动创建与主数据库上的日志文件大小相匹配的日志文件。这保证了两个数据库上的日志文件是一致的。

在主数据库与备用数据库之间切换数据库角色，也就是说，备用数据库变成主数据库，主数据库变成备用数据库。
从主数据库故障转移到备用数据库。

   GET SNAPSHOT FOR DATABASE ON test1

下面的命令在备用数据库 TEST1 上开始 HADR 数据库切换角色操作：

   TAKEOVER HADR ON DB test1

故障转移方案不切换数据库角色。在故障转移操作期间，备用数据库接管主数据库角色，但是主数据库不会变成备用数据库。

下面的命令在数据库 TEST1 上开始一个 HADR 故障转移操作：

   TAKEOVER HADR ON DB test1 BY FORCE

表 3 和 4 总结了在备用数据库上发出的 TAKEOVER HADR 命令的行为，以及备用数据库所处的对应的 HADR 状态：

备用数据库的状态	接管行为
对等	主数据库和备用数据库都切换角色
Local catch-up or remote catch-up	错误
Remote catch-up pending	错误

备用数据库的状态	接管行为
对等	备用数据库通知主数据库关闭。备用数据库停止接收来自主数据库的日志，完成它已经收到的日志的重演，然后变成主数据库。备用数据库不用等到主数据库发来通知确认它受到接管通知或者它已经关闭
Local catch-up OR remote catch-up	错误
Remote catch-up pending	备用数据库变成主数据库

您已经看到了如何设置 HADR 环境，以及如何使用数据库角色切换和故障转移方案执行接管。

您学习了如何使用 HADR 使数据库具有高可用性。如果主数据库停机，那么它的备用数据库将接管，并成为新的主数据库。

为了启用自动客户机重路由特性，在主数据库上发出 UPDATE ALTERNATE SERVER 命令。该命令的语法如下：

UPDATE ALTERNATE SERVER FOR DATABASE database-alias
USING HOSTNAME alternate-server-hostname PORT port-number

为了在 server1 上的 TEST1 数据库上启用客户机重路由特性，以便在接管之后已有的和新的客户机连接被重新路由到 server2，在 server1 上发出以下命令：

UPDATE ALTERNATE SERVER FOR DATABASE test1 USING 
HOSTNAME server2.torolab.ibm.com PORT 50000

在这个例子中，50000 是 SVCENAME 端口，而不是 HADR 端口。

备用服务器信息存储在 server1 的数据库目录中。如果发出一个 LIST DB DIRECTORY 命令，那么可以注意到备用服务器信息（主机名和端口号）已经被添加：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

现在让我们来看一个关于如何在启用了自动客户机重路由特性的数据库上执行接管的例子。

在这个例子中，不带 BY FORCE 选项执行一个接管。

首先，建立到 server1 上的 TEST1 数据库的一个远程客户机连接。为此，只需在一个远程 DB2 客户机上发出一条 CONNECT TO DATABASE 命令：

CONNECT TO DB test1 USER user1

为了建立那样的连接，客户机必须已经被配置为连接到 server1。关于如何配置远程客户机连接的信息，请参考本系列中的第一篇教程。

在建立连接之后，主服务器上的备用服务器信息被获取并存储在客户机的数据库目录中：

 Database alias                       = TEST1
 Database name                        = TEST1
 Node name                            = server1
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Remote
 Catalog database partition number    = -1
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

确保该连接已成功建立，并且可以查询 TEST1 数据库。在 server1 上发出一条 LIST APPLICATION 命令，它应该显示数据库 TEST1 上的远程客户机连接：

D:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      8          9.26.94.149.24336.060601000305
                                                         TEST1    1

接着，在 TEST1 数据库上执行接管。在备用服务器 server2 上发出以下命令：

TAKEOVER HADR ON DB test1

让我们看看这次接管完成后远程客户机连接有什么变化。

再次尝试从客户机查询 TEST1 数据库。对 TEST1 数据库的任何查询应该都会返回一个错误消息。例如，从客户机连接发出一条 LIST TABLES 命令：

D:\Programs\IBM\SQLLIB\BIN>db2 list tables
SQL30108N A connection failed but has been re-established. 
The hostname or IP address is "server2" and the service name or port number is "50000". 
Special registers may or may not be re-attempted (Reason code = "1").  
SQLSTATE=08506

这证明客户机重路由特性在起作用。现在您已经连接到新的主服务器，即 server2。

在 server2 上发出一条 LIST APPLICATIONS 命令。您可以看到，远程客户机连接已经被重新路由到那里：

H:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      55         9.26.94.149.29200.060601001803
                                                         TEST1    1

如果再次查询数据库，那么可以从新的主服务器得到一个响应。而且，到原来主服务器的新连接也被重新路由到新的主服务器。

使用 GET SNAPSHOT 命令可以获得数据库的 HADR 状态。在 server2 上发出以下命令，应该可以看到 server2 已经接管了主数据库角色：

db2 "get snapshot for database on test1"

  HADR Status
  Role                   = Primary
  State                  = Peer
  Synchronization mode   = Nearsync
  Connection status      = Connected , 05/31/2006 20:17:24.989618
  Heartbeats missed      = 0
  Local host             = server2.torolab.ibm.com
  Local service          = 80000
  Remote host            = server1.torolab.ibm.com
  Remote service         = 70000
  Remote instance        = db2inst1
  timeout(seconds)       = 120
  Primary log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Standby log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Log gap running average(bytes) = 0

在执行接管操作之后，如果出故障的数据库又可以使用，它不会自动恢复主数据库的角色。

通过以下步骤可以使之重新成为主数据库：

修复原来的主数据库所在的系统。这包括修复有问题的硬件或者重新启动崩溃的操作系统。
重新启动出故障的主数据库，使之成为一个备用数据库。
执行一个接管操作，使之接管主数据库的角色。

当原来的主数据库重新以备用数据库的角色加入 HADR 对之后，执行一个接管操作来切换数据库的角色，使原来的主数据库再次成为主数据库。

为了停止 TEST1 数据库上的 HADR，发出：

STOP HADR ON DB test1

您可以看到，HADR 是实现高可用性解决方案的一个强大的特性。提供了一个名为 HADR 向导的图形化用户界面工具，以帮助您设置和配置 HADR。

如果选择 Set Up，那么就会打开一个如图 15 所示的逐步向导。

如果使用 Control Center 设置 HADR 环境，则会自动启用自动客户机重路由特性。

阅读(23822) | 评论(0) | 转发(0) |

上一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（4）

下一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（6）

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

16024965号-6

高可用性灾难恢复（HADR）

DB2 高可用性灾难恢复（HADR）是一种数据库复制特性，它提供了一种高可用性解决方案。目前，HADR 只用于单分区数据库环境。

为了设置 HADR 环境，要更新一些数据库配置参数。

首先，必须启用主数据库上的归档日志记录。请参阅备份和恢复教程，以了解如何启用归档日志记录。

表 1 列出了与 HADR 相关的数据库配置参数的描述。本教程后面将给出一个关于如何更新这些参数的例子。

与 HADR 相关的数据库配置参数	描述
HADR_LOCAL_HOST	指定 HADR TCPIP 通信的本地主机。主机名和 IP 地址都可以使用
HADR_LOCAL_SVC	指定 TCPIP 服务名和端口号，HADR 进程将在本地主机上接受该服务或端口的连接。这个端口不能与 HADR 实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_HOST	指定远程 HADR 节点的 TCPIP 主机名或 IP 地址
HADR_REMOTE_SVC	指定 TCPIP 服务名或端口号，HADR 进程将在远程节点上接受该服务或端口的连接。这个端口不能与远程实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_INST	指定远程服务器的实例名。DB2 Control Center 之类的管理工具将使用这个参数与远程服务器联系
HADR_TIMEOUT	HADR 进程在认为一次通信尝试失败之前所等待的时间（以秒为单位）。默认值为 120 秒
HADR_SYNCMODE	指定同步模式。它决定当系统处于对等状态时，主日志写与备用数据库如何同步。有效值有 SYNC、NEARSYNC 和 ASYNC。默认值为 NEARSYNC。（本节后面将讨论对等状态）。
HADR_DB_ROLE	指定一个数据库当前的角色。有效值有 STANDARD、PRIMARY 和 STANDBY。STANDARD 意味着数据库没有启用 HADR。

当备用数据库第一次启动时，它进入 local catch-up 状态。本地日志路径中的日志文件（如果有的话）将被读取，并应用到备用数据库。

当到达本地日志文件的最后时，备用数据库进入 remote catch-up 状态。它重演主数据库的归档日志和活动日志，直到备用数据库应用了最近的活动日志。

当主系统上的所有日志文件都已经被重演时，主数据库和备用数据库就进入对等（peer）状态。

在同步模式中，日志写只有在以下情况下才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库的日志文件中。

主数据库与备用数据库中的日志记录几乎（或近似）是同步的，因为只有在以下情况下，日志写才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库上的主存中。

在这种模式下，主数据库不等待收到备用数据库的通知。只有在以下情况下，日志写才被认为是成功的：

日志记录已经被写到主数据库上的日志文件中。
日志记录已经被传送到备用数据库；不需要通知。

HADR 是通过以下三个简单的命令来管理的：

START HADR
STOP HADR
TAKENOVER HADR

这些命令的语法如下：

START HADR ON DATABASE database-alias
[USER userid] [USING password] 
AS PRIMARY | STANDBY [BY FORCE]

STOP HADR ON DATABASE database-alias 
[USER userid] [USING password] 

TAKEOVER HADR ON DATABASE database-alias
[USER userid] [USING password] 
[BY FORCE]

您已经学习了 HADR 的概念，现在可以学习如何设置 HADR 环境。

使用另一个数据库服务器 server2.torolab.ibm.com 作为备用服务器。TEST1 当前不在备用服务器上。

服务名	实例名	SVCENAME 或端口号	数据库名
server1.torolab.ibm.com	DB2INST1	50000	TEST1
server2.torolab.ibm.com	DB2INST1	50000	--

第一次初始化 HADR 时，执行图 13 所示的五个步骤：

确定主服务器和备用服务器。决定主机名、主机 IP 地址和每个 HADR 数据库的服务名或端口号。
您已经确定了主服务器和备用服务器。主服务器是 server1。备用服务器是 server2。

确保这两个服务器是通过 TCPIP 相互通信的。尝试用主机名在这两个服务器上相互 ping 对方。应确保输出没有错误。如果主机名不能使用，那么尝试使用它们的 TCPIP 地址。选用两者中最好用的一种用于 HADR 配置。

通过克隆主数据库创建备用数据库。

有两种方案可用于克隆主数据库：

一种方案是为主数据库做一个备份，并在备用数据库上恢复这个数据库备份。这种方案使用标准备份和恢复方法。
克隆主数据库的另一种方案是使用分割镜像。为主数据库做一个分割镜像，然后在备用服务器上初始化该分割镜像。当初始化分割镜像时，必须在 db2inidb 命令中使用 standby 选项，以便使用 mirror 和 snapshot 选项。

在这个例子种，使用备份/恢复方法来创建备用数据库。

首先为 server1 上的主数据库 TEST1 做一个备份：

BACKUP DB test1

接着，通过 ftp 将备份镜像传送到备用服务器，并恢复该备份镜像。

将备份镜像恢复到与主服务器上相同的位置。在主服务器上，发出 LIST DB DIRECTORY 命令将显示：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            =
 Alternate server port number         =

数据库位于主服务器上的 C: 盘上。当在备用服务器上恢复备份镜像时，也将它恢复到 C: 盘。在备用服务器 server2 上，发出以下命令来恢复 TEST1 数据库：

RESTORE DB test1 ON C:

在主数据库和备用数据库上设置以下 HADR 配置参数：

HADR_LOCAL_HOST
HADR_LOCAL_SVC
HADR_REMOTE_HOST
HADR_REMOTE_SVC
HADR_REMOTE_INST
HADR_SYNCMODE
LOGINDEXBUILD

在主服务器上，为 HADR 使用端口号 70000。更新 Windows\System32\drivers\etc\services 文件，在其中添加以下一行：

Hadr_port 	70000/tcp

在备用服务器上的 services 文件中添加以下一行：

Hadr_port 	80000/tcp

为 HADR_SYNCMODE 使用默认值，即 NEARSYNC。

您已经有了配置 HADR 参数所需的所有信息。发出以下命令来配置备用服务器上的参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在主数据库服务器上，配置相同的一组参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在备用数据库上使用 START HADR 命令启动 HADR：
START HADR ON DB test1 AS STANDBY
在启动主数据库之前启动备用数据库。如果先启动主数据库，那么，如果没有在 HADR_TIMEOUT 数据库配置参数指定的期限内启动备用数据库，那么主数据库的启动过程就会失败。
在主数据库上启动 HADR，如下面的例子所示：
START HADR ON DB test1 AS PRIMARY
HADR 现在已经在主数据库和备用数据库上启动了。

当第一次启动主服务器时，它等待备用服务器与它联系。如果在指定期限内备用服务器没有与主服务器联系，那么 HADR 将不启动。这个期限可以用 HADR_TIMEOUT 配置参数（见表 1）来配置。这样做的目的是避免两个系统在偶然的情况下与主服务器同时启动。

在 HADR 启动过程中，数据库经历以下状态：local catch-up、remote catch-up pending、remote catch-up 和对等状态。日志被自动从主服务器传送到备用服务器，然后在备用服务器上重演。这是为了确保备用数据库跟上主数据库的变化。

强烈建议在主数据库和备用数据库所在的系统上使用相同的数据库配置参数和数据库管理器配置参数。否则，备用数据库就不会像主数据库一样执行。

一个例外是 LOGFILSIZ 数据库配置参数。这个参数的值被备用服务器所忽略。备用服务器自动创建与主数据库上的日志文件大小相匹配的日志文件。这保证了两个数据库上的日志文件是一致的。

在主数据库与备用数据库之间切换数据库角色，也就是说，备用数据库变成主数据库，主数据库变成备用数据库。
从主数据库故障转移到备用数据库。

   GET SNAPSHOT FOR DATABASE ON test1

下面的命令在备用数据库 TEST1 上开始 HADR 数据库切换角色操作：

   TAKEOVER HADR ON DB test1

故障转移方案不切换数据库角色。在故障转移操作期间，备用数据库接管主数据库角色，但是主数据库不会变成备用数据库。

下面的命令在数据库 TEST1 上开始一个 HADR 故障转移操作：

   TAKEOVER HADR ON DB test1 BY FORCE

表 3 和 4 总结了在备用数据库上发出的 TAKEOVER HADR 命令的行为，以及备用数据库所处的对应的 HADR 状态：

备用数据库的状态	接管行为
对等	主数据库和备用数据库都切换角色
Local catch-up or remote catch-up	错误
Remote catch-up pending	错误

备用数据库的状态	接管行为
对等	备用数据库通知主数据库关闭。备用数据库停止接收来自主数据库的日志，完成它已经收到的日志的重演，然后变成主数据库。备用数据库不用等到主数据库发来通知确认它受到接管通知或者它已经关闭
Local catch-up OR remote catch-up	错误
Remote catch-up pending	备用数据库变成主数据库

您已经看到了如何设置 HADR 环境，以及如何使用数据库角色切换和故障转移方案执行接管。

您学习了如何使用 HADR 使数据库具有高可用性。如果主数据库停机，那么它的备用数据库将接管，并成为新的主数据库。

为了启用自动客户机重路由特性，在主数据库上发出 UPDATE ALTERNATE SERVER 命令。该命令的语法如下：

UPDATE ALTERNATE SERVER FOR DATABASE database-alias
USING HOSTNAME alternate-server-hostname PORT port-number

为了在 server1 上的 TEST1 数据库上启用客户机重路由特性，以便在接管之后已有的和新的客户机连接被重新路由到 server2，在 server1 上发出以下命令：

UPDATE ALTERNATE SERVER FOR DATABASE test1 USING 
HOSTNAME server2.torolab.ibm.com PORT 50000

在这个例子中，50000 是 SVCENAME 端口，而不是 HADR 端口。

备用服务器信息存储在 server1 的数据库目录中。如果发出一个 LIST DB DIRECTORY 命令，那么可以注意到备用服务器信息（主机名和端口号）已经被添加：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

现在让我们来看一个关于如何在启用了自动客户机重路由特性的数据库上执行接管的例子。

在这个例子中，不带 BY FORCE 选项执行一个接管。

首先，建立到 server1 上的 TEST1 数据库的一个远程客户机连接。为此，只需在一个远程 DB2 客户机上发出一条 CONNECT TO DATABASE 命令：

CONNECT TO DB test1 USER user1

为了建立那样的连接，客户机必须已经被配置为连接到 server1。关于如何配置远程客户机连接的信息，请参考本系列中的第一篇教程。

在建立连接之后，主服务器上的备用服务器信息被获取并存储在客户机的数据库目录中：

 Database alias                       = TEST1
 Database name                        = TEST1
 Node name                            = server1
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Remote
 Catalog database partition number    = -1
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

确保该连接已成功建立，并且可以查询 TEST1 数据库。在 server1 上发出一条 LIST APPLICATION 命令，它应该显示数据库 TEST1 上的远程客户机连接：

D:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      8          9.26.94.149.24336.060601000305
                                                         TEST1    1

接着，在 TEST1 数据库上执行接管。在备用服务器 server2 上发出以下命令：

TAKEOVER HADR ON DB test1

让我们看看这次接管完成后远程客户机连接有什么变化。

再次尝试从客户机查询 TEST1 数据库。对 TEST1 数据库的任何查询应该都会返回一个错误消息。例如，从客户机连接发出一条 LIST TABLES 命令：

D:\Programs\IBM\SQLLIB\BIN>db2 list tables
SQL30108N A connection failed but has been re-established. 
The hostname or IP address is "server2" and the service name or port number is "50000". 
Special registers may or may not be re-attempted (Reason code = "1").  
SQLSTATE=08506

这证明客户机重路由特性在起作用。现在您已经连接到新的主服务器，即 server2。

在 server2 上发出一条 LIST APPLICATIONS 命令。您可以看到，远程客户机连接已经被重新路由到那里：

H:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      55         9.26.94.149.29200.060601001803
                                                         TEST1    1

如果再次查询数据库，那么可以从新的主服务器得到一个响应。而且，到原来主服务器的新连接也被重新路由到新的主服务器。

使用 GET SNAPSHOT 命令可以获得数据库的 HADR 状态。在 server2 上发出以下命令，应该可以看到 server2 已经接管了主数据库角色：

db2 "get snapshot for database on test1"

  HADR Status
  Role                   = Primary
  State                  = Peer
  Synchronization mode   = Nearsync
  Connection status      = Connected , 05/31/2006 20:17:24.989618
  Heartbeats missed      = 0
  Local host             = server2.torolab.ibm.com
  Local service          = 80000
  Remote host            = server1.torolab.ibm.com
  Remote service         = 70000
  Remote instance        = db2inst1
  timeout(seconds)       = 120
  Primary log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Standby log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Log gap running average(bytes) = 0

在执行接管操作之后，如果出故障的数据库又可以使用，它不会自动恢复主数据库的角色。

通过以下步骤可以使之重新成为主数据库：

修复原来的主数据库所在的系统。这包括修复有问题的硬件或者重新启动崩溃的操作系统。
重新启动出故障的主数据库，使之成为一个备用数据库。
执行一个接管操作，使之接管主数据库的角色。

当原来的主数据库重新以备用数据库的角色加入 HADR 对之后，执行一个接管操作来切换数据库的角色，使原来的主数据库再次成为主数据库。

为了停止 TEST1 数据库上的 HADR，发出：

STOP HADR ON DB test1

您可以看到，HADR 是实现高可用性解决方案的一个强大的特性。提供了一个名为 HADR 向导的图形化用户界面工具，以帮助您设置和配置 HADR。

如果选择 Set Up，那么就会打开一个如图 15 所示的逐步向导。

如果使用 Control Center 设置 HADR 环境，则会自动启用自动客户机重路由特性。

阅读(23821) | 评论(0) | 转发(0) |

上一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（4）

下一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（6）

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

16024965号-6

高可用性灾难恢复（HADR）

DB2 高可用性灾难恢复（HADR）是一种数据库复制特性，它提供了一种高可用性解决方案。目前，HADR 只用于单分区数据库环境。

为了设置 HADR 环境，要更新一些数据库配置参数。

首先，必须启用主数据库上的归档日志记录。请参阅备份和恢复教程，以了解如何启用归档日志记录。

表 1 列出了与 HADR 相关的数据库配置参数的描述。本教程后面将给出一个关于如何更新这些参数的例子。

与 HADR 相关的数据库配置参数	描述
HADR_LOCAL_HOST	指定 HADR TCPIP 通信的本地主机。主机名和 IP 地址都可以使用
HADR_LOCAL_SVC	指定 TCPIP 服务名和端口号，HADR 进程将在本地主机上接受该服务或端口的连接。这个端口不能与 HADR 实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_HOST	指定远程 HADR 节点的 TCPIP 主机名或 IP 地址
HADR_REMOTE_SVC	指定 TCPIP 服务名或端口号，HADR 进程将在远程节点上接受该服务或端口的连接。这个端口不能与远程实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_INST	指定远程服务器的实例名。DB2 Control Center 之类的管理工具将使用这个参数与远程服务器联系
HADR_TIMEOUT	HADR 进程在认为一次通信尝试失败之前所等待的时间（以秒为单位）。默认值为 120 秒
HADR_SYNCMODE	指定同步模式。它决定当系统处于对等状态时，主日志写与备用数据库如何同步。有效值有 SYNC、NEARSYNC 和 ASYNC。默认值为 NEARSYNC。（本节后面将讨论对等状态）。
HADR_DB_ROLE	指定一个数据库当前的角色。有效值有 STANDARD、PRIMARY 和 STANDBY。STANDARD 意味着数据库没有启用 HADR。

当备用数据库第一次启动时，它进入 local catch-up 状态。本地日志路径中的日志文件（如果有的话）将被读取，并应用到备用数据库。

当到达本地日志文件的最后时，备用数据库进入 remote catch-up 状态。它重演主数据库的归档日志和活动日志，直到备用数据库应用了最近的活动日志。

当主系统上的所有日志文件都已经被重演时，主数据库和备用数据库就进入对等（peer）状态。

在同步模式中，日志写只有在以下情况下才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库的日志文件中。

主数据库与备用数据库中的日志记录几乎（或近似）是同步的，因为只有在以下情况下，日志写才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库上的主存中。

在这种模式下，主数据库不等待收到备用数据库的通知。只有在以下情况下，日志写才被认为是成功的：

日志记录已经被写到主数据库上的日志文件中。
日志记录已经被传送到备用数据库；不需要通知。

HADR 是通过以下三个简单的命令来管理的：

START HADR
STOP HADR
TAKENOVER HADR

这些命令的语法如下：

START HADR ON DATABASE database-alias
[USER userid] [USING password] 
AS PRIMARY | STANDBY [BY FORCE]

STOP HADR ON DATABASE database-alias 
[USER userid] [USING password] 

TAKEOVER HADR ON DATABASE database-alias
[USER userid] [USING password] 
[BY FORCE]

您已经学习了 HADR 的概念，现在可以学习如何设置 HADR 环境。

使用另一个数据库服务器 server2.torolab.ibm.com 作为备用服务器。TEST1 当前不在备用服务器上。

服务名	实例名	SVCENAME 或端口号	数据库名
server1.torolab.ibm.com	DB2INST1	50000	TEST1
server2.torolab.ibm.com	DB2INST1	50000	--

第一次初始化 HADR 时，执行图 13 所示的五个步骤：

确定主服务器和备用服务器。决定主机名、主机 IP 地址和每个 HADR 数据库的服务名或端口号。
您已经确定了主服务器和备用服务器。主服务器是 server1。备用服务器是 server2。

确保这两个服务器是通过 TCPIP 相互通信的。尝试用主机名在这两个服务器上相互 ping 对方。应确保输出没有错误。如果主机名不能使用，那么尝试使用它们的 TCPIP 地址。选用两者中最好用的一种用于 HADR 配置。

通过克隆主数据库创建备用数据库。

有两种方案可用于克隆主数据库：

一种方案是为主数据库做一个备份，并在备用数据库上恢复这个数据库备份。这种方案使用标准备份和恢复方法。
克隆主数据库的另一种方案是使用分割镜像。为主数据库做一个分割镜像，然后在备用服务器上初始化该分割镜像。当初始化分割镜像时，必须在 db2inidb 命令中使用 standby 选项，以便使用 mirror 和 snapshot 选项。

在这个例子种，使用备份/恢复方法来创建备用数据库。

首先为 server1 上的主数据库 TEST1 做一个备份：

BACKUP DB test1

接着，通过 ftp 将备份镜像传送到备用服务器，并恢复该备份镜像。

将备份镜像恢复到与主服务器上相同的位置。在主服务器上，发出 LIST DB DIRECTORY 命令将显示：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            =
 Alternate server port number         =

数据库位于主服务器上的 C: 盘上。当在备用服务器上恢复备份镜像时，也将它恢复到 C: 盘。在备用服务器 server2 上，发出以下命令来恢复 TEST1 数据库：

RESTORE DB test1 ON C:

在主数据库和备用数据库上设置以下 HADR 配置参数：

HADR_LOCAL_HOST
HADR_LOCAL_SVC
HADR_REMOTE_HOST
HADR_REMOTE_SVC
HADR_REMOTE_INST
HADR_SYNCMODE
LOGINDEXBUILD

在主服务器上，为 HADR 使用端口号 70000。更新 Windows\System32\drivers\etc\services 文件，在其中添加以下一行：

Hadr_port 	70000/tcp

在备用服务器上的 services 文件中添加以下一行：

Hadr_port 	80000/tcp

为 HADR_SYNCMODE 使用默认值，即 NEARSYNC。

您已经有了配置 HADR 参数所需的所有信息。发出以下命令来配置备用服务器上的参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在主数据库服务器上，配置相同的一组参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在备用数据库上使用 START HADR 命令启动 HADR：
START HADR ON DB test1 AS STANDBY
在启动主数据库之前启动备用数据库。如果先启动主数据库，那么，如果没有在 HADR_TIMEOUT 数据库配置参数指定的期限内启动备用数据库，那么主数据库的启动过程就会失败。
在主数据库上启动 HADR，如下面的例子所示：
START HADR ON DB test1 AS PRIMARY
HADR 现在已经在主数据库和备用数据库上启动了。

当第一次启动主服务器时，它等待备用服务器与它联系。如果在指定期限内备用服务器没有与主服务器联系，那么 HADR 将不启动。这个期限可以用 HADR_TIMEOUT 配置参数（见表 1）来配置。这样做的目的是避免两个系统在偶然的情况下与主服务器同时启动。

在 HADR 启动过程中，数据库经历以下状态：local catch-up、remote catch-up pending、remote catch-up 和对等状态。日志被自动从主服务器传送到备用服务器，然后在备用服务器上重演。这是为了确保备用数据库跟上主数据库的变化。

强烈建议在主数据库和备用数据库所在的系统上使用相同的数据库配置参数和数据库管理器配置参数。否则，备用数据库就不会像主数据库一样执行。

一个例外是 LOGFILSIZ 数据库配置参数。这个参数的值被备用服务器所忽略。备用服务器自动创建与主数据库上的日志文件大小相匹配的日志文件。这保证了两个数据库上的日志文件是一致的。

在主数据库与备用数据库之间切换数据库角色，也就是说，备用数据库变成主数据库，主数据库变成备用数据库。
从主数据库故障转移到备用数据库。

   GET SNAPSHOT FOR DATABASE ON test1

下面的命令在备用数据库 TEST1 上开始 HADR 数据库切换角色操作：

   TAKEOVER HADR ON DB test1

故障转移方案不切换数据库角色。在故障转移操作期间，备用数据库接管主数据库角色，但是主数据库不会变成备用数据库。

下面的命令在数据库 TEST1 上开始一个 HADR 故障转移操作：

   TAKEOVER HADR ON DB test1 BY FORCE

表 3 和 4 总结了在备用数据库上发出的 TAKEOVER HADR 命令的行为，以及备用数据库所处的对应的 HADR 状态：

备用数据库的状态	接管行为
对等	主数据库和备用数据库都切换角色
Local catch-up or remote catch-up	错误
Remote catch-up pending	错误

备用数据库的状态	接管行为
对等	备用数据库通知主数据库关闭。备用数据库停止接收来自主数据库的日志，完成它已经收到的日志的重演，然后变成主数据库。备用数据库不用等到主数据库发来通知确认它受到接管通知或者它已经关闭
Local catch-up OR remote catch-up	错误
Remote catch-up pending	备用数据库变成主数据库

您已经看到了如何设置 HADR 环境，以及如何使用数据库角色切换和故障转移方案执行接管。

您学习了如何使用 HADR 使数据库具有高可用性。如果主数据库停机，那么它的备用数据库将接管，并成为新的主数据库。

为了启用自动客户机重路由特性，在主数据库上发出 UPDATE ALTERNATE SERVER 命令。该命令的语法如下：

UPDATE ALTERNATE SERVER FOR DATABASE database-alias
USING HOSTNAME alternate-server-hostname PORT port-number

为了在 server1 上的 TEST1 数据库上启用客户机重路由特性，以便在接管之后已有的和新的客户机连接被重新路由到 server2，在 server1 上发出以下命令：

UPDATE ALTERNATE SERVER FOR DATABASE test1 USING 
HOSTNAME server2.torolab.ibm.com PORT 50000

在这个例子中，50000 是 SVCENAME 端口，而不是 HADR 端口。

备用服务器信息存储在 server1 的数据库目录中。如果发出一个 LIST DB DIRECTORY 命令，那么可以注意到备用服务器信息（主机名和端口号）已经被添加：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

现在让我们来看一个关于如何在启用了自动客户机重路由特性的数据库上执行接管的例子。

在这个例子中，不带 BY FORCE 选项执行一个接管。

首先，建立到 server1 上的 TEST1 数据库的一个远程客户机连接。为此，只需在一个远程 DB2 客户机上发出一条 CONNECT TO DATABASE 命令：

CONNECT TO DB test1 USER user1

为了建立那样的连接，客户机必须已经被配置为连接到 server1。关于如何配置远程客户机连接的信息，请参考本系列中的第一篇教程。

在建立连接之后，主服务器上的备用服务器信息被获取并存储在客户机的数据库目录中：

 Database alias                       = TEST1
 Database name                        = TEST1
 Node name                            = server1
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Remote
 Catalog database partition number    = -1
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

确保该连接已成功建立，并且可以查询 TEST1 数据库。在 server1 上发出一条 LIST APPLICATION 命令，它应该显示数据库 TEST1 上的远程客户机连接：

D:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      8          9.26.94.149.24336.060601000305
                                                         TEST1    1

接着，在 TEST1 数据库上执行接管。在备用服务器 server2 上发出以下命令：

TAKEOVER HADR ON DB test1

让我们看看这次接管完成后远程客户机连接有什么变化。

再次尝试从客户机查询 TEST1 数据库。对 TEST1 数据库的任何查询应该都会返回一个错误消息。例如，从客户机连接发出一条 LIST TABLES 命令：

D:\Programs\IBM\SQLLIB\BIN>db2 list tables
SQL30108N A connection failed but has been re-established. 
The hostname or IP address is "server2" and the service name or port number is "50000". 
Special registers may or may not be re-attempted (Reason code = "1").  
SQLSTATE=08506

这证明客户机重路由特性在起作用。现在您已经连接到新的主服务器，即 server2。

在 server2 上发出一条 LIST APPLICATIONS 命令。您可以看到，远程客户机连接已经被重新路由到那里：

H:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      55         9.26.94.149.29200.060601001803
                                                         TEST1    1

如果再次查询数据库，那么可以从新的主服务器得到一个响应。而且，到原来主服务器的新连接也被重新路由到新的主服务器。

使用 GET SNAPSHOT 命令可以获得数据库的 HADR 状态。在 server2 上发出以下命令，应该可以看到 server2 已经接管了主数据库角色：

db2 "get snapshot for database on test1"

  HADR Status
  Role                   = Primary
  State                  = Peer
  Synchronization mode   = Nearsync
  Connection status      = Connected , 05/31/2006 20:17:24.989618
  Heartbeats missed      = 0
  Local host             = server2.torolab.ibm.com
  Local service          = 80000
  Remote host            = server1.torolab.ibm.com
  Remote service         = 70000
  Remote instance        = db2inst1
  timeout(seconds)       = 120
  Primary log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Standby log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Log gap running average(bytes) = 0

在执行接管操作之后，如果出故障的数据库又可以使用，它不会自动恢复主数据库的角色。

通过以下步骤可以使之重新成为主数据库：

修复原来的主数据库所在的系统。这包括修复有问题的硬件或者重新启动崩溃的操作系统。
重新启动出故障的主数据库，使之成为一个备用数据库。
执行一个接管操作，使之接管主数据库的角色。

当原来的主数据库重新以备用数据库的角色加入 HADR 对之后，执行一个接管操作来切换数据库的角色，使原来的主数据库再次成为主数据库。

为了停止 TEST1 数据库上的 HADR，发出：

STOP HADR ON DB test1

您可以看到，HADR 是实现高可用性解决方案的一个强大的特性。提供了一个名为 HADR 向导的图形化用户界面工具，以帮助您设置和配置 HADR。

如果选择 Set Up，那么就会打开一个如图 15 所示的逐步向导。

如果使用 Control Center 设置 HADR 环境，则会自动启用自动客户机重路由特性。

阅读(23820) | 评论(0) | 转发(0) |

上一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（4）

下一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（6）

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

16024965号-6

高可用性灾难恢复（HADR）

DB2 高可用性灾难恢复（HADR）是一种数据库复制特性，它提供了一种高可用性解决方案。目前，HADR 只用于单分区数据库环境。

为了设置 HADR 环境，要更新一些数据库配置参数。

首先，必须启用主数据库上的归档日志记录。请参阅备份和恢复教程，以了解如何启用归档日志记录。

表 1 列出了与 HADR 相关的数据库配置参数的描述。本教程后面将给出一个关于如何更新这些参数的例子。

与 HADR 相关的数据库配置参数	描述
HADR_LOCAL_HOST	指定 HADR TCPIP 通信的本地主机。主机名和 IP 地址都可以使用
HADR_LOCAL_SVC	指定 TCPIP 服务名和端口号，HADR 进程将在本地主机上接受该服务或端口的连接。这个端口不能与 HADR 实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_HOST	指定远程 HADR 节点的 TCPIP 主机名或 IP 地址
HADR_REMOTE_SVC	指定 TCPIP 服务名或端口号，HADR 进程将在远程节点上接受该服务或端口的连接。这个端口不能与远程实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_INST	指定远程服务器的实例名。DB2 Control Center 之类的管理工具将使用这个参数与远程服务器联系
HADR_TIMEOUT	HADR 进程在认为一次通信尝试失败之前所等待的时间（以秒为单位）。默认值为 120 秒
HADR_SYNCMODE	指定同步模式。它决定当系统处于对等状态时，主日志写与备用数据库如何同步。有效值有 SYNC、NEARSYNC 和 ASYNC。默认值为 NEARSYNC。（本节后面将讨论对等状态）。
HADR_DB_ROLE	指定一个数据库当前的角色。有效值有 STANDARD、PRIMARY 和 STANDBY。STANDARD 意味着数据库没有启用 HADR。

当备用数据库第一次启动时，它进入 local catch-up 状态。本地日志路径中的日志文件（如果有的话）将被读取，并应用到备用数据库。

当到达本地日志文件的最后时，备用数据库进入 remote catch-up 状态。它重演主数据库的归档日志和活动日志，直到备用数据库应用了最近的活动日志。

当主系统上的所有日志文件都已经被重演时，主数据库和备用数据库就进入对等（peer）状态。

在同步模式中，日志写只有在以下情况下才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库的日志文件中。

主数据库与备用数据库中的日志记录几乎（或近似）是同步的，因为只有在以下情况下，日志写才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库上的主存中。

在这种模式下，主数据库不等待收到备用数据库的通知。只有在以下情况下，日志写才被认为是成功的：

日志记录已经被写到主数据库上的日志文件中。
日志记录已经被传送到备用数据库；不需要通知。

HADR 是通过以下三个简单的命令来管理的：

START HADR
STOP HADR
TAKENOVER HADR

这些命令的语法如下：

START HADR ON DATABASE database-alias
[USER userid] [USING password] 
AS PRIMARY | STANDBY [BY FORCE]

STOP HADR ON DATABASE database-alias 
[USER userid] [USING password] 

TAKEOVER HADR ON DATABASE database-alias
[USER userid] [USING password] 
[BY FORCE]

您已经学习了 HADR 的概念，现在可以学习如何设置 HADR 环境。

使用另一个数据库服务器 server2.torolab.ibm.com 作为备用服务器。TEST1 当前不在备用服务器上。

服务名	实例名	SVCENAME 或端口号	数据库名
server1.torolab.ibm.com	DB2INST1	50000	TEST1
server2.torolab.ibm.com	DB2INST1	50000	--

第一次初始化 HADR 时，执行图 13 所示的五个步骤：

确定主服务器和备用服务器。决定主机名、主机 IP 地址和每个 HADR 数据库的服务名或端口号。
您已经确定了主服务器和备用服务器。主服务器是 server1。备用服务器是 server2。

确保这两个服务器是通过 TCPIP 相互通信的。尝试用主机名在这两个服务器上相互 ping 对方。应确保输出没有错误。如果主机名不能使用，那么尝试使用它们的 TCPIP 地址。选用两者中最好用的一种用于 HADR 配置。

通过克隆主数据库创建备用数据库。

有两种方案可用于克隆主数据库：

一种方案是为主数据库做一个备份，并在备用数据库上恢复这个数据库备份。这种方案使用标准备份和恢复方法。
克隆主数据库的另一种方案是使用分割镜像。为主数据库做一个分割镜像，然后在备用服务器上初始化该分割镜像。当初始化分割镜像时，必须在 db2inidb 命令中使用 standby 选项，以便使用 mirror 和 snapshot 选项。

在这个例子种，使用备份/恢复方法来创建备用数据库。

首先为 server1 上的主数据库 TEST1 做一个备份：

BACKUP DB test1

接着，通过 ftp 将备份镜像传送到备用服务器，并恢复该备份镜像。

将备份镜像恢复到与主服务器上相同的位置。在主服务器上，发出 LIST DB DIRECTORY 命令将显示：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            =
 Alternate server port number         =

数据库位于主服务器上的 C: 盘上。当在备用服务器上恢复备份镜像时，也将它恢复到 C: 盘。在备用服务器 server2 上，发出以下命令来恢复 TEST1 数据库：

RESTORE DB test1 ON C:

在主数据库和备用数据库上设置以下 HADR 配置参数：

HADR_LOCAL_HOST
HADR_LOCAL_SVC
HADR_REMOTE_HOST
HADR_REMOTE_SVC
HADR_REMOTE_INST
HADR_SYNCMODE
LOGINDEXBUILD

在主服务器上，为 HADR 使用端口号 70000。更新 Windows\System32\drivers\etc\services 文件，在其中添加以下一行：

Hadr_port 	70000/tcp

在备用服务器上的 services 文件中添加以下一行：

Hadr_port 	80000/tcp

为 HADR_SYNCMODE 使用默认值，即 NEARSYNC。

您已经有了配置 HADR 参数所需的所有信息。发出以下命令来配置备用服务器上的参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在主数据库服务器上，配置相同的一组参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在备用数据库上使用 START HADR 命令启动 HADR：
START HADR ON DB test1 AS STANDBY
在启动主数据库之前启动备用数据库。如果先启动主数据库，那么，如果没有在 HADR_TIMEOUT 数据库配置参数指定的期限内启动备用数据库，那么主数据库的启动过程就会失败。
在主数据库上启动 HADR，如下面的例子所示：
START HADR ON DB test1 AS PRIMARY
HADR 现在已经在主数据库和备用数据库上启动了。

当第一次启动主服务器时，它等待备用服务器与它联系。如果在指定期限内备用服务器没有与主服务器联系，那么 HADR 将不启动。这个期限可以用 HADR_TIMEOUT 配置参数（见表 1）来配置。这样做的目的是避免两个系统在偶然的情况下与主服务器同时启动。

在 HADR 启动过程中，数据库经历以下状态：local catch-up、remote catch-up pending、remote catch-up 和对等状态。日志被自动从主服务器传送到备用服务器，然后在备用服务器上重演。这是为了确保备用数据库跟上主数据库的变化。

强烈建议在主数据库和备用数据库所在的系统上使用相同的数据库配置参数和数据库管理器配置参数。否则，备用数据库就不会像主数据库一样执行。

一个例外是 LOGFILSIZ 数据库配置参数。这个参数的值被备用服务器所忽略。备用服务器自动创建与主数据库上的日志文件大小相匹配的日志文件。这保证了两个数据库上的日志文件是一致的。

在主数据库与备用数据库之间切换数据库角色，也就是说，备用数据库变成主数据库，主数据库变成备用数据库。
从主数据库故障转移到备用数据库。

   GET SNAPSHOT FOR DATABASE ON test1

下面的命令在备用数据库 TEST1 上开始 HADR 数据库切换角色操作：

   TAKEOVER HADR ON DB test1

故障转移方案不切换数据库角色。在故障转移操作期间，备用数据库接管主数据库角色，但是主数据库不会变成备用数据库。

下面的命令在数据库 TEST1 上开始一个 HADR 故障转移操作：

   TAKEOVER HADR ON DB test1 BY FORCE

表 3 和 4 总结了在备用数据库上发出的 TAKEOVER HADR 命令的行为，以及备用数据库所处的对应的 HADR 状态：

备用数据库的状态	接管行为
对等	主数据库和备用数据库都切换角色
Local catch-up or remote catch-up	错误
Remote catch-up pending	错误

备用数据库的状态	接管行为
对等	备用数据库通知主数据库关闭。备用数据库停止接收来自主数据库的日志，完成它已经收到的日志的重演，然后变成主数据库。备用数据库不用等到主数据库发来通知确认它受到接管通知或者它已经关闭
Local catch-up OR remote catch-up	错误
Remote catch-up pending	备用数据库变成主数据库

您已经看到了如何设置 HADR 环境，以及如何使用数据库角色切换和故障转移方案执行接管。

您学习了如何使用 HADR 使数据库具有高可用性。如果主数据库停机，那么它的备用数据库将接管，并成为新的主数据库。

为了启用自动客户机重路由特性，在主数据库上发出 UPDATE ALTERNATE SERVER 命令。该命令的语法如下：

UPDATE ALTERNATE SERVER FOR DATABASE database-alias
USING HOSTNAME alternate-server-hostname PORT port-number

为了在 server1 上的 TEST1 数据库上启用客户机重路由特性，以便在接管之后已有的和新的客户机连接被重新路由到 server2，在 server1 上发出以下命令：

UPDATE ALTERNATE SERVER FOR DATABASE test1 USING 
HOSTNAME server2.torolab.ibm.com PORT 50000

在这个例子中，50000 是 SVCENAME 端口，而不是 HADR 端口。

备用服务器信息存储在 server1 的数据库目录中。如果发出一个 LIST DB DIRECTORY 命令，那么可以注意到备用服务器信息（主机名和端口号）已经被添加：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

现在让我们来看一个关于如何在启用了自动客户机重路由特性的数据库上执行接管的例子。

在这个例子中，不带 BY FORCE 选项执行一个接管。

首先，建立到 server1 上的 TEST1 数据库的一个远程客户机连接。为此，只需在一个远程 DB2 客户机上发出一条 CONNECT TO DATABASE 命令：

CONNECT TO DB test1 USER user1

为了建立那样的连接，客户机必须已经被配置为连接到 server1。关于如何配置远程客户机连接的信息，请参考本系列中的第一篇教程。

在建立连接之后，主服务器上的备用服务器信息被获取并存储在客户机的数据库目录中：

 Database alias                       = TEST1
 Database name                        = TEST1
 Node name                            = server1
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Remote
 Catalog database partition number    = -1
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

确保该连接已成功建立，并且可以查询 TEST1 数据库。在 server1 上发出一条 LIST APPLICATION 命令，它应该显示数据库 TEST1 上的远程客户机连接：

D:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      8          9.26.94.149.24336.060601000305
                                                         TEST1    1

接着，在 TEST1 数据库上执行接管。在备用服务器 server2 上发出以下命令：

TAKEOVER HADR ON DB test1

让我们看看这次接管完成后远程客户机连接有什么变化。

再次尝试从客户机查询 TEST1 数据库。对 TEST1 数据库的任何查询应该都会返回一个错误消息。例如，从客户机连接发出一条 LIST TABLES 命令：

D:\Programs\IBM\SQLLIB\BIN>db2 list tables
SQL30108N A connection failed but has been re-established. 
The hostname or IP address is "server2" and the service name or port number is "50000". 
Special registers may or may not be re-attempted (Reason code = "1").  
SQLSTATE=08506

这证明客户机重路由特性在起作用。现在您已经连接到新的主服务器，即 server2。

在 server2 上发出一条 LIST APPLICATIONS 命令。您可以看到，远程客户机连接已经被重新路由到那里：

H:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      55         9.26.94.149.29200.060601001803
                                                         TEST1    1

如果再次查询数据库，那么可以从新的主服务器得到一个响应。而且，到原来主服务器的新连接也被重新路由到新的主服务器。

使用 GET SNAPSHOT 命令可以获得数据库的 HADR 状态。在 server2 上发出以下命令，应该可以看到 server2 已经接管了主数据库角色：

db2 "get snapshot for database on test1"

  HADR Status
  Role                   = Primary
  State                  = Peer
  Synchronization mode   = Nearsync
  Connection status      = Connected , 05/31/2006 20:17:24.989618
  Heartbeats missed      = 0
  Local host             = server2.torolab.ibm.com
  Local service          = 80000
  Remote host            = server1.torolab.ibm.com
  Remote service         = 70000
  Remote instance        = db2inst1
  timeout(seconds)       = 120
  Primary log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Standby log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Log gap running average(bytes) = 0

在执行接管操作之后，如果出故障的数据库又可以使用，它不会自动恢复主数据库的角色。

通过以下步骤可以使之重新成为主数据库：

修复原来的主数据库所在的系统。这包括修复有问题的硬件或者重新启动崩溃的操作系统。
重新启动出故障的主数据库，使之成为一个备用数据库。
执行一个接管操作，使之接管主数据库的角色。

当原来的主数据库重新以备用数据库的角色加入 HADR 对之后，执行一个接管操作来切换数据库的角色，使原来的主数据库再次成为主数据库。

为了停止 TEST1 数据库上的 HADR，发出：

STOP HADR ON DB test1

您可以看到，HADR 是实现高可用性解决方案的一个强大的特性。提供了一个名为 HADR 向导的图形化用户界面工具，以帮助您设置和配置 HADR。

如果选择 Set Up，那么就会打开一个如图 15 所示的逐步向导。

如果使用 Control Center 设置 HADR 环境，则会自动启用自动客户机重路由特性。

阅读(23819) | 评论(0) | 转发(0) |

上一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（4）

下一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（6）

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

16024965号-6

高可用性灾难恢复（HADR）

DB2 高可用性灾难恢复（HADR）是一种数据库复制特性，它提供了一种高可用性解决方案。目前，HADR 只用于单分区数据库环境。

为了设置 HADR 环境，要更新一些数据库配置参数。

首先，必须启用主数据库上的归档日志记录。请参阅备份和恢复教程，以了解如何启用归档日志记录。

表 1 列出了与 HADR 相关的数据库配置参数的描述。本教程后面将给出一个关于如何更新这些参数的例子。

与 HADR 相关的数据库配置参数	描述
HADR_LOCAL_HOST	指定 HADR TCPIP 通信的本地主机。主机名和 IP 地址都可以使用
HADR_LOCAL_SVC	指定 TCPIP 服务名和端口号，HADR 进程将在本地主机上接受该服务或端口的连接。这个端口不能与 HADR 实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_HOST	指定远程 HADR 节点的 TCPIP 主机名或 IP 地址
HADR_REMOTE_SVC	指定 TCPIP 服务名或端口号，HADR 进程将在远程节点上接受该服务或端口的连接。这个端口不能与远程实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_INST	指定远程服务器的实例名。DB2 Control Center 之类的管理工具将使用这个参数与远程服务器联系
HADR_TIMEOUT	HADR 进程在认为一次通信尝试失败之前所等待的时间（以秒为单位）。默认值为 120 秒
HADR_SYNCMODE	指定同步模式。它决定当系统处于对等状态时，主日志写与备用数据库如何同步。有效值有 SYNC、NEARSYNC 和 ASYNC。默认值为 NEARSYNC。（本节后面将讨论对等状态）。
HADR_DB_ROLE	指定一个数据库当前的角色。有效值有 STANDARD、PRIMARY 和 STANDBY。STANDARD 意味着数据库没有启用 HADR。

当备用数据库第一次启动时，它进入 local catch-up 状态。本地日志路径中的日志文件（如果有的话）将被读取，并应用到备用数据库。

当到达本地日志文件的最后时，备用数据库进入 remote catch-up 状态。它重演主数据库的归档日志和活动日志，直到备用数据库应用了最近的活动日志。

当主系统上的所有日志文件都已经被重演时，主数据库和备用数据库就进入对等（peer）状态。

在同步模式中，日志写只有在以下情况下才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库的日志文件中。

主数据库与备用数据库中的日志记录几乎（或近似）是同步的，因为只有在以下情况下，日志写才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库上的主存中。

在这种模式下，主数据库不等待收到备用数据库的通知。只有在以下情况下，日志写才被认为是成功的：

日志记录已经被写到主数据库上的日志文件中。
日志记录已经被传送到备用数据库；不需要通知。

HADR 是通过以下三个简单的命令来管理的：

START HADR
STOP HADR
TAKENOVER HADR

这些命令的语法如下：

START HADR ON DATABASE database-alias
[USER userid] [USING password] 
AS PRIMARY | STANDBY [BY FORCE]

STOP HADR ON DATABASE database-alias 
[USER userid] [USING password] 

TAKEOVER HADR ON DATABASE database-alias
[USER userid] [USING password] 
[BY FORCE]

您已经学习了 HADR 的概念，现在可以学习如何设置 HADR 环境。

使用另一个数据库服务器 server2.torolab.ibm.com 作为备用服务器。TEST1 当前不在备用服务器上。

服务名	实例名	SVCENAME 或端口号	数据库名
server1.torolab.ibm.com	DB2INST1	50000	TEST1
server2.torolab.ibm.com	DB2INST1	50000	--

第一次初始化 HADR 时，执行图 13 所示的五个步骤：

确定主服务器和备用服务器。决定主机名、主机 IP 地址和每个 HADR 数据库的服务名或端口号。
您已经确定了主服务器和备用服务器。主服务器是 server1。备用服务器是 server2。

确保这两个服务器是通过 TCPIP 相互通信的。尝试用主机名在这两个服务器上相互 ping 对方。应确保输出没有错误。如果主机名不能使用，那么尝试使用它们的 TCPIP 地址。选用两者中最好用的一种用于 HADR 配置。

通过克隆主数据库创建备用数据库。

有两种方案可用于克隆主数据库：

一种方案是为主数据库做一个备份，并在备用数据库上恢复这个数据库备份。这种方案使用标准备份和恢复方法。
克隆主数据库的另一种方案是使用分割镜像。为主数据库做一个分割镜像，然后在备用服务器上初始化该分割镜像。当初始化分割镜像时，必须在 db2inidb 命令中使用 standby 选项，以便使用 mirror 和 snapshot 选项。

在这个例子种，使用备份/恢复方法来创建备用数据库。

首先为 server1 上的主数据库 TEST1 做一个备份：

BACKUP DB test1

接着，通过 ftp 将备份镜像传送到备用服务器，并恢复该备份镜像。

将备份镜像恢复到与主服务器上相同的位置。在主服务器上，发出 LIST DB DIRECTORY 命令将显示：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            =
 Alternate server port number         =

数据库位于主服务器上的 C: 盘上。当在备用服务器上恢复备份镜像时，也将它恢复到 C: 盘。在备用服务器 server2 上，发出以下命令来恢复 TEST1 数据库：

RESTORE DB test1 ON C:

在主数据库和备用数据库上设置以下 HADR 配置参数：

HADR_LOCAL_HOST
HADR_LOCAL_SVC
HADR_REMOTE_HOST
HADR_REMOTE_SVC
HADR_REMOTE_INST
HADR_SYNCMODE
LOGINDEXBUILD

在主服务器上，为 HADR 使用端口号 70000。更新 Windows\System32\drivers\etc\services 文件，在其中添加以下一行：

Hadr_port 	70000/tcp

在备用服务器上的 services 文件中添加以下一行：

Hadr_port 	80000/tcp

为 HADR_SYNCMODE 使用默认值，即 NEARSYNC。

您已经有了配置 HADR 参数所需的所有信息。发出以下命令来配置备用服务器上的参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在主数据库服务器上，配置相同的一组参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在备用数据库上使用 START HADR 命令启动 HADR：
START HADR ON DB test1 AS STANDBY
在启动主数据库之前启动备用数据库。如果先启动主数据库，那么，如果没有在 HADR_TIMEOUT 数据库配置参数指定的期限内启动备用数据库，那么主数据库的启动过程就会失败。
在主数据库上启动 HADR，如下面的例子所示：
START HADR ON DB test1 AS PRIMARY
HADR 现在已经在主数据库和备用数据库上启动了。

当第一次启动主服务器时，它等待备用服务器与它联系。如果在指定期限内备用服务器没有与主服务器联系，那么 HADR 将不启动。这个期限可以用 HADR_TIMEOUT 配置参数（见表 1）来配置。这样做的目的是避免两个系统在偶然的情况下与主服务器同时启动。

在 HADR 启动过程中，数据库经历以下状态：local catch-up、remote catch-up pending、remote catch-up 和对等状态。日志被自动从主服务器传送到备用服务器，然后在备用服务器上重演。这是为了确保备用数据库跟上主数据库的变化。

强烈建议在主数据库和备用数据库所在的系统上使用相同的数据库配置参数和数据库管理器配置参数。否则，备用数据库就不会像主数据库一样执行。

一个例外是 LOGFILSIZ 数据库配置参数。这个参数的值被备用服务器所忽略。备用服务器自动创建与主数据库上的日志文件大小相匹配的日志文件。这保证了两个数据库上的日志文件是一致的。

在主数据库与备用数据库之间切换数据库角色，也就是说，备用数据库变成主数据库，主数据库变成备用数据库。
从主数据库故障转移到备用数据库。

   GET SNAPSHOT FOR DATABASE ON test1

下面的命令在备用数据库 TEST1 上开始 HADR 数据库切换角色操作：

   TAKEOVER HADR ON DB test1

故障转移方案不切换数据库角色。在故障转移操作期间，备用数据库接管主数据库角色，但是主数据库不会变成备用数据库。

下面的命令在数据库 TEST1 上开始一个 HADR 故障转移操作：

   TAKEOVER HADR ON DB test1 BY FORCE

表 3 和 4 总结了在备用数据库上发出的 TAKEOVER HADR 命令的行为，以及备用数据库所处的对应的 HADR 状态：

备用数据库的状态	接管行为
对等	主数据库和备用数据库都切换角色
Local catch-up or remote catch-up	错误
Remote catch-up pending	错误

备用数据库的状态	接管行为
对等	备用数据库通知主数据库关闭。备用数据库停止接收来自主数据库的日志，完成它已经收到的日志的重演，然后变成主数据库。备用数据库不用等到主数据库发来通知确认它受到接管通知或者它已经关闭
Local catch-up OR remote catch-up	错误
Remote catch-up pending	备用数据库变成主数据库

您已经看到了如何设置 HADR 环境，以及如何使用数据库角色切换和故障转移方案执行接管。

您学习了如何使用 HADR 使数据库具有高可用性。如果主数据库停机，那么它的备用数据库将接管，并成为新的主数据库。

为了启用自动客户机重路由特性，在主数据库上发出 UPDATE ALTERNATE SERVER 命令。该命令的语法如下：

UPDATE ALTERNATE SERVER FOR DATABASE database-alias
USING HOSTNAME alternate-server-hostname PORT port-number

为了在 server1 上的 TEST1 数据库上启用客户机重路由特性，以便在接管之后已有的和新的客户机连接被重新路由到 server2，在 server1 上发出以下命令：

UPDATE ALTERNATE SERVER FOR DATABASE test1 USING 
HOSTNAME server2.torolab.ibm.com PORT 50000

在这个例子中，50000 是 SVCENAME 端口，而不是 HADR 端口。

备用服务器信息存储在 server1 的数据库目录中。如果发出一个 LIST DB DIRECTORY 命令，那么可以注意到备用服务器信息（主机名和端口号）已经被添加：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

现在让我们来看一个关于如何在启用了自动客户机重路由特性的数据库上执行接管的例子。

在这个例子中，不带 BY FORCE 选项执行一个接管。

首先，建立到 server1 上的 TEST1 数据库的一个远程客户机连接。为此，只需在一个远程 DB2 客户机上发出一条 CONNECT TO DATABASE 命令：

CONNECT TO DB test1 USER user1

为了建立那样的连接，客户机必须已经被配置为连接到 server1。关于如何配置远程客户机连接的信息，请参考本系列中的第一篇教程。

在建立连接之后，主服务器上的备用服务器信息被获取并存储在客户机的数据库目录中：

 Database alias                       = TEST1
 Database name                        = TEST1
 Node name                            = server1
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Remote
 Catalog database partition number    = -1
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

确保该连接已成功建立，并且可以查询 TEST1 数据库。在 server1 上发出一条 LIST APPLICATION 命令，它应该显示数据库 TEST1 上的远程客户机连接：

D:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      8          9.26.94.149.24336.060601000305
                                                         TEST1    1

接着，在 TEST1 数据库上执行接管。在备用服务器 server2 上发出以下命令：

TAKEOVER HADR ON DB test1

让我们看看这次接管完成后远程客户机连接有什么变化。

再次尝试从客户机查询 TEST1 数据库。对 TEST1 数据库的任何查询应该都会返回一个错误消息。例如，从客户机连接发出一条 LIST TABLES 命令：

D:\Programs\IBM\SQLLIB\BIN>db2 list tables
SQL30108N A connection failed but has been re-established. 
The hostname or IP address is "server2" and the service name or port number is "50000". 
Special registers may or may not be re-attempted (Reason code = "1").  
SQLSTATE=08506

这证明客户机重路由特性在起作用。现在您已经连接到新的主服务器，即 server2。

在 server2 上发出一条 LIST APPLICATIONS 命令。您可以看到，远程客户机连接已经被重新路由到那里：

H:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      55         9.26.94.149.29200.060601001803
                                                         TEST1    1

如果再次查询数据库，那么可以从新的主服务器得到一个响应。而且，到原来主服务器的新连接也被重新路由到新的主服务器。

使用 GET SNAPSHOT 命令可以获得数据库的 HADR 状态。在 server2 上发出以下命令，应该可以看到 server2 已经接管了主数据库角色：

db2 "get snapshot for database on test1"

  HADR Status
  Role                   = Primary
  State                  = Peer
  Synchronization mode   = Nearsync
  Connection status      = Connected , 05/31/2006 20:17:24.989618
  Heartbeats missed      = 0
  Local host             = server2.torolab.ibm.com
  Local service          = 80000
  Remote host            = server1.torolab.ibm.com
  Remote service         = 70000
  Remote instance        = db2inst1
  timeout(seconds)       = 120
  Primary log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Standby log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Log gap running average(bytes) = 0

在执行接管操作之后，如果出故障的数据库又可以使用，它不会自动恢复主数据库的角色。

通过以下步骤可以使之重新成为主数据库：

修复原来的主数据库所在的系统。这包括修复有问题的硬件或者重新启动崩溃的操作系统。
重新启动出故障的主数据库，使之成为一个备用数据库。
执行一个接管操作，使之接管主数据库的角色。

当原来的主数据库重新以备用数据库的角色加入 HADR 对之后，执行一个接管操作来切换数据库的角色，使原来的主数据库再次成为主数据库。

为了停止 TEST1 数据库上的 HADR，发出：

STOP HADR ON DB test1

您可以看到，HADR 是实现高可用性解决方案的一个强大的特性。提供了一个名为 HADR 向导的图形化用户界面工具，以帮助您设置和配置 HADR。

如果选择 Set Up，那么就会打开一个如图 15 所示的逐步向导。

如果使用 Control Center 设置 HADR 环境，则会自动启用自动客户机重路由特性。

阅读(23818) | 评论(0) | 转发(0) |

上一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（4）

下一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（6）

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

16024965号-6

高可用性灾难恢复（HADR）

DB2 高可用性灾难恢复（HADR）是一种数据库复制特性，它提供了一种高可用性解决方案。目前，HADR 只用于单分区数据库环境。

为了设置 HADR 环境，要更新一些数据库配置参数。

首先，必须启用主数据库上的归档日志记录。请参阅备份和恢复教程，以了解如何启用归档日志记录。

表 1 列出了与 HADR 相关的数据库配置参数的描述。本教程后面将给出一个关于如何更新这些参数的例子。

与 HADR 相关的数据库配置参数	描述
HADR_LOCAL_HOST	指定 HADR TCPIP 通信的本地主机。主机名和 IP 地址都可以使用
HADR_LOCAL_SVC	指定 TCPIP 服务名和端口号，HADR 进程将在本地主机上接受该服务或端口的连接。这个端口不能与 HADR 实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_HOST	指定远程 HADR 节点的 TCPIP 主机名或 IP 地址
HADR_REMOTE_SVC	指定 TCPIP 服务名或端口号，HADR 进程将在远程节点上接受该服务或端口的连接。这个端口不能与远程实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_INST	指定远程服务器的实例名。DB2 Control Center 之类的管理工具将使用这个参数与远程服务器联系
HADR_TIMEOUT	HADR 进程在认为一次通信尝试失败之前所等待的时间（以秒为单位）。默认值为 120 秒
HADR_SYNCMODE	指定同步模式。它决定当系统处于对等状态时，主日志写与备用数据库如何同步。有效值有 SYNC、NEARSYNC 和 ASYNC。默认值为 NEARSYNC。（本节后面将讨论对等状态）。
HADR_DB_ROLE	指定一个数据库当前的角色。有效值有 STANDARD、PRIMARY 和 STANDBY。STANDARD 意味着数据库没有启用 HADR。

当备用数据库第一次启动时，它进入 local catch-up 状态。本地日志路径中的日志文件（如果有的话）将被读取，并应用到备用数据库。

当到达本地日志文件的最后时，备用数据库进入 remote catch-up 状态。它重演主数据库的归档日志和活动日志，直到备用数据库应用了最近的活动日志。

当主系统上的所有日志文件都已经被重演时，主数据库和备用数据库就进入对等（peer）状态。

在同步模式中，日志写只有在以下情况下才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库的日志文件中。

主数据库与备用数据库中的日志记录几乎（或近似）是同步的，因为只有在以下情况下，日志写才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库上的主存中。

在这种模式下，主数据库不等待收到备用数据库的通知。只有在以下情况下，日志写才被认为是成功的：

日志记录已经被写到主数据库上的日志文件中。
日志记录已经被传送到备用数据库；不需要通知。

HADR 是通过以下三个简单的命令来管理的：

START HADR
STOP HADR
TAKENOVER HADR

这些命令的语法如下：

START HADR ON DATABASE database-alias
[USER userid] [USING password] 
AS PRIMARY | STANDBY [BY FORCE]

STOP HADR ON DATABASE database-alias 
[USER userid] [USING password] 

TAKEOVER HADR ON DATABASE database-alias
[USER userid] [USING password] 
[BY FORCE]

您已经学习了 HADR 的概念，现在可以学习如何设置 HADR 环境。

使用另一个数据库服务器 server2.torolab.ibm.com 作为备用服务器。TEST1 当前不在备用服务器上。

服务名	实例名	SVCENAME 或端口号	数据库名
server1.torolab.ibm.com	DB2INST1	50000	TEST1
server2.torolab.ibm.com	DB2INST1	50000	--

第一次初始化 HADR 时，执行图 13 所示的五个步骤：

确定主服务器和备用服务器。决定主机名、主机 IP 地址和每个 HADR 数据库的服务名或端口号。
您已经确定了主服务器和备用服务器。主服务器是 server1。备用服务器是 server2。

确保这两个服务器是通过 TCPIP 相互通信的。尝试用主机名在这两个服务器上相互 ping 对方。应确保输出没有错误。如果主机名不能使用，那么尝试使用它们的 TCPIP 地址。选用两者中最好用的一种用于 HADR 配置。

通过克隆主数据库创建备用数据库。

有两种方案可用于克隆主数据库：

一种方案是为主数据库做一个备份，并在备用数据库上恢复这个数据库备份。这种方案使用标准备份和恢复方法。
克隆主数据库的另一种方案是使用分割镜像。为主数据库做一个分割镜像，然后在备用服务器上初始化该分割镜像。当初始化分割镜像时，必须在 db2inidb 命令中使用 standby 选项，以便使用 mirror 和 snapshot 选项。

在这个例子种，使用备份/恢复方法来创建备用数据库。

首先为 server1 上的主数据库 TEST1 做一个备份：

BACKUP DB test1

接着，通过 ftp 将备份镜像传送到备用服务器，并恢复该备份镜像。

将备份镜像恢复到与主服务器上相同的位置。在主服务器上，发出 LIST DB DIRECTORY 命令将显示：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            =
 Alternate server port number         =

数据库位于主服务器上的 C: 盘上。当在备用服务器上恢复备份镜像时，也将它恢复到 C: 盘。在备用服务器 server2 上，发出以下命令来恢复 TEST1 数据库：

RESTORE DB test1 ON C:

在主数据库和备用数据库上设置以下 HADR 配置参数：

HADR_LOCAL_HOST
HADR_LOCAL_SVC
HADR_REMOTE_HOST
HADR_REMOTE_SVC
HADR_REMOTE_INST
HADR_SYNCMODE
LOGINDEXBUILD

在主服务器上，为 HADR 使用端口号 70000。更新 Windows\System32\drivers\etc\services 文件，在其中添加以下一行：

Hadr_port 	70000/tcp

在备用服务器上的 services 文件中添加以下一行：

Hadr_port 	80000/tcp

为 HADR_SYNCMODE 使用默认值，即 NEARSYNC。

您已经有了配置 HADR 参数所需的所有信息。发出以下命令来配置备用服务器上的参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在主数据库服务器上，配置相同的一组参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在备用数据库上使用 START HADR 命令启动 HADR：
START HADR ON DB test1 AS STANDBY
在启动主数据库之前启动备用数据库。如果先启动主数据库，那么，如果没有在 HADR_TIMEOUT 数据库配置参数指定的期限内启动备用数据库，那么主数据库的启动过程就会失败。
在主数据库上启动 HADR，如下面的例子所示：
START HADR ON DB test1 AS PRIMARY
HADR 现在已经在主数据库和备用数据库上启动了。

当第一次启动主服务器时，它等待备用服务器与它联系。如果在指定期限内备用服务器没有与主服务器联系，那么 HADR 将不启动。这个期限可以用 HADR_TIMEOUT 配置参数（见表 1）来配置。这样做的目的是避免两个系统在偶然的情况下与主服务器同时启动。

在 HADR 启动过程中，数据库经历以下状态：local catch-up、remote catch-up pending、remote catch-up 和对等状态。日志被自动从主服务器传送到备用服务器，然后在备用服务器上重演。这是为了确保备用数据库跟上主数据库的变化。

强烈建议在主数据库和备用数据库所在的系统上使用相同的数据库配置参数和数据库管理器配置参数。否则，备用数据库就不会像主数据库一样执行。

一个例外是 LOGFILSIZ 数据库配置参数。这个参数的值被备用服务器所忽略。备用服务器自动创建与主数据库上的日志文件大小相匹配的日志文件。这保证了两个数据库上的日志文件是一致的。

在主数据库与备用数据库之间切换数据库角色，也就是说，备用数据库变成主数据库，主数据库变成备用数据库。
从主数据库故障转移到备用数据库。

   GET SNAPSHOT FOR DATABASE ON test1

下面的命令在备用数据库 TEST1 上开始 HADR 数据库切换角色操作：

   TAKEOVER HADR ON DB test1

故障转移方案不切换数据库角色。在故障转移操作期间，备用数据库接管主数据库角色，但是主数据库不会变成备用数据库。

下面的命令在数据库 TEST1 上开始一个 HADR 故障转移操作：

   TAKEOVER HADR ON DB test1 BY FORCE

表 3 和 4 总结了在备用数据库上发出的 TAKEOVER HADR 命令的行为，以及备用数据库所处的对应的 HADR 状态：

备用数据库的状态	接管行为
对等	主数据库和备用数据库都切换角色
Local catch-up or remote catch-up	错误
Remote catch-up pending	错误

备用数据库的状态	接管行为
对等	备用数据库通知主数据库关闭。备用数据库停止接收来自主数据库的日志，完成它已经收到的日志的重演，然后变成主数据库。备用数据库不用等到主数据库发来通知确认它受到接管通知或者它已经关闭
Local catch-up OR remote catch-up	错误
Remote catch-up pending	备用数据库变成主数据库

您已经看到了如何设置 HADR 环境，以及如何使用数据库角色切换和故障转移方案执行接管。

您学习了如何使用 HADR 使数据库具有高可用性。如果主数据库停机，那么它的备用数据库将接管，并成为新的主数据库。

为了启用自动客户机重路由特性，在主数据库上发出 UPDATE ALTERNATE SERVER 命令。该命令的语法如下：

UPDATE ALTERNATE SERVER FOR DATABASE database-alias
USING HOSTNAME alternate-server-hostname PORT port-number

为了在 server1 上的 TEST1 数据库上启用客户机重路由特性，以便在接管之后已有的和新的客户机连接被重新路由到 server2，在 server1 上发出以下命令：

UPDATE ALTERNATE SERVER FOR DATABASE test1 USING 
HOSTNAME server2.torolab.ibm.com PORT 50000

在这个例子中，50000 是 SVCENAME 端口，而不是 HADR 端口。

备用服务器信息存储在 server1 的数据库目录中。如果发出一个 LIST DB DIRECTORY 命令，那么可以注意到备用服务器信息（主机名和端口号）已经被添加：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

现在让我们来看一个关于如何在启用了自动客户机重路由特性的数据库上执行接管的例子。

在这个例子中，不带 BY FORCE 选项执行一个接管。

首先，建立到 server1 上的 TEST1 数据库的一个远程客户机连接。为此，只需在一个远程 DB2 客户机上发出一条 CONNECT TO DATABASE 命令：

CONNECT TO DB test1 USER user1

为了建立那样的连接，客户机必须已经被配置为连接到 server1。关于如何配置远程客户机连接的信息，请参考本系列中的第一篇教程。

在建立连接之后，主服务器上的备用服务器信息被获取并存储在客户机的数据库目录中：

 Database alias                       = TEST1
 Database name                        = TEST1
 Node name                            = server1
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Remote
 Catalog database partition number    = -1
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

确保该连接已成功建立，并且可以查询 TEST1 数据库。在 server1 上发出一条 LIST APPLICATION 命令，它应该显示数据库 TEST1 上的远程客户机连接：

D:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      8          9.26.94.149.24336.060601000305
                                                         TEST1    1

接着，在 TEST1 数据库上执行接管。在备用服务器 server2 上发出以下命令：

TAKEOVER HADR ON DB test1

让我们看看这次接管完成后远程客户机连接有什么变化。

再次尝试从客户机查询 TEST1 数据库。对 TEST1 数据库的任何查询应该都会返回一个错误消息。例如，从客户机连接发出一条 LIST TABLES 命令：

D:\Programs\IBM\SQLLIB\BIN>db2 list tables
SQL30108N A connection failed but has been re-established. 
The hostname or IP address is "server2" and the service name or port number is "50000". 
Special registers may or may not be re-attempted (Reason code = "1").  
SQLSTATE=08506

这证明客户机重路由特性在起作用。现在您已经连接到新的主服务器，即 server2。

在 server2 上发出一条 LIST APPLICATIONS 命令。您可以看到，远程客户机连接已经被重新路由到那里：

H:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      55         9.26.94.149.29200.060601001803
                                                         TEST1    1

如果再次查询数据库，那么可以从新的主服务器得到一个响应。而且，到原来主服务器的新连接也被重新路由到新的主服务器。

使用 GET SNAPSHOT 命令可以获得数据库的 HADR 状态。在 server2 上发出以下命令，应该可以看到 server2 已经接管了主数据库角色：

db2 "get snapshot for database on test1"

  HADR Status
  Role                   = Primary
  State                  = Peer
  Synchronization mode   = Nearsync
  Connection status      = Connected , 05/31/2006 20:17:24.989618
  Heartbeats missed      = 0
  Local host             = server2.torolab.ibm.com
  Local service          = 80000
  Remote host            = server1.torolab.ibm.com
  Remote service         = 70000
  Remote instance        = db2inst1
  timeout(seconds)       = 120
  Primary log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Standby log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Log gap running average(bytes) = 0

在执行接管操作之后，如果出故障的数据库又可以使用，它不会自动恢复主数据库的角色。

通过以下步骤可以使之重新成为主数据库：

修复原来的主数据库所在的系统。这包括修复有问题的硬件或者重新启动崩溃的操作系统。
重新启动出故障的主数据库，使之成为一个备用数据库。
执行一个接管操作，使之接管主数据库的角色。

当原来的主数据库重新以备用数据库的角色加入 HADR 对之后，执行一个接管操作来切换数据库的角色，使原来的主数据库再次成为主数据库。

为了停止 TEST1 数据库上的 HADR，发出：

STOP HADR ON DB test1

您可以看到，HADR 是实现高可用性解决方案的一个强大的特性。提供了一个名为 HADR 向导的图形化用户界面工具，以帮助您设置和配置 HADR。

如果选择 Set Up，那么就会打开一个如图 15 所示的逐步向导。

如果使用 Control Center 设置 HADR 环境，则会自动启用自动客户机重路由特性。

阅读(23817) | 评论(0) | 转发(0) |

上一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（4）

下一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（6）

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

16024965号-6

高可用性灾难恢复（HADR）

DB2 高可用性灾难恢复（HADR）是一种数据库复制特性，它提供了一种高可用性解决方案。目前，HADR 只用于单分区数据库环境。

为了设置 HADR 环境，要更新一些数据库配置参数。

首先，必须启用主数据库上的归档日志记录。请参阅备份和恢复教程，以了解如何启用归档日志记录。

表 1 列出了与 HADR 相关的数据库配置参数的描述。本教程后面将给出一个关于如何更新这些参数的例子。

与 HADR 相关的数据库配置参数	描述
HADR_LOCAL_HOST	指定 HADR TCPIP 通信的本地主机。主机名和 IP 地址都可以使用
HADR_LOCAL_SVC	指定 TCPIP 服务名和端口号，HADR 进程将在本地主机上接受该服务或端口的连接。这个端口不能与 HADR 实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_HOST	指定远程 HADR 节点的 TCPIP 主机名或 IP 地址
HADR_REMOTE_SVC	指定 TCPIP 服务名或端口号，HADR 进程将在远程节点上接受该服务或端口的连接。这个端口不能与远程实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_INST	指定远程服务器的实例名。DB2 Control Center 之类的管理工具将使用这个参数与远程服务器联系
HADR_TIMEOUT	HADR 进程在认为一次通信尝试失败之前所等待的时间（以秒为单位）。默认值为 120 秒
HADR_SYNCMODE	指定同步模式。它决定当系统处于对等状态时，主日志写与备用数据库如何同步。有效值有 SYNC、NEARSYNC 和 ASYNC。默认值为 NEARSYNC。（本节后面将讨论对等状态）。
HADR_DB_ROLE	指定一个数据库当前的角色。有效值有 STANDARD、PRIMARY 和 STANDBY。STANDARD 意味着数据库没有启用 HADR。

当备用数据库第一次启动时，它进入 local catch-up 状态。本地日志路径中的日志文件（如果有的话）将被读取，并应用到备用数据库。

当到达本地日志文件的最后时，备用数据库进入 remote catch-up 状态。它重演主数据库的归档日志和活动日志，直到备用数据库应用了最近的活动日志。

当主系统上的所有日志文件都已经被重演时，主数据库和备用数据库就进入对等（peer）状态。

在同步模式中，日志写只有在以下情况下才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库的日志文件中。

主数据库与备用数据库中的日志记录几乎（或近似）是同步的，因为只有在以下情况下，日志写才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库上的主存中。

在这种模式下，主数据库不等待收到备用数据库的通知。只有在以下情况下，日志写才被认为是成功的：

日志记录已经被写到主数据库上的日志文件中。
日志记录已经被传送到备用数据库；不需要通知。

HADR 是通过以下三个简单的命令来管理的：

START HADR
STOP HADR
TAKENOVER HADR

这些命令的语法如下：

START HADR ON DATABASE database-alias
[USER userid] [USING password] 
AS PRIMARY | STANDBY [BY FORCE]

STOP HADR ON DATABASE database-alias 
[USER userid] [USING password] 

TAKEOVER HADR ON DATABASE database-alias
[USER userid] [USING password] 
[BY FORCE]

您已经学习了 HADR 的概念，现在可以学习如何设置 HADR 环境。

使用另一个数据库服务器 server2.torolab.ibm.com 作为备用服务器。TEST1 当前不在备用服务器上。

服务名	实例名	SVCENAME 或端口号	数据库名
server1.torolab.ibm.com	DB2INST1	50000	TEST1
server2.torolab.ibm.com	DB2INST1	50000	--

第一次初始化 HADR 时，执行图 13 所示的五个步骤：

确定主服务器和备用服务器。决定主机名、主机 IP 地址和每个 HADR 数据库的服务名或端口号。
您已经确定了主服务器和备用服务器。主服务器是 server1。备用服务器是 server2。

确保这两个服务器是通过 TCPIP 相互通信的。尝试用主机名在这两个服务器上相互 ping 对方。应确保输出没有错误。如果主机名不能使用，那么尝试使用它们的 TCPIP 地址。选用两者中最好用的一种用于 HADR 配置。

通过克隆主数据库创建备用数据库。

有两种方案可用于克隆主数据库：

一种方案是为主数据库做一个备份，并在备用数据库上恢复这个数据库备份。这种方案使用标准备份和恢复方法。
克隆主数据库的另一种方案是使用分割镜像。为主数据库做一个分割镜像，然后在备用服务器上初始化该分割镜像。当初始化分割镜像时，必须在 db2inidb 命令中使用 standby 选项，以便使用 mirror 和 snapshot 选项。

在这个例子种，使用备份/恢复方法来创建备用数据库。

首先为 server1 上的主数据库 TEST1 做一个备份：

BACKUP DB test1

接着，通过 ftp 将备份镜像传送到备用服务器，并恢复该备份镜像。

将备份镜像恢复到与主服务器上相同的位置。在主服务器上，发出 LIST DB DIRECTORY 命令将显示：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            =
 Alternate server port number         =

数据库位于主服务器上的 C: 盘上。当在备用服务器上恢复备份镜像时，也将它恢复到 C: 盘。在备用服务器 server2 上，发出以下命令来恢复 TEST1 数据库：

RESTORE DB test1 ON C:

在主数据库和备用数据库上设置以下 HADR 配置参数：

HADR_LOCAL_HOST
HADR_LOCAL_SVC
HADR_REMOTE_HOST
HADR_REMOTE_SVC
HADR_REMOTE_INST
HADR_SYNCMODE
LOGINDEXBUILD

在主服务器上，为 HADR 使用端口号 70000。更新 Windows\System32\drivers\etc\services 文件，在其中添加以下一行：

Hadr_port 	70000/tcp

在备用服务器上的 services 文件中添加以下一行：

Hadr_port 	80000/tcp

为 HADR_SYNCMODE 使用默认值，即 NEARSYNC。

您已经有了配置 HADR 参数所需的所有信息。发出以下命令来配置备用服务器上的参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在主数据库服务器上，配置相同的一组参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在备用数据库上使用 START HADR 命令启动 HADR：
START HADR ON DB test1 AS STANDBY
在启动主数据库之前启动备用数据库。如果先启动主数据库，那么，如果没有在 HADR_TIMEOUT 数据库配置参数指定的期限内启动备用数据库，那么主数据库的启动过程就会失败。
在主数据库上启动 HADR，如下面的例子所示：
START HADR ON DB test1 AS PRIMARY
HADR 现在已经在主数据库和备用数据库上启动了。

当第一次启动主服务器时，它等待备用服务器与它联系。如果在指定期限内备用服务器没有与主服务器联系，那么 HADR 将不启动。这个期限可以用 HADR_TIMEOUT 配置参数（见表 1）来配置。这样做的目的是避免两个系统在偶然的情况下与主服务器同时启动。

在 HADR 启动过程中，数据库经历以下状态：local catch-up、remote catch-up pending、remote catch-up 和对等状态。日志被自动从主服务器传送到备用服务器，然后在备用服务器上重演。这是为了确保备用数据库跟上主数据库的变化。

强烈建议在主数据库和备用数据库所在的系统上使用相同的数据库配置参数和数据库管理器配置参数。否则，备用数据库就不会像主数据库一样执行。

一个例外是 LOGFILSIZ 数据库配置参数。这个参数的值被备用服务器所忽略。备用服务器自动创建与主数据库上的日志文件大小相匹配的日志文件。这保证了两个数据库上的日志文件是一致的。

在主数据库与备用数据库之间切换数据库角色，也就是说，备用数据库变成主数据库，主数据库变成备用数据库。
从主数据库故障转移到备用数据库。

   GET SNAPSHOT FOR DATABASE ON test1

下面的命令在备用数据库 TEST1 上开始 HADR 数据库切换角色操作：

   TAKEOVER HADR ON DB test1

故障转移方案不切换数据库角色。在故障转移操作期间，备用数据库接管主数据库角色，但是主数据库不会变成备用数据库。

下面的命令在数据库 TEST1 上开始一个 HADR 故障转移操作：

   TAKEOVER HADR ON DB test1 BY FORCE

表 3 和 4 总结了在备用数据库上发出的 TAKEOVER HADR 命令的行为，以及备用数据库所处的对应的 HADR 状态：

备用数据库的状态	接管行为
对等	主数据库和备用数据库都切换角色
Local catch-up or remote catch-up	错误
Remote catch-up pending	错误

备用数据库的状态	接管行为
对等	备用数据库通知主数据库关闭。备用数据库停止接收来自主数据库的日志，完成它已经收到的日志的重演，然后变成主数据库。备用数据库不用等到主数据库发来通知确认它受到接管通知或者它已经关闭
Local catch-up OR remote catch-up	错误
Remote catch-up pending	备用数据库变成主数据库

您已经看到了如何设置 HADR 环境，以及如何使用数据库角色切换和故障转移方案执行接管。

您学习了如何使用 HADR 使数据库具有高可用性。如果主数据库停机，那么它的备用数据库将接管，并成为新的主数据库。

为了启用自动客户机重路由特性，在主数据库上发出 UPDATE ALTERNATE SERVER 命令。该命令的语法如下：

UPDATE ALTERNATE SERVER FOR DATABASE database-alias
USING HOSTNAME alternate-server-hostname PORT port-number

为了在 server1 上的 TEST1 数据库上启用客户机重路由特性，以便在接管之后已有的和新的客户机连接被重新路由到 server2，在 server1 上发出以下命令：

UPDATE ALTERNATE SERVER FOR DATABASE test1 USING 
HOSTNAME server2.torolab.ibm.com PORT 50000

在这个例子中，50000 是 SVCENAME 端口，而不是 HADR 端口。

备用服务器信息存储在 server1 的数据库目录中。如果发出一个 LIST DB DIRECTORY 命令，那么可以注意到备用服务器信息（主机名和端口号）已经被添加：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

现在让我们来看一个关于如何在启用了自动客户机重路由特性的数据库上执行接管的例子。

在这个例子中，不带 BY FORCE 选项执行一个接管。

首先，建立到 server1 上的 TEST1 数据库的一个远程客户机连接。为此，只需在一个远程 DB2 客户机上发出一条 CONNECT TO DATABASE 命令：

CONNECT TO DB test1 USER user1

为了建立那样的连接，客户机必须已经被配置为连接到 server1。关于如何配置远程客户机连接的信息，请参考本系列中的第一篇教程。

在建立连接之后，主服务器上的备用服务器信息被获取并存储在客户机的数据库目录中：

 Database alias                       = TEST1
 Database name                        = TEST1
 Node name                            = server1
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Remote
 Catalog database partition number    = -1
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

确保该连接已成功建立，并且可以查询 TEST1 数据库。在 server1 上发出一条 LIST APPLICATION 命令，它应该显示数据库 TEST1 上的远程客户机连接：

D:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      8          9.26.94.149.24336.060601000305
                                                         TEST1    1

接着，在 TEST1 数据库上执行接管。在备用服务器 server2 上发出以下命令：

TAKEOVER HADR ON DB test1

让我们看看这次接管完成后远程客户机连接有什么变化。

再次尝试从客户机查询 TEST1 数据库。对 TEST1 数据库的任何查询应该都会返回一个错误消息。例如，从客户机连接发出一条 LIST TABLES 命令：

D:\Programs\IBM\SQLLIB\BIN>db2 list tables
SQL30108N A connection failed but has been re-established. 
The hostname or IP address is "server2" and the service name or port number is "50000". 
Special registers may or may not be re-attempted (Reason code = "1").  
SQLSTATE=08506

这证明客户机重路由特性在起作用。现在您已经连接到新的主服务器，即 server2。

在 server2 上发出一条 LIST APPLICATIONS 命令。您可以看到，远程客户机连接已经被重新路由到那里：

H:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      55         9.26.94.149.29200.060601001803
                                                         TEST1    1

如果再次查询数据库，那么可以从新的主服务器得到一个响应。而且，到原来主服务器的新连接也被重新路由到新的主服务器。

使用 GET SNAPSHOT 命令可以获得数据库的 HADR 状态。在 server2 上发出以下命令，应该可以看到 server2 已经接管了主数据库角色：

db2 "get snapshot for database on test1"

  HADR Status
  Role                   = Primary
  State                  = Peer
  Synchronization mode   = Nearsync
  Connection status      = Connected , 05/31/2006 20:17:24.989618
  Heartbeats missed      = 0
  Local host             = server2.torolab.ibm.com
  Local service          = 80000
  Remote host            = server1.torolab.ibm.com
  Remote service         = 70000
  Remote instance        = db2inst1
  timeout(seconds)       = 120
  Primary log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Standby log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Log gap running average(bytes) = 0

在执行接管操作之后，如果出故障的数据库又可以使用，它不会自动恢复主数据库的角色。

通过以下步骤可以使之重新成为主数据库：

修复原来的主数据库所在的系统。这包括修复有问题的硬件或者重新启动崩溃的操作系统。
重新启动出故障的主数据库，使之成为一个备用数据库。
执行一个接管操作，使之接管主数据库的角色。

当原来的主数据库重新以备用数据库的角色加入 HADR 对之后，执行一个接管操作来切换数据库的角色，使原来的主数据库再次成为主数据库。

为了停止 TEST1 数据库上的 HADR，发出：

STOP HADR ON DB test1

您可以看到，HADR 是实现高可用性解决方案的一个强大的特性。提供了一个名为 HADR 向导的图形化用户界面工具，以帮助您设置和配置 HADR。

如果选择 Set Up，那么就会打开一个如图 15 所示的逐步向导。

如果使用 Control Center 设置 HADR 环境，则会自动启用自动客户机重路由特性。

阅读(23816) | 评论(0) | 转发(0) |

上一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（4）

下一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（6）

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

16024965号-6

高可用性灾难恢复（HADR）

DB2 高可用性灾难恢复（HADR）是一种数据库复制特性，它提供了一种高可用性解决方案。目前，HADR 只用于单分区数据库环境。

为了设置 HADR 环境，要更新一些数据库配置参数。

首先，必须启用主数据库上的归档日志记录。请参阅备份和恢复教程，以了解如何启用归档日志记录。

表 1 列出了与 HADR 相关的数据库配置参数的描述。本教程后面将给出一个关于如何更新这些参数的例子。

与 HADR 相关的数据库配置参数	描述
HADR_LOCAL_HOST	指定 HADR TCPIP 通信的本地主机。主机名和 IP 地址都可以使用
HADR_LOCAL_SVC	指定 TCPIP 服务名和端口号，HADR 进程将在本地主机上接受该服务或端口的连接。这个端口不能与 HADR 实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_HOST	指定远程 HADR 节点的 TCPIP 主机名或 IP 地址
HADR_REMOTE_SVC	指定 TCPIP 服务名或端口号，HADR 进程将在远程节点上接受该服务或端口的连接。这个端口不能与远程实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_INST	指定远程服务器的实例名。DB2 Control Center 之类的管理工具将使用这个参数与远程服务器联系
HADR_TIMEOUT	HADR 进程在认为一次通信尝试失败之前所等待的时间（以秒为单位）。默认值为 120 秒
HADR_SYNCMODE	指定同步模式。它决定当系统处于对等状态时，主日志写与备用数据库如何同步。有效值有 SYNC、NEARSYNC 和 ASYNC。默认值为 NEARSYNC。（本节后面将讨论对等状态）。
HADR_DB_ROLE	指定一个数据库当前的角色。有效值有 STANDARD、PRIMARY 和 STANDBY。STANDARD 意味着数据库没有启用 HADR。

当备用数据库第一次启动时，它进入 local catch-up 状态。本地日志路径中的日志文件（如果有的话）将被读取，并应用到备用数据库。

当到达本地日志文件的最后时，备用数据库进入 remote catch-up 状态。它重演主数据库的归档日志和活动日志，直到备用数据库应用了最近的活动日志。

当主系统上的所有日志文件都已经被重演时，主数据库和备用数据库就进入对等（peer）状态。

在同步模式中，日志写只有在以下情况下才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库的日志文件中。

主数据库与备用数据库中的日志记录几乎（或近似）是同步的，因为只有在以下情况下，日志写才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库上的主存中。

在这种模式下，主数据库不等待收到备用数据库的通知。只有在以下情况下，日志写才被认为是成功的：

日志记录已经被写到主数据库上的日志文件中。
日志记录已经被传送到备用数据库；不需要通知。

HADR 是通过以下三个简单的命令来管理的：

START HADR
STOP HADR
TAKENOVER HADR

这些命令的语法如下：

START HADR ON DATABASE database-alias
[USER userid] [USING password] 
AS PRIMARY | STANDBY [BY FORCE]

STOP HADR ON DATABASE database-alias 
[USER userid] [USING password] 

TAKEOVER HADR ON DATABASE database-alias
[USER userid] [USING password] 
[BY FORCE]

您已经学习了 HADR 的概念，现在可以学习如何设置 HADR 环境。

使用另一个数据库服务器 server2.torolab.ibm.com 作为备用服务器。TEST1 当前不在备用服务器上。

服务名	实例名	SVCENAME 或端口号	数据库名
server1.torolab.ibm.com	DB2INST1	50000	TEST1
server2.torolab.ibm.com	DB2INST1	50000	--

第一次初始化 HADR 时，执行图 13 所示的五个步骤：

确定主服务器和备用服务器。决定主机名、主机 IP 地址和每个 HADR 数据库的服务名或端口号。
您已经确定了主服务器和备用服务器。主服务器是 server1。备用服务器是 server2。

确保这两个服务器是通过 TCPIP 相互通信的。尝试用主机名在这两个服务器上相互 ping 对方。应确保输出没有错误。如果主机名不能使用，那么尝试使用它们的 TCPIP 地址。选用两者中最好用的一种用于 HADR 配置。

通过克隆主数据库创建备用数据库。

有两种方案可用于克隆主数据库：

一种方案是为主数据库做一个备份，并在备用数据库上恢复这个数据库备份。这种方案使用标准备份和恢复方法。
克隆主数据库的另一种方案是使用分割镜像。为主数据库做一个分割镜像，然后在备用服务器上初始化该分割镜像。当初始化分割镜像时，必须在 db2inidb 命令中使用 standby 选项，以便使用 mirror 和 snapshot 选项。

在这个例子种，使用备份/恢复方法来创建备用数据库。

首先为 server1 上的主数据库 TEST1 做一个备份：

BACKUP DB test1

接着，通过 ftp 将备份镜像传送到备用服务器，并恢复该备份镜像。

将备份镜像恢复到与主服务器上相同的位置。在主服务器上，发出 LIST DB DIRECTORY 命令将显示：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            =
 Alternate server port number         =

数据库位于主服务器上的 C: 盘上。当在备用服务器上恢复备份镜像时，也将它恢复到 C: 盘。在备用服务器 server2 上，发出以下命令来恢复 TEST1 数据库：

RESTORE DB test1 ON C:

在主数据库和备用数据库上设置以下 HADR 配置参数：

HADR_LOCAL_HOST
HADR_LOCAL_SVC
HADR_REMOTE_HOST
HADR_REMOTE_SVC
HADR_REMOTE_INST
HADR_SYNCMODE
LOGINDEXBUILD

在主服务器上，为 HADR 使用端口号 70000。更新 Windows\System32\drivers\etc\services 文件，在其中添加以下一行：

Hadr_port 	70000/tcp

在备用服务器上的 services 文件中添加以下一行：

Hadr_port 	80000/tcp

为 HADR_SYNCMODE 使用默认值，即 NEARSYNC。

您已经有了配置 HADR 参数所需的所有信息。发出以下命令来配置备用服务器上的参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在主数据库服务器上，配置相同的一组参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在备用数据库上使用 START HADR 命令启动 HADR：
START HADR ON DB test1 AS STANDBY
在启动主数据库之前启动备用数据库。如果先启动主数据库，那么，如果没有在 HADR_TIMEOUT 数据库配置参数指定的期限内启动备用数据库，那么主数据库的启动过程就会失败。
在主数据库上启动 HADR，如下面的例子所示：
START HADR ON DB test1 AS PRIMARY
HADR 现在已经在主数据库和备用数据库上启动了。

当第一次启动主服务器时，它等待备用服务器与它联系。如果在指定期限内备用服务器没有与主服务器联系，那么 HADR 将不启动。这个期限可以用 HADR_TIMEOUT 配置参数（见表 1）来配置。这样做的目的是避免两个系统在偶然的情况下与主服务器同时启动。

在 HADR 启动过程中，数据库经历以下状态：local catch-up、remote catch-up pending、remote catch-up 和对等状态。日志被自动从主服务器传送到备用服务器，然后在备用服务器上重演。这是为了确保备用数据库跟上主数据库的变化。

强烈建议在主数据库和备用数据库所在的系统上使用相同的数据库配置参数和数据库管理器配置参数。否则，备用数据库就不会像主数据库一样执行。

一个例外是 LOGFILSIZ 数据库配置参数。这个参数的值被备用服务器所忽略。备用服务器自动创建与主数据库上的日志文件大小相匹配的日志文件。这保证了两个数据库上的日志文件是一致的。

在主数据库与备用数据库之间切换数据库角色，也就是说，备用数据库变成主数据库，主数据库变成备用数据库。
从主数据库故障转移到备用数据库。

   GET SNAPSHOT FOR DATABASE ON test1

下面的命令在备用数据库 TEST1 上开始 HADR 数据库切换角色操作：

   TAKEOVER HADR ON DB test1

故障转移方案不切换数据库角色。在故障转移操作期间，备用数据库接管主数据库角色，但是主数据库不会变成备用数据库。

下面的命令在数据库 TEST1 上开始一个 HADR 故障转移操作：

   TAKEOVER HADR ON DB test1 BY FORCE

表 3 和 4 总结了在备用数据库上发出的 TAKEOVER HADR 命令的行为，以及备用数据库所处的对应的 HADR 状态：

备用数据库的状态	接管行为
对等	主数据库和备用数据库都切换角色
Local catch-up or remote catch-up	错误
Remote catch-up pending	错误

备用数据库的状态	接管行为
对等	备用数据库通知主数据库关闭。备用数据库停止接收来自主数据库的日志，完成它已经收到的日志的重演，然后变成主数据库。备用数据库不用等到主数据库发来通知确认它受到接管通知或者它已经关闭
Local catch-up OR remote catch-up	错误
Remote catch-up pending	备用数据库变成主数据库

您已经看到了如何设置 HADR 环境，以及如何使用数据库角色切换和故障转移方案执行接管。

您学习了如何使用 HADR 使数据库具有高可用性。如果主数据库停机，那么它的备用数据库将接管，并成为新的主数据库。

为了启用自动客户机重路由特性，在主数据库上发出 UPDATE ALTERNATE SERVER 命令。该命令的语法如下：

UPDATE ALTERNATE SERVER FOR DATABASE database-alias
USING HOSTNAME alternate-server-hostname PORT port-number

为了在 server1 上的 TEST1 数据库上启用客户机重路由特性，以便在接管之后已有的和新的客户机连接被重新路由到 server2，在 server1 上发出以下命令：

UPDATE ALTERNATE SERVER FOR DATABASE test1 USING 
HOSTNAME server2.torolab.ibm.com PORT 50000

在这个例子中，50000 是 SVCENAME 端口，而不是 HADR 端口。

备用服务器信息存储在 server1 的数据库目录中。如果发出一个 LIST DB DIRECTORY 命令，那么可以注意到备用服务器信息（主机名和端口号）已经被添加：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

现在让我们来看一个关于如何在启用了自动客户机重路由特性的数据库上执行接管的例子。

在这个例子中，不带 BY FORCE 选项执行一个接管。

首先，建立到 server1 上的 TEST1 数据库的一个远程客户机连接。为此，只需在一个远程 DB2 客户机上发出一条 CONNECT TO DATABASE 命令：

CONNECT TO DB test1 USER user1

为了建立那样的连接，客户机必须已经被配置为连接到 server1。关于如何配置远程客户机连接的信息，请参考本系列中的第一篇教程。

在建立连接之后，主服务器上的备用服务器信息被获取并存储在客户机的数据库目录中：

 Database alias                       = TEST1
 Database name                        = TEST1
 Node name                            = server1
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Remote
 Catalog database partition number    = -1
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

确保该连接已成功建立，并且可以查询 TEST1 数据库。在 server1 上发出一条 LIST APPLICATION 命令，它应该显示数据库 TEST1 上的远程客户机连接：

D:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      8          9.26.94.149.24336.060601000305
                                                         TEST1    1

接着，在 TEST1 数据库上执行接管。在备用服务器 server2 上发出以下命令：

TAKEOVER HADR ON DB test1

让我们看看这次接管完成后远程客户机连接有什么变化。

再次尝试从客户机查询 TEST1 数据库。对 TEST1 数据库的任何查询应该都会返回一个错误消息。例如，从客户机连接发出一条 LIST TABLES 命令：

D:\Programs\IBM\SQLLIB\BIN>db2 list tables
SQL30108N A connection failed but has been re-established. 
The hostname or IP address is "server2" and the service name or port number is "50000". 
Special registers may or may not be re-attempted (Reason code = "1").  
SQLSTATE=08506

这证明客户机重路由特性在起作用。现在您已经连接到新的主服务器，即 server2。

在 server2 上发出一条 LIST APPLICATIONS 命令。您可以看到，远程客户机连接已经被重新路由到那里：

H:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      55         9.26.94.149.29200.060601001803
                                                         TEST1    1

如果再次查询数据库，那么可以从新的主服务器得到一个响应。而且，到原来主服务器的新连接也被重新路由到新的主服务器。

使用 GET SNAPSHOT 命令可以获得数据库的 HADR 状态。在 server2 上发出以下命令，应该可以看到 server2 已经接管了主数据库角色：

db2 "get snapshot for database on test1"

  HADR Status
  Role                   = Primary
  State                  = Peer
  Synchronization mode   = Nearsync
  Connection status      = Connected , 05/31/2006 20:17:24.989618
  Heartbeats missed      = 0
  Local host             = server2.torolab.ibm.com
  Local service          = 80000
  Remote host            = server1.torolab.ibm.com
  Remote service         = 70000
  Remote instance        = db2inst1
  timeout(seconds)       = 120
  Primary log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Standby log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Log gap running average(bytes) = 0

在执行接管操作之后，如果出故障的数据库又可以使用，它不会自动恢复主数据库的角色。

通过以下步骤可以使之重新成为主数据库：

修复原来的主数据库所在的系统。这包括修复有问题的硬件或者重新启动崩溃的操作系统。
重新启动出故障的主数据库，使之成为一个备用数据库。
执行一个接管操作，使之接管主数据库的角色。

当原来的主数据库重新以备用数据库的角色加入 HADR 对之后，执行一个接管操作来切换数据库的角色，使原来的主数据库再次成为主数据库。

为了停止 TEST1 数据库上的 HADR，发出：

STOP HADR ON DB test1

您可以看到，HADR 是实现高可用性解决方案的一个强大的特性。提供了一个名为 HADR 向导的图形化用户界面工具，以帮助您设置和配置 HADR。

如果选择 Set Up，那么就会打开一个如图 15 所示的逐步向导。

如果使用 Control Center 设置 HADR 环境，则会自动启用自动客户机重路由特性。

阅读(23815) | 评论(0) | 转发(0) |

上一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（4）

下一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（6）

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

16024965号-6

高可用性灾难恢复（HADR）

DB2 高可用性灾难恢复（HADR）是一种数据库复制特性，它提供了一种高可用性解决方案。目前，HADR 只用于单分区数据库环境。

为了设置 HADR 环境，要更新一些数据库配置参数。

首先，必须启用主数据库上的归档日志记录。请参阅备份和恢复教程，以了解如何启用归档日志记录。

表 1 列出了与 HADR 相关的数据库配置参数的描述。本教程后面将给出一个关于如何更新这些参数的例子。

与 HADR 相关的数据库配置参数	描述
HADR_LOCAL_HOST	指定 HADR TCPIP 通信的本地主机。主机名和 IP 地址都可以使用
HADR_LOCAL_SVC	指定 TCPIP 服务名和端口号，HADR 进程将在本地主机上接受该服务或端口的连接。这个端口不能与 HADR 实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_HOST	指定远程 HADR 节点的 TCPIP 主机名或 IP 地址
HADR_REMOTE_SVC	指定 TCPIP 服务名或端口号，HADR 进程将在远程节点上接受该服务或端口的连接。这个端口不能与远程实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_INST	指定远程服务器的实例名。DB2 Control Center 之类的管理工具将使用这个参数与远程服务器联系
HADR_TIMEOUT	HADR 进程在认为一次通信尝试失败之前所等待的时间（以秒为单位）。默认值为 120 秒
HADR_SYNCMODE	指定同步模式。它决定当系统处于对等状态时，主日志写与备用数据库如何同步。有效值有 SYNC、NEARSYNC 和 ASYNC。默认值为 NEARSYNC。（本节后面将讨论对等状态）。
HADR_DB_ROLE	指定一个数据库当前的角色。有效值有 STANDARD、PRIMARY 和 STANDBY。STANDARD 意味着数据库没有启用 HADR。

当备用数据库第一次启动时，它进入 local catch-up 状态。本地日志路径中的日志文件（如果有的话）将被读取，并应用到备用数据库。

当到达本地日志文件的最后时，备用数据库进入 remote catch-up 状态。它重演主数据库的归档日志和活动日志，直到备用数据库应用了最近的活动日志。

当主系统上的所有日志文件都已经被重演时，主数据库和备用数据库就进入对等（peer）状态。

在同步模式中，日志写只有在以下情况下才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库的日志文件中。

主数据库与备用数据库中的日志记录几乎（或近似）是同步的，因为只有在以下情况下，日志写才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库上的主存中。

在这种模式下，主数据库不等待收到备用数据库的通知。只有在以下情况下，日志写才被认为是成功的：

日志记录已经被写到主数据库上的日志文件中。
日志记录已经被传送到备用数据库；不需要通知。

HADR 是通过以下三个简单的命令来管理的：

START HADR
STOP HADR
TAKENOVER HADR

这些命令的语法如下：

START HADR ON DATABASE database-alias
[USER userid] [USING password] 
AS PRIMARY | STANDBY [BY FORCE]

STOP HADR ON DATABASE database-alias 
[USER userid] [USING password] 

TAKEOVER HADR ON DATABASE database-alias
[USER userid] [USING password] 
[BY FORCE]

您已经学习了 HADR 的概念，现在可以学习如何设置 HADR 环境。

使用另一个数据库服务器 server2.torolab.ibm.com 作为备用服务器。TEST1 当前不在备用服务器上。

服务名	实例名	SVCENAME 或端口号	数据库名
server1.torolab.ibm.com	DB2INST1	50000	TEST1
server2.torolab.ibm.com	DB2INST1	50000	--

第一次初始化 HADR 时，执行图 13 所示的五个步骤：

确定主服务器和备用服务器。决定主机名、主机 IP 地址和每个 HADR 数据库的服务名或端口号。
您已经确定了主服务器和备用服务器。主服务器是 server1。备用服务器是 server2。

确保这两个服务器是通过 TCPIP 相互通信的。尝试用主机名在这两个服务器上相互 ping 对方。应确保输出没有错误。如果主机名不能使用，那么尝试使用它们的 TCPIP 地址。选用两者中最好用的一种用于 HADR 配置。

通过克隆主数据库创建备用数据库。

有两种方案可用于克隆主数据库：

一种方案是为主数据库做一个备份，并在备用数据库上恢复这个数据库备份。这种方案使用标准备份和恢复方法。
克隆主数据库的另一种方案是使用分割镜像。为主数据库做一个分割镜像，然后在备用服务器上初始化该分割镜像。当初始化分割镜像时，必须在 db2inidb 命令中使用 standby 选项，以便使用 mirror 和 snapshot 选项。

在这个例子种，使用备份/恢复方法来创建备用数据库。

首先为 server1 上的主数据库 TEST1 做一个备份：

BACKUP DB test1

接着，通过 ftp 将备份镜像传送到备用服务器，并恢复该备份镜像。

将备份镜像恢复到与主服务器上相同的位置。在主服务器上，发出 LIST DB DIRECTORY 命令将显示：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            =
 Alternate server port number         =

数据库位于主服务器上的 C: 盘上。当在备用服务器上恢复备份镜像时，也将它恢复到 C: 盘。在备用服务器 server2 上，发出以下命令来恢复 TEST1 数据库：

RESTORE DB test1 ON C:

在主数据库和备用数据库上设置以下 HADR 配置参数：

HADR_LOCAL_HOST
HADR_LOCAL_SVC
HADR_REMOTE_HOST
HADR_REMOTE_SVC
HADR_REMOTE_INST
HADR_SYNCMODE
LOGINDEXBUILD

在主服务器上，为 HADR 使用端口号 70000。更新 Windows\System32\drivers\etc\services 文件，在其中添加以下一行：

Hadr_port 	70000/tcp

在备用服务器上的 services 文件中添加以下一行：

Hadr_port 	80000/tcp

为 HADR_SYNCMODE 使用默认值，即 NEARSYNC。

您已经有了配置 HADR 参数所需的所有信息。发出以下命令来配置备用服务器上的参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在主数据库服务器上，配置相同的一组参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在备用数据库上使用 START HADR 命令启动 HADR：
START HADR ON DB test1 AS STANDBY
在启动主数据库之前启动备用数据库。如果先启动主数据库，那么，如果没有在 HADR_TIMEOUT 数据库配置参数指定的期限内启动备用数据库，那么主数据库的启动过程就会失败。
在主数据库上启动 HADR，如下面的例子所示：
START HADR ON DB test1 AS PRIMARY
HADR 现在已经在主数据库和备用数据库上启动了。

当第一次启动主服务器时，它等待备用服务器与它联系。如果在指定期限内备用服务器没有与主服务器联系，那么 HADR 将不启动。这个期限可以用 HADR_TIMEOUT 配置参数（见表 1）来配置。这样做的目的是避免两个系统在偶然的情况下与主服务器同时启动。

在 HADR 启动过程中，数据库经历以下状态：local catch-up、remote catch-up pending、remote catch-up 和对等状态。日志被自动从主服务器传送到备用服务器，然后在备用服务器上重演。这是为了确保备用数据库跟上主数据库的变化。

强烈建议在主数据库和备用数据库所在的系统上使用相同的数据库配置参数和数据库管理器配置参数。否则，备用数据库就不会像主数据库一样执行。

一个例外是 LOGFILSIZ 数据库配置参数。这个参数的值被备用服务器所忽略。备用服务器自动创建与主数据库上的日志文件大小相匹配的日志文件。这保证了两个数据库上的日志文件是一致的。

在主数据库与备用数据库之间切换数据库角色，也就是说，备用数据库变成主数据库，主数据库变成备用数据库。
从主数据库故障转移到备用数据库。

   GET SNAPSHOT FOR DATABASE ON test1

下面的命令在备用数据库 TEST1 上开始 HADR 数据库切换角色操作：

   TAKEOVER HADR ON DB test1

故障转移方案不切换数据库角色。在故障转移操作期间，备用数据库接管主数据库角色，但是主数据库不会变成备用数据库。

下面的命令在数据库 TEST1 上开始一个 HADR 故障转移操作：

   TAKEOVER HADR ON DB test1 BY FORCE

表 3 和 4 总结了在备用数据库上发出的 TAKEOVER HADR 命令的行为，以及备用数据库所处的对应的 HADR 状态：

备用数据库的状态	接管行为
对等	主数据库和备用数据库都切换角色
Local catch-up or remote catch-up	错误
Remote catch-up pending	错误

备用数据库的状态	接管行为
对等	备用数据库通知主数据库关闭。备用数据库停止接收来自主数据库的日志，完成它已经收到的日志的重演，然后变成主数据库。备用数据库不用等到主数据库发来通知确认它受到接管通知或者它已经关闭
Local catch-up OR remote catch-up	错误
Remote catch-up pending	备用数据库变成主数据库

您已经看到了如何设置 HADR 环境，以及如何使用数据库角色切换和故障转移方案执行接管。

您学习了如何使用 HADR 使数据库具有高可用性。如果主数据库停机，那么它的备用数据库将接管，并成为新的主数据库。

为了启用自动客户机重路由特性，在主数据库上发出 UPDATE ALTERNATE SERVER 命令。该命令的语法如下：

UPDATE ALTERNATE SERVER FOR DATABASE database-alias
USING HOSTNAME alternate-server-hostname PORT port-number

为了在 server1 上的 TEST1 数据库上启用客户机重路由特性，以便在接管之后已有的和新的客户机连接被重新路由到 server2，在 server1 上发出以下命令：

UPDATE ALTERNATE SERVER FOR DATABASE test1 USING 
HOSTNAME server2.torolab.ibm.com PORT 50000

在这个例子中，50000 是 SVCENAME 端口，而不是 HADR 端口。

备用服务器信息存储在 server1 的数据库目录中。如果发出一个 LIST DB DIRECTORY 命令，那么可以注意到备用服务器信息（主机名和端口号）已经被添加：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

现在让我们来看一个关于如何在启用了自动客户机重路由特性的数据库上执行接管的例子。

在这个例子中，不带 BY FORCE 选项执行一个接管。

首先，建立到 server1 上的 TEST1 数据库的一个远程客户机连接。为此，只需在一个远程 DB2 客户机上发出一条 CONNECT TO DATABASE 命令：

CONNECT TO DB test1 USER user1

为了建立那样的连接，客户机必须已经被配置为连接到 server1。关于如何配置远程客户机连接的信息，请参考本系列中的第一篇教程。

在建立连接之后，主服务器上的备用服务器信息被获取并存储在客户机的数据库目录中：

 Database alias                       = TEST1
 Database name                        = TEST1
 Node name                            = server1
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Remote
 Catalog database partition number    = -1
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

确保该连接已成功建立，并且可以查询 TEST1 数据库。在 server1 上发出一条 LIST APPLICATION 命令，它应该显示数据库 TEST1 上的远程客户机连接：

D:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      8          9.26.94.149.24336.060601000305
                                                         TEST1    1

接着，在 TEST1 数据库上执行接管。在备用服务器 server2 上发出以下命令：

TAKEOVER HADR ON DB test1

让我们看看这次接管完成后远程客户机连接有什么变化。

再次尝试从客户机查询 TEST1 数据库。对 TEST1 数据库的任何查询应该都会返回一个错误消息。例如，从客户机连接发出一条 LIST TABLES 命令：

D:\Programs\IBM\SQLLIB\BIN>db2 list tables
SQL30108N A connection failed but has been re-established. 
The hostname or IP address is "server2" and the service name or port number is "50000". 
Special registers may or may not be re-attempted (Reason code = "1").  
SQLSTATE=08506

这证明客户机重路由特性在起作用。现在您已经连接到新的主服务器，即 server2。

在 server2 上发出一条 LIST APPLICATIONS 命令。您可以看到，远程客户机连接已经被重新路由到那里：

H:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      55         9.26.94.149.29200.060601001803
                                                         TEST1    1

如果再次查询数据库，那么可以从新的主服务器得到一个响应。而且，到原来主服务器的新连接也被重新路由到新的主服务器。

使用 GET SNAPSHOT 命令可以获得数据库的 HADR 状态。在 server2 上发出以下命令，应该可以看到 server2 已经接管了主数据库角色：

db2 "get snapshot for database on test1"

  HADR Status
  Role                   = Primary
  State                  = Peer
  Synchronization mode   = Nearsync
  Connection status      = Connected , 05/31/2006 20:17:24.989618
  Heartbeats missed      = 0
  Local host             = server2.torolab.ibm.com
  Local service          = 80000
  Remote host            = server1.torolab.ibm.com
  Remote service         = 70000
  Remote instance        = db2inst1
  timeout(seconds)       = 120
  Primary log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Standby log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Log gap running average(bytes) = 0

在执行接管操作之后，如果出故障的数据库又可以使用，它不会自动恢复主数据库的角色。

通过以下步骤可以使之重新成为主数据库：

修复原来的主数据库所在的系统。这包括修复有问题的硬件或者重新启动崩溃的操作系统。
重新启动出故障的主数据库，使之成为一个备用数据库。
执行一个接管操作，使之接管主数据库的角色。

当原来的主数据库重新以备用数据库的角色加入 HADR 对之后，执行一个接管操作来切换数据库的角色，使原来的主数据库再次成为主数据库。

为了停止 TEST1 数据库上的 HADR，发出：

STOP HADR ON DB test1

您可以看到，HADR 是实现高可用性解决方案的一个强大的特性。提供了一个名为 HADR 向导的图形化用户界面工具，以帮助您设置和配置 HADR。

如果选择 Set Up，那么就会打开一个如图 15 所示的逐步向导。

如果使用 Control Center 设置 HADR 环境，则会自动启用自动客户机重路由特性。

阅读(23814) | 评论(0) | 转发(0) |

上一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（4）

下一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（6）

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

16024965号-6

高可用性灾难恢复（HADR）

DB2 高可用性灾难恢复（HADR）是一种数据库复制特性，它提供了一种高可用性解决方案。目前，HADR 只用于单分区数据库环境。

为了设置 HADR 环境，要更新一些数据库配置参数。

首先，必须启用主数据库上的归档日志记录。请参阅备份和恢复教程，以了解如何启用归档日志记录。

表 1 列出了与 HADR 相关的数据库配置参数的描述。本教程后面将给出一个关于如何更新这些参数的例子。

与 HADR 相关的数据库配置参数	描述
HADR_LOCAL_HOST	指定 HADR TCPIP 通信的本地主机。主机名和 IP 地址都可以使用
HADR_LOCAL_SVC	指定 TCPIP 服务名和端口号，HADR 进程将在本地主机上接受该服务或端口的连接。这个端口不能与 HADR 实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_HOST	指定远程 HADR 节点的 TCPIP 主机名或 IP 地址
HADR_REMOTE_SVC	指定 TCPIP 服务名或端口号，HADR 进程将在远程节点上接受该服务或端口的连接。这个端口不能与远程实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_INST	指定远程服务器的实例名。DB2 Control Center 之类的管理工具将使用这个参数与远程服务器联系
HADR_TIMEOUT	HADR 进程在认为一次通信尝试失败之前所等待的时间（以秒为单位）。默认值为 120 秒
HADR_SYNCMODE	指定同步模式。它决定当系统处于对等状态时，主日志写与备用数据库如何同步。有效值有 SYNC、NEARSYNC 和 ASYNC。默认值为 NEARSYNC。（本节后面将讨论对等状态）。
HADR_DB_ROLE	指定一个数据库当前的角色。有效值有 STANDARD、PRIMARY 和 STANDBY。STANDARD 意味着数据库没有启用 HADR。

当备用数据库第一次启动时，它进入 local catch-up 状态。本地日志路径中的日志文件（如果有的话）将被读取，并应用到备用数据库。

当到达本地日志文件的最后时，备用数据库进入 remote catch-up 状态。它重演主数据库的归档日志和活动日志，直到备用数据库应用了最近的活动日志。

当主系统上的所有日志文件都已经被重演时，主数据库和备用数据库就进入对等（peer）状态。

在同步模式中，日志写只有在以下情况下才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库的日志文件中。

主数据库与备用数据库中的日志记录几乎（或近似）是同步的，因为只有在以下情况下，日志写才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库上的主存中。

在这种模式下，主数据库不等待收到备用数据库的通知。只有在以下情况下，日志写才被认为是成功的：

日志记录已经被写到主数据库上的日志文件中。
日志记录已经被传送到备用数据库；不需要通知。

HADR 是通过以下三个简单的命令来管理的：

START HADR
STOP HADR
TAKENOVER HADR

这些命令的语法如下：

START HADR ON DATABASE database-alias
[USER userid] [USING password] 
AS PRIMARY | STANDBY [BY FORCE]

STOP HADR ON DATABASE database-alias 
[USER userid] [USING password] 

TAKEOVER HADR ON DATABASE database-alias
[USER userid] [USING password] 
[BY FORCE]

您已经学习了 HADR 的概念，现在可以学习如何设置 HADR 环境。

使用另一个数据库服务器 server2.torolab.ibm.com 作为备用服务器。TEST1 当前不在备用服务器上。

服务名	实例名	SVCENAME 或端口号	数据库名
server1.torolab.ibm.com	DB2INST1	50000	TEST1
server2.torolab.ibm.com	DB2INST1	50000	--

第一次初始化 HADR 时，执行图 13 所示的五个步骤：

确定主服务器和备用服务器。决定主机名、主机 IP 地址和每个 HADR 数据库的服务名或端口号。
您已经确定了主服务器和备用服务器。主服务器是 server1。备用服务器是 server2。

确保这两个服务器是通过 TCPIP 相互通信的。尝试用主机名在这两个服务器上相互 ping 对方。应确保输出没有错误。如果主机名不能使用，那么尝试使用它们的 TCPIP 地址。选用两者中最好用的一种用于 HADR 配置。

通过克隆主数据库创建备用数据库。

有两种方案可用于克隆主数据库：

一种方案是为主数据库做一个备份，并在备用数据库上恢复这个数据库备份。这种方案使用标准备份和恢复方法。
克隆主数据库的另一种方案是使用分割镜像。为主数据库做一个分割镜像，然后在备用服务器上初始化该分割镜像。当初始化分割镜像时，必须在 db2inidb 命令中使用 standby 选项，以便使用 mirror 和 snapshot 选项。

在这个例子种，使用备份/恢复方法来创建备用数据库。

首先为 server1 上的主数据库 TEST1 做一个备份：

BACKUP DB test1

接着，通过 ftp 将备份镜像传送到备用服务器，并恢复该备份镜像。

将备份镜像恢复到与主服务器上相同的位置。在主服务器上，发出 LIST DB DIRECTORY 命令将显示：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            =
 Alternate server port number         =

数据库位于主服务器上的 C: 盘上。当在备用服务器上恢复备份镜像时，也将它恢复到 C: 盘。在备用服务器 server2 上，发出以下命令来恢复 TEST1 数据库：

RESTORE DB test1 ON C:

在主数据库和备用数据库上设置以下 HADR 配置参数：

HADR_LOCAL_HOST
HADR_LOCAL_SVC
HADR_REMOTE_HOST
HADR_REMOTE_SVC
HADR_REMOTE_INST
HADR_SYNCMODE
LOGINDEXBUILD

在主服务器上，为 HADR 使用端口号 70000。更新 Windows\System32\drivers\etc\services 文件，在其中添加以下一行：

Hadr_port 	70000/tcp

在备用服务器上的 services 文件中添加以下一行：

Hadr_port 	80000/tcp

为 HADR_SYNCMODE 使用默认值，即 NEARSYNC。

您已经有了配置 HADR 参数所需的所有信息。发出以下命令来配置备用服务器上的参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在主数据库服务器上，配置相同的一组参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在备用数据库上使用 START HADR 命令启动 HADR：
START HADR ON DB test1 AS STANDBY
在启动主数据库之前启动备用数据库。如果先启动主数据库，那么，如果没有在 HADR_TIMEOUT 数据库配置参数指定的期限内启动备用数据库，那么主数据库的启动过程就会失败。
在主数据库上启动 HADR，如下面的例子所示：
START HADR ON DB test1 AS PRIMARY
HADR 现在已经在主数据库和备用数据库上启动了。

当第一次启动主服务器时，它等待备用服务器与它联系。如果在指定期限内备用服务器没有与主服务器联系，那么 HADR 将不启动。这个期限可以用 HADR_TIMEOUT 配置参数（见表 1）来配置。这样做的目的是避免两个系统在偶然的情况下与主服务器同时启动。

在 HADR 启动过程中，数据库经历以下状态：local catch-up、remote catch-up pending、remote catch-up 和对等状态。日志被自动从主服务器传送到备用服务器，然后在备用服务器上重演。这是为了确保备用数据库跟上主数据库的变化。

强烈建议在主数据库和备用数据库所在的系统上使用相同的数据库配置参数和数据库管理器配置参数。否则，备用数据库就不会像主数据库一样执行。

一个例外是 LOGFILSIZ 数据库配置参数。这个参数的值被备用服务器所忽略。备用服务器自动创建与主数据库上的日志文件大小相匹配的日志文件。这保证了两个数据库上的日志文件是一致的。

在主数据库与备用数据库之间切换数据库角色，也就是说，备用数据库变成主数据库，主数据库变成备用数据库。
从主数据库故障转移到备用数据库。

   GET SNAPSHOT FOR DATABASE ON test1

下面的命令在备用数据库 TEST1 上开始 HADR 数据库切换角色操作：

   TAKEOVER HADR ON DB test1

故障转移方案不切换数据库角色。在故障转移操作期间，备用数据库接管主数据库角色，但是主数据库不会变成备用数据库。

下面的命令在数据库 TEST1 上开始一个 HADR 故障转移操作：

   TAKEOVER HADR ON DB test1 BY FORCE

表 3 和 4 总结了在备用数据库上发出的 TAKEOVER HADR 命令的行为，以及备用数据库所处的对应的 HADR 状态：

备用数据库的状态	接管行为
对等	主数据库和备用数据库都切换角色
Local catch-up or remote catch-up	错误
Remote catch-up pending	错误

备用数据库的状态	接管行为
对等	备用数据库通知主数据库关闭。备用数据库停止接收来自主数据库的日志，完成它已经收到的日志的重演，然后变成主数据库。备用数据库不用等到主数据库发来通知确认它受到接管通知或者它已经关闭
Local catch-up OR remote catch-up	错误
Remote catch-up pending	备用数据库变成主数据库

您已经看到了如何设置 HADR 环境，以及如何使用数据库角色切换和故障转移方案执行接管。

您学习了如何使用 HADR 使数据库具有高可用性。如果主数据库停机，那么它的备用数据库将接管，并成为新的主数据库。

为了启用自动客户机重路由特性，在主数据库上发出 UPDATE ALTERNATE SERVER 命令。该命令的语法如下：

UPDATE ALTERNATE SERVER FOR DATABASE database-alias
USING HOSTNAME alternate-server-hostname PORT port-number

为了在 server1 上的 TEST1 数据库上启用客户机重路由特性，以便在接管之后已有的和新的客户机连接被重新路由到 server2，在 server1 上发出以下命令：

UPDATE ALTERNATE SERVER FOR DATABASE test1 USING 
HOSTNAME server2.torolab.ibm.com PORT 50000

在这个例子中，50000 是 SVCENAME 端口，而不是 HADR 端口。

备用服务器信息存储在 server1 的数据库目录中。如果发出一个 LIST DB DIRECTORY 命令，那么可以注意到备用服务器信息（主机名和端口号）已经被添加：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

现在让我们来看一个关于如何在启用了自动客户机重路由特性的数据库上执行接管的例子。

在这个例子中，不带 BY FORCE 选项执行一个接管。

首先，建立到 server1 上的 TEST1 数据库的一个远程客户机连接。为此，只需在一个远程 DB2 客户机上发出一条 CONNECT TO DATABASE 命令：

CONNECT TO DB test1 USER user1

为了建立那样的连接，客户机必须已经被配置为连接到 server1。关于如何配置远程客户机连接的信息，请参考本系列中的第一篇教程。

在建立连接之后，主服务器上的备用服务器信息被获取并存储在客户机的数据库目录中：

 Database alias                       = TEST1
 Database name                        = TEST1
 Node name                            = server1
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Remote
 Catalog database partition number    = -1
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

确保该连接已成功建立，并且可以查询 TEST1 数据库。在 server1 上发出一条 LIST APPLICATION 命令，它应该显示数据库 TEST1 上的远程客户机连接：

D:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      8          9.26.94.149.24336.060601000305
                                                         TEST1    1

接着，在 TEST1 数据库上执行接管。在备用服务器 server2 上发出以下命令：

TAKEOVER HADR ON DB test1

让我们看看这次接管完成后远程客户机连接有什么变化。

再次尝试从客户机查询 TEST1 数据库。对 TEST1 数据库的任何查询应该都会返回一个错误消息。例如，从客户机连接发出一条 LIST TABLES 命令：

D:\Programs\IBM\SQLLIB\BIN>db2 list tables
SQL30108N A connection failed but has been re-established. 
The hostname or IP address is "server2" and the service name or port number is "50000". 
Special registers may or may not be re-attempted (Reason code = "1").  
SQLSTATE=08506

这证明客户机重路由特性在起作用。现在您已经连接到新的主服务器，即 server2。

在 server2 上发出一条 LIST APPLICATIONS 命令。您可以看到，远程客户机连接已经被重新路由到那里：

H:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      55         9.26.94.149.29200.060601001803
                                                         TEST1    1

如果再次查询数据库，那么可以从新的主服务器得到一个响应。而且，到原来主服务器的新连接也被重新路由到新的主服务器。

使用 GET SNAPSHOT 命令可以获得数据库的 HADR 状态。在 server2 上发出以下命令，应该可以看到 server2 已经接管了主数据库角色：

db2 "get snapshot for database on test1"

  HADR Status
  Role                   = Primary
  State                  = Peer
  Synchronization mode   = Nearsync
  Connection status      = Connected , 05/31/2006 20:17:24.989618
  Heartbeats missed      = 0
  Local host             = server2.torolab.ibm.com
  Local service          = 80000
  Remote host            = server1.torolab.ibm.com
  Remote service         = 70000
  Remote instance        = db2inst1
  timeout(seconds)       = 120
  Primary log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Standby log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Log gap running average(bytes) = 0

在执行接管操作之后，如果出故障的数据库又可以使用，它不会自动恢复主数据库的角色。

通过以下步骤可以使之重新成为主数据库：

修复原来的主数据库所在的系统。这包括修复有问题的硬件或者重新启动崩溃的操作系统。
重新启动出故障的主数据库，使之成为一个备用数据库。
执行一个接管操作，使之接管主数据库的角色。

当原来的主数据库重新以备用数据库的角色加入 HADR 对之后，执行一个接管操作来切换数据库的角色，使原来的主数据库再次成为主数据库。

为了停止 TEST1 数据库上的 HADR，发出：

STOP HADR ON DB test1

您可以看到，HADR 是实现高可用性解决方案的一个强大的特性。提供了一个名为 HADR 向导的图形化用户界面工具，以帮助您设置和配置 HADR。

如果选择 Set Up，那么就会打开一个如图 15 所示的逐步向导。

如果使用 Control Center 设置 HADR 环境，则会自动启用自动客户机重路由特性。

阅读(23813) | 评论(0) | 转发(0) |

上一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（4）

下一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（6）

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

16024965号-6

高可用性灾难恢复（HADR）

DB2 高可用性灾难恢复（HADR）是一种数据库复制特性，它提供了一种高可用性解决方案。目前，HADR 只用于单分区数据库环境。

为了设置 HADR 环境，要更新一些数据库配置参数。

首先，必须启用主数据库上的归档日志记录。请参阅备份和恢复教程，以了解如何启用归档日志记录。

表 1 列出了与 HADR 相关的数据库配置参数的描述。本教程后面将给出一个关于如何更新这些参数的例子。

与 HADR 相关的数据库配置参数	描述
HADR_LOCAL_HOST	指定 HADR TCPIP 通信的本地主机。主机名和 IP 地址都可以使用
HADR_LOCAL_SVC	指定 TCPIP 服务名和端口号，HADR 进程将在本地主机上接受该服务或端口的连接。这个端口不能与 HADR 实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_HOST	指定远程 HADR 节点的 TCPIP 主机名或 IP 地址
HADR_REMOTE_SVC	指定 TCPIP 服务名或端口号，HADR 进程将在远程节点上接受该服务或端口的连接。这个端口不能与远程实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_INST	指定远程服务器的实例名。DB2 Control Center 之类的管理工具将使用这个参数与远程服务器联系
HADR_TIMEOUT	HADR 进程在认为一次通信尝试失败之前所等待的时间（以秒为单位）。默认值为 120 秒
HADR_SYNCMODE	指定同步模式。它决定当系统处于对等状态时，主日志写与备用数据库如何同步。有效值有 SYNC、NEARSYNC 和 ASYNC。默认值为 NEARSYNC。（本节后面将讨论对等状态）。
HADR_DB_ROLE	指定一个数据库当前的角色。有效值有 STANDARD、PRIMARY 和 STANDBY。STANDARD 意味着数据库没有启用 HADR。

当备用数据库第一次启动时，它进入 local catch-up 状态。本地日志路径中的日志文件（如果有的话）将被读取，并应用到备用数据库。

当到达本地日志文件的最后时，备用数据库进入 remote catch-up 状态。它重演主数据库的归档日志和活动日志，直到备用数据库应用了最近的活动日志。

当主系统上的所有日志文件都已经被重演时，主数据库和备用数据库就进入对等（peer）状态。

在同步模式中，日志写只有在以下情况下才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库的日志文件中。

主数据库与备用数据库中的日志记录几乎（或近似）是同步的，因为只有在以下情况下，日志写才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库上的主存中。

在这种模式下，主数据库不等待收到备用数据库的通知。只有在以下情况下，日志写才被认为是成功的：

日志记录已经被写到主数据库上的日志文件中。
日志记录已经被传送到备用数据库；不需要通知。

HADR 是通过以下三个简单的命令来管理的：

START HADR
STOP HADR
TAKENOVER HADR

这些命令的语法如下：

START HADR ON DATABASE database-alias
[USER userid] [USING password] 
AS PRIMARY | STANDBY [BY FORCE]

STOP HADR ON DATABASE database-alias 
[USER userid] [USING password] 

TAKEOVER HADR ON DATABASE database-alias
[USER userid] [USING password] 
[BY FORCE]

您已经学习了 HADR 的概念，现在可以学习如何设置 HADR 环境。

使用另一个数据库服务器 server2.torolab.ibm.com 作为备用服务器。TEST1 当前不在备用服务器上。

服务名	实例名	SVCENAME 或端口号	数据库名
server1.torolab.ibm.com	DB2INST1	50000	TEST1
server2.torolab.ibm.com	DB2INST1	50000	--

第一次初始化 HADR 时，执行图 13 所示的五个步骤：

确定主服务器和备用服务器。决定主机名、主机 IP 地址和每个 HADR 数据库的服务名或端口号。
您已经确定了主服务器和备用服务器。主服务器是 server1。备用服务器是 server2。

确保这两个服务器是通过 TCPIP 相互通信的。尝试用主机名在这两个服务器上相互 ping 对方。应确保输出没有错误。如果主机名不能使用，那么尝试使用它们的 TCPIP 地址。选用两者中最好用的一种用于 HADR 配置。

通过克隆主数据库创建备用数据库。

有两种方案可用于克隆主数据库：

一种方案是为主数据库做一个备份，并在备用数据库上恢复这个数据库备份。这种方案使用标准备份和恢复方法。
克隆主数据库的另一种方案是使用分割镜像。为主数据库做一个分割镜像，然后在备用服务器上初始化该分割镜像。当初始化分割镜像时，必须在 db2inidb 命令中使用 standby 选项，以便使用 mirror 和 snapshot 选项。

在这个例子种，使用备份/恢复方法来创建备用数据库。

首先为 server1 上的主数据库 TEST1 做一个备份：

BACKUP DB test1

接着，通过 ftp 将备份镜像传送到备用服务器，并恢复该备份镜像。

将备份镜像恢复到与主服务器上相同的位置。在主服务器上，发出 LIST DB DIRECTORY 命令将显示：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            =
 Alternate server port number         =

数据库位于主服务器上的 C: 盘上。当在备用服务器上恢复备份镜像时，也将它恢复到 C: 盘。在备用服务器 server2 上，发出以下命令来恢复 TEST1 数据库：

RESTORE DB test1 ON C:

在主数据库和备用数据库上设置以下 HADR 配置参数：

HADR_LOCAL_HOST
HADR_LOCAL_SVC
HADR_REMOTE_HOST
HADR_REMOTE_SVC
HADR_REMOTE_INST
HADR_SYNCMODE
LOGINDEXBUILD

在主服务器上，为 HADR 使用端口号 70000。更新 Windows\System32\drivers\etc\services 文件，在其中添加以下一行：

Hadr_port 	70000/tcp

在备用服务器上的 services 文件中添加以下一行：

Hadr_port 	80000/tcp

为 HADR_SYNCMODE 使用默认值，即 NEARSYNC。

您已经有了配置 HADR 参数所需的所有信息。发出以下命令来配置备用服务器上的参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在主数据库服务器上，配置相同的一组参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在备用数据库上使用 START HADR 命令启动 HADR：
START HADR ON DB test1 AS STANDBY
在启动主数据库之前启动备用数据库。如果先启动主数据库，那么，如果没有在 HADR_TIMEOUT 数据库配置参数指定的期限内启动备用数据库，那么主数据库的启动过程就会失败。
在主数据库上启动 HADR，如下面的例子所示：
START HADR ON DB test1 AS PRIMARY
HADR 现在已经在主数据库和备用数据库上启动了。

当第一次启动主服务器时，它等待备用服务器与它联系。如果在指定期限内备用服务器没有与主服务器联系，那么 HADR 将不启动。这个期限可以用 HADR_TIMEOUT 配置参数（见表 1）来配置。这样做的目的是避免两个系统在偶然的情况下与主服务器同时启动。

在 HADR 启动过程中，数据库经历以下状态：local catch-up、remote catch-up pending、remote catch-up 和对等状态。日志被自动从主服务器传送到备用服务器，然后在备用服务器上重演。这是为了确保备用数据库跟上主数据库的变化。

强烈建议在主数据库和备用数据库所在的系统上使用相同的数据库配置参数和数据库管理器配置参数。否则，备用数据库就不会像主数据库一样执行。

一个例外是 LOGFILSIZ 数据库配置参数。这个参数的值被备用服务器所忽略。备用服务器自动创建与主数据库上的日志文件大小相匹配的日志文件。这保证了两个数据库上的日志文件是一致的。

在主数据库与备用数据库之间切换数据库角色，也就是说，备用数据库变成主数据库，主数据库变成备用数据库。
从主数据库故障转移到备用数据库。

   GET SNAPSHOT FOR DATABASE ON test1

下面的命令在备用数据库 TEST1 上开始 HADR 数据库切换角色操作：

   TAKEOVER HADR ON DB test1

故障转移方案不切换数据库角色。在故障转移操作期间，备用数据库接管主数据库角色，但是主数据库不会变成备用数据库。

下面的命令在数据库 TEST1 上开始一个 HADR 故障转移操作：

   TAKEOVER HADR ON DB test1 BY FORCE

表 3 和 4 总结了在备用数据库上发出的 TAKEOVER HADR 命令的行为，以及备用数据库所处的对应的 HADR 状态：

备用数据库的状态	接管行为
对等	主数据库和备用数据库都切换角色
Local catch-up or remote catch-up	错误
Remote catch-up pending	错误

备用数据库的状态	接管行为
对等	备用数据库通知主数据库关闭。备用数据库停止接收来自主数据库的日志，完成它已经收到的日志的重演，然后变成主数据库。备用数据库不用等到主数据库发来通知确认它受到接管通知或者它已经关闭
Local catch-up OR remote catch-up	错误
Remote catch-up pending	备用数据库变成主数据库

您已经看到了如何设置 HADR 环境，以及如何使用数据库角色切换和故障转移方案执行接管。

您学习了如何使用 HADR 使数据库具有高可用性。如果主数据库停机，那么它的备用数据库将接管，并成为新的主数据库。

为了启用自动客户机重路由特性，在主数据库上发出 UPDATE ALTERNATE SERVER 命令。该命令的语法如下：

UPDATE ALTERNATE SERVER FOR DATABASE database-alias
USING HOSTNAME alternate-server-hostname PORT port-number

为了在 server1 上的 TEST1 数据库上启用客户机重路由特性，以便在接管之后已有的和新的客户机连接被重新路由到 server2，在 server1 上发出以下命令：

UPDATE ALTERNATE SERVER FOR DATABASE test1 USING 
HOSTNAME server2.torolab.ibm.com PORT 50000

在这个例子中，50000 是 SVCENAME 端口，而不是 HADR 端口。

备用服务器信息存储在 server1 的数据库目录中。如果发出一个 LIST DB DIRECTORY 命令，那么可以注意到备用服务器信息（主机名和端口号）已经被添加：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

现在让我们来看一个关于如何在启用了自动客户机重路由特性的数据库上执行接管的例子。

在这个例子中，不带 BY FORCE 选项执行一个接管。

首先，建立到 server1 上的 TEST1 数据库的一个远程客户机连接。为此，只需在一个远程 DB2 客户机上发出一条 CONNECT TO DATABASE 命令：

CONNECT TO DB test1 USER user1

为了建立那样的连接，客户机必须已经被配置为连接到 server1。关于如何配置远程客户机连接的信息，请参考本系列中的第一篇教程。

在建立连接之后，主服务器上的备用服务器信息被获取并存储在客户机的数据库目录中：

 Database alias                       = TEST1
 Database name                        = TEST1
 Node name                            = server1
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Remote
 Catalog database partition number    = -1
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

确保该连接已成功建立，并且可以查询 TEST1 数据库。在 server1 上发出一条 LIST APPLICATION 命令，它应该显示数据库 TEST1 上的远程客户机连接：

D:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      8          9.26.94.149.24336.060601000305
                                                         TEST1    1

接着，在 TEST1 数据库上执行接管。在备用服务器 server2 上发出以下命令：

TAKEOVER HADR ON DB test1

让我们看看这次接管完成后远程客户机连接有什么变化。

再次尝试从客户机查询 TEST1 数据库。对 TEST1 数据库的任何查询应该都会返回一个错误消息。例如，从客户机连接发出一条 LIST TABLES 命令：

D:\Programs\IBM\SQLLIB\BIN>db2 list tables
SQL30108N A connection failed but has been re-established. 
The hostname or IP address is "server2" and the service name or port number is "50000". 
Special registers may or may not be re-attempted (Reason code = "1").  
SQLSTATE=08506

这证明客户机重路由特性在起作用。现在您已经连接到新的主服务器，即 server2。

在 server2 上发出一条 LIST APPLICATIONS 命令。您可以看到，远程客户机连接已经被重新路由到那里：

H:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      55         9.26.94.149.29200.060601001803
                                                         TEST1    1

如果再次查询数据库，那么可以从新的主服务器得到一个响应。而且，到原来主服务器的新连接也被重新路由到新的主服务器。

使用 GET SNAPSHOT 命令可以获得数据库的 HADR 状态。在 server2 上发出以下命令，应该可以看到 server2 已经接管了主数据库角色：

db2 "get snapshot for database on test1"

  HADR Status
  Role                   = Primary
  State                  = Peer
  Synchronization mode   = Nearsync
  Connection status      = Connected , 05/31/2006 20:17:24.989618
  Heartbeats missed      = 0
  Local host             = server2.torolab.ibm.com
  Local service          = 80000
  Remote host            = server1.torolab.ibm.com
  Remote service         = 70000
  Remote instance        = db2inst1
  timeout(seconds)       = 120
  Primary log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Standby log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Log gap running average(bytes) = 0

在执行接管操作之后，如果出故障的数据库又可以使用，它不会自动恢复主数据库的角色。

通过以下步骤可以使之重新成为主数据库：

修复原来的主数据库所在的系统。这包括修复有问题的硬件或者重新启动崩溃的操作系统。
重新启动出故障的主数据库，使之成为一个备用数据库。
执行一个接管操作，使之接管主数据库的角色。

当原来的主数据库重新以备用数据库的角色加入 HADR 对之后，执行一个接管操作来切换数据库的角色，使原来的主数据库再次成为主数据库。

为了停止 TEST1 数据库上的 HADR，发出：

STOP HADR ON DB test1

您可以看到，HADR 是实现高可用性解决方案的一个强大的特性。提供了一个名为 HADR 向导的图形化用户界面工具，以帮助您设置和配置 HADR。

如果选择 Set Up，那么就会打开一个如图 15 所示的逐步向导。

如果使用 Control Center 设置 HADR 环境，则会自动启用自动客户机重路由特性。

阅读(23812) | 评论(0) | 转发(0) |

上一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（4）

下一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（6）

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

16024965号-6

高可用性灾难恢复（HADR）

DB2 高可用性灾难恢复（HADR）是一种数据库复制特性，它提供了一种高可用性解决方案。目前，HADR 只用于单分区数据库环境。

为了设置 HADR 环境，要更新一些数据库配置参数。

首先，必须启用主数据库上的归档日志记录。请参阅备份和恢复教程，以了解如何启用归档日志记录。

表 1 列出了与 HADR 相关的数据库配置参数的描述。本教程后面将给出一个关于如何更新这些参数的例子。

与 HADR 相关的数据库配置参数	描述
HADR_LOCAL_HOST	指定 HADR TCPIP 通信的本地主机。主机名和 IP 地址都可以使用
HADR_LOCAL_SVC	指定 TCPIP 服务名和端口号，HADR 进程将在本地主机上接受该服务或端口的连接。这个端口不能与 HADR 实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_HOST	指定远程 HADR 节点的 TCPIP 主机名或 IP 地址
HADR_REMOTE_SVC	指定 TCPIP 服务名或端口号，HADR 进程将在远程节点上接受该服务或端口的连接。这个端口不能与远程实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_INST	指定远程服务器的实例名。DB2 Control Center 之类的管理工具将使用这个参数与远程服务器联系
HADR_TIMEOUT	HADR 进程在认为一次通信尝试失败之前所等待的时间（以秒为单位）。默认值为 120 秒
HADR_SYNCMODE	指定同步模式。它决定当系统处于对等状态时，主日志写与备用数据库如何同步。有效值有 SYNC、NEARSYNC 和 ASYNC。默认值为 NEARSYNC。（本节后面将讨论对等状态）。
HADR_DB_ROLE	指定一个数据库当前的角色。有效值有 STANDARD、PRIMARY 和 STANDBY。STANDARD 意味着数据库没有启用 HADR。

当备用数据库第一次启动时，它进入 local catch-up 状态。本地日志路径中的日志文件（如果有的话）将被读取，并应用到备用数据库。

当到达本地日志文件的最后时，备用数据库进入 remote catch-up 状态。它重演主数据库的归档日志和活动日志，直到备用数据库应用了最近的活动日志。

当主系统上的所有日志文件都已经被重演时，主数据库和备用数据库就进入对等（peer）状态。

在同步模式中，日志写只有在以下情况下才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库的日志文件中。

主数据库与备用数据库中的日志记录几乎（或近似）是同步的，因为只有在以下情况下，日志写才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库上的主存中。

在这种模式下，主数据库不等待收到备用数据库的通知。只有在以下情况下，日志写才被认为是成功的：

日志记录已经被写到主数据库上的日志文件中。
日志记录已经被传送到备用数据库；不需要通知。

HADR 是通过以下三个简单的命令来管理的：

START HADR
STOP HADR
TAKENOVER HADR

这些命令的语法如下：

START HADR ON DATABASE database-alias
[USER userid] [USING password] 
AS PRIMARY | STANDBY [BY FORCE]

STOP HADR ON DATABASE database-alias 
[USER userid] [USING password] 

TAKEOVER HADR ON DATABASE database-alias
[USER userid] [USING password] 
[BY FORCE]

您已经学习了 HADR 的概念，现在可以学习如何设置 HADR 环境。

使用另一个数据库服务器 server2.torolab.ibm.com 作为备用服务器。TEST1 当前不在备用服务器上。

服务名	实例名	SVCENAME 或端口号	数据库名
server1.torolab.ibm.com	DB2INST1	50000	TEST1
server2.torolab.ibm.com	DB2INST1	50000	--

第一次初始化 HADR 时，执行图 13 所示的五个步骤：

确定主服务器和备用服务器。决定主机名、主机 IP 地址和每个 HADR 数据库的服务名或端口号。
您已经确定了主服务器和备用服务器。主服务器是 server1。备用服务器是 server2。

确保这两个服务器是通过 TCPIP 相互通信的。尝试用主机名在这两个服务器上相互 ping 对方。应确保输出没有错误。如果主机名不能使用，那么尝试使用它们的 TCPIP 地址。选用两者中最好用的一种用于 HADR 配置。

通过克隆主数据库创建备用数据库。

有两种方案可用于克隆主数据库：

一种方案是为主数据库做一个备份，并在备用数据库上恢复这个数据库备份。这种方案使用标准备份和恢复方法。
克隆主数据库的另一种方案是使用分割镜像。为主数据库做一个分割镜像，然后在备用服务器上初始化该分割镜像。当初始化分割镜像时，必须在 db2inidb 命令中使用 standby 选项，以便使用 mirror 和 snapshot 选项。

在这个例子种，使用备份/恢复方法来创建备用数据库。

首先为 server1 上的主数据库 TEST1 做一个备份：

BACKUP DB test1

接着，通过 ftp 将备份镜像传送到备用服务器，并恢复该备份镜像。

将备份镜像恢复到与主服务器上相同的位置。在主服务器上，发出 LIST DB DIRECTORY 命令将显示：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            =
 Alternate server port number         =

数据库位于主服务器上的 C: 盘上。当在备用服务器上恢复备份镜像时，也将它恢复到 C: 盘。在备用服务器 server2 上，发出以下命令来恢复 TEST1 数据库：

RESTORE DB test1 ON C:

在主数据库和备用数据库上设置以下 HADR 配置参数：

HADR_LOCAL_HOST
HADR_LOCAL_SVC
HADR_REMOTE_HOST
HADR_REMOTE_SVC
HADR_REMOTE_INST
HADR_SYNCMODE
LOGINDEXBUILD

在主服务器上，为 HADR 使用端口号 70000。更新 Windows\System32\drivers\etc\services 文件，在其中添加以下一行：

Hadr_port 	70000/tcp

在备用服务器上的 services 文件中添加以下一行：

Hadr_port 	80000/tcp

为 HADR_SYNCMODE 使用默认值，即 NEARSYNC。

您已经有了配置 HADR 参数所需的所有信息。发出以下命令来配置备用服务器上的参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在主数据库服务器上，配置相同的一组参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在备用数据库上使用 START HADR 命令启动 HADR：
START HADR ON DB test1 AS STANDBY
在启动主数据库之前启动备用数据库。如果先启动主数据库，那么，如果没有在 HADR_TIMEOUT 数据库配置参数指定的期限内启动备用数据库，那么主数据库的启动过程就会失败。
在主数据库上启动 HADR，如下面的例子所示：
START HADR ON DB test1 AS PRIMARY
HADR 现在已经在主数据库和备用数据库上启动了。

当第一次启动主服务器时，它等待备用服务器与它联系。如果在指定期限内备用服务器没有与主服务器联系，那么 HADR 将不启动。这个期限可以用 HADR_TIMEOUT 配置参数（见表 1）来配置。这样做的目的是避免两个系统在偶然的情况下与主服务器同时启动。

在 HADR 启动过程中，数据库经历以下状态：local catch-up、remote catch-up pending、remote catch-up 和对等状态。日志被自动从主服务器传送到备用服务器，然后在备用服务器上重演。这是为了确保备用数据库跟上主数据库的变化。

强烈建议在主数据库和备用数据库所在的系统上使用相同的数据库配置参数和数据库管理器配置参数。否则，备用数据库就不会像主数据库一样执行。

一个例外是 LOGFILSIZ 数据库配置参数。这个参数的值被备用服务器所忽略。备用服务器自动创建与主数据库上的日志文件大小相匹配的日志文件。这保证了两个数据库上的日志文件是一致的。

在主数据库与备用数据库之间切换数据库角色，也就是说，备用数据库变成主数据库，主数据库变成备用数据库。
从主数据库故障转移到备用数据库。

   GET SNAPSHOT FOR DATABASE ON test1

下面的命令在备用数据库 TEST1 上开始 HADR 数据库切换角色操作：

   TAKEOVER HADR ON DB test1

故障转移方案不切换数据库角色。在故障转移操作期间，备用数据库接管主数据库角色，但是主数据库不会变成备用数据库。

下面的命令在数据库 TEST1 上开始一个 HADR 故障转移操作：

   TAKEOVER HADR ON DB test1 BY FORCE

表 3 和 4 总结了在备用数据库上发出的 TAKEOVER HADR 命令的行为，以及备用数据库所处的对应的 HADR 状态：

备用数据库的状态	接管行为
对等	主数据库和备用数据库都切换角色
Local catch-up or remote catch-up	错误
Remote catch-up pending	错误

备用数据库的状态	接管行为
对等	备用数据库通知主数据库关闭。备用数据库停止接收来自主数据库的日志，完成它已经收到的日志的重演，然后变成主数据库。备用数据库不用等到主数据库发来通知确认它受到接管通知或者它已经关闭
Local catch-up OR remote catch-up	错误
Remote catch-up pending	备用数据库变成主数据库

您已经看到了如何设置 HADR 环境，以及如何使用数据库角色切换和故障转移方案执行接管。

您学习了如何使用 HADR 使数据库具有高可用性。如果主数据库停机，那么它的备用数据库将接管，并成为新的主数据库。

为了启用自动客户机重路由特性，在主数据库上发出 UPDATE ALTERNATE SERVER 命令。该命令的语法如下：

UPDATE ALTERNATE SERVER FOR DATABASE database-alias
USING HOSTNAME alternate-server-hostname PORT port-number

为了在 server1 上的 TEST1 数据库上启用客户机重路由特性，以便在接管之后已有的和新的客户机连接被重新路由到 server2，在 server1 上发出以下命令：

UPDATE ALTERNATE SERVER FOR DATABASE test1 USING 
HOSTNAME server2.torolab.ibm.com PORT 50000

在这个例子中，50000 是 SVCENAME 端口，而不是 HADR 端口。

备用服务器信息存储在 server1 的数据库目录中。如果发出一个 LIST DB DIRECTORY 命令，那么可以注意到备用服务器信息（主机名和端口号）已经被添加：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

现在让我们来看一个关于如何在启用了自动客户机重路由特性的数据库上执行接管的例子。

在这个例子中，不带 BY FORCE 选项执行一个接管。

首先，建立到 server1 上的 TEST1 数据库的一个远程客户机连接。为此，只需在一个远程 DB2 客户机上发出一条 CONNECT TO DATABASE 命令：

CONNECT TO DB test1 USER user1

为了建立那样的连接，客户机必须已经被配置为连接到 server1。关于如何配置远程客户机连接的信息，请参考本系列中的第一篇教程。

在建立连接之后，主服务器上的备用服务器信息被获取并存储在客户机的数据库目录中：

 Database alias                       = TEST1
 Database name                        = TEST1
 Node name                            = server1
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Remote
 Catalog database partition number    = -1
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

确保该连接已成功建立，并且可以查询 TEST1 数据库。在 server1 上发出一条 LIST APPLICATION 命令，它应该显示数据库 TEST1 上的远程客户机连接：

D:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      8          9.26.94.149.24336.060601000305
                                                         TEST1    1

接着，在 TEST1 数据库上执行接管。在备用服务器 server2 上发出以下命令：

TAKEOVER HADR ON DB test1

让我们看看这次接管完成后远程客户机连接有什么变化。

再次尝试从客户机查询 TEST1 数据库。对 TEST1 数据库的任何查询应该都会返回一个错误消息。例如，从客户机连接发出一条 LIST TABLES 命令：

D:\Programs\IBM\SQLLIB\BIN>db2 list tables
SQL30108N A connection failed but has been re-established. 
The hostname or IP address is "server2" and the service name or port number is "50000". 
Special registers may or may not be re-attempted (Reason code = "1").  
SQLSTATE=08506

这证明客户机重路由特性在起作用。现在您已经连接到新的主服务器，即 server2。

在 server2 上发出一条 LIST APPLICATIONS 命令。您可以看到，远程客户机连接已经被重新路由到那里：

H:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      55         9.26.94.149.29200.060601001803
                                                         TEST1    1

如果再次查询数据库，那么可以从新的主服务器得到一个响应。而且，到原来主服务器的新连接也被重新路由到新的主服务器。

使用 GET SNAPSHOT 命令可以获得数据库的 HADR 状态。在 server2 上发出以下命令，应该可以看到 server2 已经接管了主数据库角色：

db2 "get snapshot for database on test1"

  HADR Status
  Role                   = Primary
  State                  = Peer
  Synchronization mode   = Nearsync
  Connection status      = Connected , 05/31/2006 20:17:24.989618
  Heartbeats missed      = 0
  Local host             = server2.torolab.ibm.com
  Local service          = 80000
  Remote host            = server1.torolab.ibm.com
  Remote service         = 70000
  Remote instance        = db2inst1
  timeout(seconds)       = 120
  Primary log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Standby log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Log gap running average(bytes) = 0

在执行接管操作之后，如果出故障的数据库又可以使用，它不会自动恢复主数据库的角色。

通过以下步骤可以使之重新成为主数据库：

修复原来的主数据库所在的系统。这包括修复有问题的硬件或者重新启动崩溃的操作系统。
重新启动出故障的主数据库，使之成为一个备用数据库。
执行一个接管操作，使之接管主数据库的角色。

当原来的主数据库重新以备用数据库的角色加入 HADR 对之后，执行一个接管操作来切换数据库的角色，使原来的主数据库再次成为主数据库。

为了停止 TEST1 数据库上的 HADR，发出：

STOP HADR ON DB test1

您可以看到，HADR 是实现高可用性解决方案的一个强大的特性。提供了一个名为 HADR 向导的图形化用户界面工具，以帮助您设置和配置 HADR。

如果选择 Set Up，那么就会打开一个如图 15 所示的逐步向导。

如果使用 Control Center 设置 HADR 环境，则会自动启用自动客户机重路由特性。

阅读(23811) | 评论(0) | 转发(0) |

上一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（4）

下一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（6）

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

16024965号-6

高可用性灾难恢复（HADR）

DB2 高可用性灾难恢复（HADR）是一种数据库复制特性，它提供了一种高可用性解决方案。目前，HADR 只用于单分区数据库环境。

为了设置 HADR 环境，要更新一些数据库配置参数。

首先，必须启用主数据库上的归档日志记录。请参阅备份和恢复教程，以了解如何启用归档日志记录。

表 1 列出了与 HADR 相关的数据库配置参数的描述。本教程后面将给出一个关于如何更新这些参数的例子。

与 HADR 相关的数据库配置参数	描述
HADR_LOCAL_HOST	指定 HADR TCPIP 通信的本地主机。主机名和 IP 地址都可以使用
HADR_LOCAL_SVC	指定 TCPIP 服务名和端口号，HADR 进程将在本地主机上接受该服务或端口的连接。这个端口不能与 HADR 实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_HOST	指定远程 HADR 节点的 TCPIP 主机名或 IP 地址
HADR_REMOTE_SVC	指定 TCPIP 服务名或端口号，HADR 进程将在远程节点上接受该服务或端口的连接。这个端口不能与远程实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_INST	指定远程服务器的实例名。DB2 Control Center 之类的管理工具将使用这个参数与远程服务器联系
HADR_TIMEOUT	HADR 进程在认为一次通信尝试失败之前所等待的时间（以秒为单位）。默认值为 120 秒
HADR_SYNCMODE	指定同步模式。它决定当系统处于对等状态时，主日志写与备用数据库如何同步。有效值有 SYNC、NEARSYNC 和 ASYNC。默认值为 NEARSYNC。（本节后面将讨论对等状态）。
HADR_DB_ROLE	指定一个数据库当前的角色。有效值有 STANDARD、PRIMARY 和 STANDBY。STANDARD 意味着数据库没有启用 HADR。

当备用数据库第一次启动时，它进入 local catch-up 状态。本地日志路径中的日志文件（如果有的话）将被读取，并应用到备用数据库。

当到达本地日志文件的最后时，备用数据库进入 remote catch-up 状态。它重演主数据库的归档日志和活动日志，直到备用数据库应用了最近的活动日志。

当主系统上的所有日志文件都已经被重演时，主数据库和备用数据库就进入对等（peer）状态。

在同步模式中，日志写只有在以下情况下才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库的日志文件中。

主数据库与备用数据库中的日志记录几乎（或近似）是同步的，因为只有在以下情况下，日志写才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库上的主存中。

在这种模式下，主数据库不等待收到备用数据库的通知。只有在以下情况下，日志写才被认为是成功的：

日志记录已经被写到主数据库上的日志文件中。
日志记录已经被传送到备用数据库；不需要通知。

HADR 是通过以下三个简单的命令来管理的：

START HADR
STOP HADR
TAKENOVER HADR

这些命令的语法如下：

START HADR ON DATABASE database-alias
[USER userid] [USING password] 
AS PRIMARY | STANDBY [BY FORCE]

STOP HADR ON DATABASE database-alias 
[USER userid] [USING password] 

TAKEOVER HADR ON DATABASE database-alias
[USER userid] [USING password] 
[BY FORCE]

您已经学习了 HADR 的概念，现在可以学习如何设置 HADR 环境。

使用另一个数据库服务器 server2.torolab.ibm.com 作为备用服务器。TEST1 当前不在备用服务器上。

服务名	实例名	SVCENAME 或端口号	数据库名
server1.torolab.ibm.com	DB2INST1	50000	TEST1
server2.torolab.ibm.com	DB2INST1	50000	--

第一次初始化 HADR 时，执行图 13 所示的五个步骤：

确定主服务器和备用服务器。决定主机名、主机 IP 地址和每个 HADR 数据库的服务名或端口号。
您已经确定了主服务器和备用服务器。主服务器是 server1。备用服务器是 server2。

确保这两个服务器是通过 TCPIP 相互通信的。尝试用主机名在这两个服务器上相互 ping 对方。应确保输出没有错误。如果主机名不能使用，那么尝试使用它们的 TCPIP 地址。选用两者中最好用的一种用于 HADR 配置。

通过克隆主数据库创建备用数据库。

有两种方案可用于克隆主数据库：

一种方案是为主数据库做一个备份，并在备用数据库上恢复这个数据库备份。这种方案使用标准备份和恢复方法。
克隆主数据库的另一种方案是使用分割镜像。为主数据库做一个分割镜像，然后在备用服务器上初始化该分割镜像。当初始化分割镜像时，必须在 db2inidb 命令中使用 standby 选项，以便使用 mirror 和 snapshot 选项。

在这个例子种，使用备份/恢复方法来创建备用数据库。

首先为 server1 上的主数据库 TEST1 做一个备份：

BACKUP DB test1

接着，通过 ftp 将备份镜像传送到备用服务器，并恢复该备份镜像。

将备份镜像恢复到与主服务器上相同的位置。在主服务器上，发出 LIST DB DIRECTORY 命令将显示：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            =
 Alternate server port number         =

数据库位于主服务器上的 C: 盘上。当在备用服务器上恢复备份镜像时，也将它恢复到 C: 盘。在备用服务器 server2 上，发出以下命令来恢复 TEST1 数据库：

RESTORE DB test1 ON C:

在主数据库和备用数据库上设置以下 HADR 配置参数：

HADR_LOCAL_HOST
HADR_LOCAL_SVC
HADR_REMOTE_HOST
HADR_REMOTE_SVC
HADR_REMOTE_INST
HADR_SYNCMODE
LOGINDEXBUILD

在主服务器上，为 HADR 使用端口号 70000。更新 Windows\System32\drivers\etc\services 文件，在其中添加以下一行：

Hadr_port 	70000/tcp

在备用服务器上的 services 文件中添加以下一行：

Hadr_port 	80000/tcp

为 HADR_SYNCMODE 使用默认值，即 NEARSYNC。

您已经有了配置 HADR 参数所需的所有信息。发出以下命令来配置备用服务器上的参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在主数据库服务器上，配置相同的一组参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在备用数据库上使用 START HADR 命令启动 HADR：
START HADR ON DB test1 AS STANDBY
在启动主数据库之前启动备用数据库。如果先启动主数据库，那么，如果没有在 HADR_TIMEOUT 数据库配置参数指定的期限内启动备用数据库，那么主数据库的启动过程就会失败。
在主数据库上启动 HADR，如下面的例子所示：
START HADR ON DB test1 AS PRIMARY
HADR 现在已经在主数据库和备用数据库上启动了。

当第一次启动主服务器时，它等待备用服务器与它联系。如果在指定期限内备用服务器没有与主服务器联系，那么 HADR 将不启动。这个期限可以用 HADR_TIMEOUT 配置参数（见表 1）来配置。这样做的目的是避免两个系统在偶然的情况下与主服务器同时启动。

在 HADR 启动过程中，数据库经历以下状态：local catch-up、remote catch-up pending、remote catch-up 和对等状态。日志被自动从主服务器传送到备用服务器，然后在备用服务器上重演。这是为了确保备用数据库跟上主数据库的变化。

强烈建议在主数据库和备用数据库所在的系统上使用相同的数据库配置参数和数据库管理器配置参数。否则，备用数据库就不会像主数据库一样执行。

一个例外是 LOGFILSIZ 数据库配置参数。这个参数的值被备用服务器所忽略。备用服务器自动创建与主数据库上的日志文件大小相匹配的日志文件。这保证了两个数据库上的日志文件是一致的。

在主数据库与备用数据库之间切换数据库角色，也就是说，备用数据库变成主数据库，主数据库变成备用数据库。
从主数据库故障转移到备用数据库。

   GET SNAPSHOT FOR DATABASE ON test1

下面的命令在备用数据库 TEST1 上开始 HADR 数据库切换角色操作：

   TAKEOVER HADR ON DB test1

故障转移方案不切换数据库角色。在故障转移操作期间，备用数据库接管主数据库角色，但是主数据库不会变成备用数据库。

下面的命令在数据库 TEST1 上开始一个 HADR 故障转移操作：

   TAKEOVER HADR ON DB test1 BY FORCE

表 3 和 4 总结了在备用数据库上发出的 TAKEOVER HADR 命令的行为，以及备用数据库所处的对应的 HADR 状态：

备用数据库的状态	接管行为
对等	主数据库和备用数据库都切换角色
Local catch-up or remote catch-up	错误
Remote catch-up pending	错误

备用数据库的状态	接管行为
对等	备用数据库通知主数据库关闭。备用数据库停止接收来自主数据库的日志，完成它已经收到的日志的重演，然后变成主数据库。备用数据库不用等到主数据库发来通知确认它受到接管通知或者它已经关闭
Local catch-up OR remote catch-up	错误
Remote catch-up pending	备用数据库变成主数据库

您已经看到了如何设置 HADR 环境，以及如何使用数据库角色切换和故障转移方案执行接管。

您学习了如何使用 HADR 使数据库具有高可用性。如果主数据库停机，那么它的备用数据库将接管，并成为新的主数据库。

为了启用自动客户机重路由特性，在主数据库上发出 UPDATE ALTERNATE SERVER 命令。该命令的语法如下：

UPDATE ALTERNATE SERVER FOR DATABASE database-alias
USING HOSTNAME alternate-server-hostname PORT port-number

为了在 server1 上的 TEST1 数据库上启用客户机重路由特性，以便在接管之后已有的和新的客户机连接被重新路由到 server2，在 server1 上发出以下命令：

UPDATE ALTERNATE SERVER FOR DATABASE test1 USING 
HOSTNAME server2.torolab.ibm.com PORT 50000

在这个例子中，50000 是 SVCENAME 端口，而不是 HADR 端口。

备用服务器信息存储在 server1 的数据库目录中。如果发出一个 LIST DB DIRECTORY 命令，那么可以注意到备用服务器信息（主机名和端口号）已经被添加：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

现在让我们来看一个关于如何在启用了自动客户机重路由特性的数据库上执行接管的例子。

在这个例子中，不带 BY FORCE 选项执行一个接管。

首先，建立到 server1 上的 TEST1 数据库的一个远程客户机连接。为此，只需在一个远程 DB2 客户机上发出一条 CONNECT TO DATABASE 命令：

CONNECT TO DB test1 USER user1

为了建立那样的连接，客户机必须已经被配置为连接到 server1。关于如何配置远程客户机连接的信息，请参考本系列中的第一篇教程。

在建立连接之后，主服务器上的备用服务器信息被获取并存储在客户机的数据库目录中：

 Database alias                       = TEST1
 Database name                        = TEST1
 Node name                            = server1
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Remote
 Catalog database partition number    = -1
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

确保该连接已成功建立，并且可以查询 TEST1 数据库。在 server1 上发出一条 LIST APPLICATION 命令，它应该显示数据库 TEST1 上的远程客户机连接：

D:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      8          9.26.94.149.24336.060601000305
                                                         TEST1    1

接着，在 TEST1 数据库上执行接管。在备用服务器 server2 上发出以下命令：

TAKEOVER HADR ON DB test1

让我们看看这次接管完成后远程客户机连接有什么变化。

再次尝试从客户机查询 TEST1 数据库。对 TEST1 数据库的任何查询应该都会返回一个错误消息。例如，从客户机连接发出一条 LIST TABLES 命令：

D:\Programs\IBM\SQLLIB\BIN>db2 list tables
SQL30108N A connection failed but has been re-established. 
The hostname or IP address is "server2" and the service name or port number is "50000". 
Special registers may or may not be re-attempted (Reason code = "1").  
SQLSTATE=08506

这证明客户机重路由特性在起作用。现在您已经连接到新的主服务器，即 server2。

在 server2 上发出一条 LIST APPLICATIONS 命令。您可以看到，远程客户机连接已经被重新路由到那里：

H:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      55         9.26.94.149.29200.060601001803
                                                         TEST1    1

如果再次查询数据库，那么可以从新的主服务器得到一个响应。而且，到原来主服务器的新连接也被重新路由到新的主服务器。

使用 GET SNAPSHOT 命令可以获得数据库的 HADR 状态。在 server2 上发出以下命令，应该可以看到 server2 已经接管了主数据库角色：

db2 "get snapshot for database on test1"

  HADR Status
  Role                   = Primary
  State                  = Peer
  Synchronization mode   = Nearsync
  Connection status      = Connected , 05/31/2006 20:17:24.989618
  Heartbeats missed      = 0
  Local host             = server2.torolab.ibm.com
  Local service          = 80000
  Remote host            = server1.torolab.ibm.com
  Remote service         = 70000
  Remote instance        = db2inst1
  timeout(seconds)       = 120
  Primary log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Standby log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Log gap running average(bytes) = 0

在执行接管操作之后，如果出故障的数据库又可以使用，它不会自动恢复主数据库的角色。

通过以下步骤可以使之重新成为主数据库：

修复原来的主数据库所在的系统。这包括修复有问题的硬件或者重新启动崩溃的操作系统。
重新启动出故障的主数据库，使之成为一个备用数据库。
执行一个接管操作，使之接管主数据库的角色。

当原来的主数据库重新以备用数据库的角色加入 HADR 对之后，执行一个接管操作来切换数据库的角色，使原来的主数据库再次成为主数据库。

为了停止 TEST1 数据库上的 HADR，发出：

STOP HADR ON DB test1

您可以看到，HADR 是实现高可用性解决方案的一个强大的特性。提供了一个名为 HADR 向导的图形化用户界面工具，以帮助您设置和配置 HADR。

如果选择 Set Up，那么就会打开一个如图 15 所示的逐步向导。

如果使用 Control Center 设置 HADR 环境，则会自动启用自动客户机重路由特性。

阅读(23810) | 评论(0) | 转发(0) |

上一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（4）

下一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（6）

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

16024965号-6

高可用性灾难恢复（HADR）

DB2 高可用性灾难恢复（HADR）是一种数据库复制特性，它提供了一种高可用性解决方案。目前，HADR 只用于单分区数据库环境。

为了设置 HADR 环境，要更新一些数据库配置参数。

首先，必须启用主数据库上的归档日志记录。请参阅备份和恢复教程，以了解如何启用归档日志记录。

表 1 列出了与 HADR 相关的数据库配置参数的描述。本教程后面将给出一个关于如何更新这些参数的例子。

与 HADR 相关的数据库配置参数	描述
HADR_LOCAL_HOST	指定 HADR TCPIP 通信的本地主机。主机名和 IP 地址都可以使用
HADR_LOCAL_SVC	指定 TCPIP 服务名和端口号，HADR 进程将在本地主机上接受该服务或端口的连接。这个端口不能与 HADR 实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_HOST	指定远程 HADR 节点的 TCPIP 主机名或 IP 地址
HADR_REMOTE_SVC	指定 TCPIP 服务名或端口号，HADR 进程将在远程节点上接受该服务或端口的连接。这个端口不能与远程实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_INST	指定远程服务器的实例名。DB2 Control Center 之类的管理工具将使用这个参数与远程服务器联系
HADR_TIMEOUT	HADR 进程在认为一次通信尝试失败之前所等待的时间（以秒为单位）。默认值为 120 秒
HADR_SYNCMODE	指定同步模式。它决定当系统处于对等状态时，主日志写与备用数据库如何同步。有效值有 SYNC、NEARSYNC 和 ASYNC。默认值为 NEARSYNC。（本节后面将讨论对等状态）。
HADR_DB_ROLE	指定一个数据库当前的角色。有效值有 STANDARD、PRIMARY 和 STANDBY。STANDARD 意味着数据库没有启用 HADR。

当备用数据库第一次启动时，它进入 local catch-up 状态。本地日志路径中的日志文件（如果有的话）将被读取，并应用到备用数据库。

当到达本地日志文件的最后时，备用数据库进入 remote catch-up 状态。它重演主数据库的归档日志和活动日志，直到备用数据库应用了最近的活动日志。

当主系统上的所有日志文件都已经被重演时，主数据库和备用数据库就进入对等（peer）状态。

在同步模式中，日志写只有在以下情况下才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库的日志文件中。

主数据库与备用数据库中的日志记录几乎（或近似）是同步的，因为只有在以下情况下，日志写才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库上的主存中。

在这种模式下，主数据库不等待收到备用数据库的通知。只有在以下情况下，日志写才被认为是成功的：

日志记录已经被写到主数据库上的日志文件中。
日志记录已经被传送到备用数据库；不需要通知。

HADR 是通过以下三个简单的命令来管理的：

START HADR
STOP HADR
TAKENOVER HADR

这些命令的语法如下：

START HADR ON DATABASE database-alias
[USER userid] [USING password] 
AS PRIMARY | STANDBY [BY FORCE]

STOP HADR ON DATABASE database-alias 
[USER userid] [USING password] 

TAKEOVER HADR ON DATABASE database-alias
[USER userid] [USING password] 
[BY FORCE]

您已经学习了 HADR 的概念，现在可以学习如何设置 HADR 环境。

使用另一个数据库服务器 server2.torolab.ibm.com 作为备用服务器。TEST1 当前不在备用服务器上。

服务名	实例名	SVCENAME 或端口号	数据库名
server1.torolab.ibm.com	DB2INST1	50000	TEST1
server2.torolab.ibm.com	DB2INST1	50000	--

第一次初始化 HADR 时，执行图 13 所示的五个步骤：

确定主服务器和备用服务器。决定主机名、主机 IP 地址和每个 HADR 数据库的服务名或端口号。
您已经确定了主服务器和备用服务器。主服务器是 server1。备用服务器是 server2。

确保这两个服务器是通过 TCPIP 相互通信的。尝试用主机名在这两个服务器上相互 ping 对方。应确保输出没有错误。如果主机名不能使用，那么尝试使用它们的 TCPIP 地址。选用两者中最好用的一种用于 HADR 配置。

通过克隆主数据库创建备用数据库。

有两种方案可用于克隆主数据库：

一种方案是为主数据库做一个备份，并在备用数据库上恢复这个数据库备份。这种方案使用标准备份和恢复方法。
克隆主数据库的另一种方案是使用分割镜像。为主数据库做一个分割镜像，然后在备用服务器上初始化该分割镜像。当初始化分割镜像时，必须在 db2inidb 命令中使用 standby 选项，以便使用 mirror 和 snapshot 选项。

在这个例子种，使用备份/恢复方法来创建备用数据库。

首先为 server1 上的主数据库 TEST1 做一个备份：

BACKUP DB test1

接着，通过 ftp 将备份镜像传送到备用服务器，并恢复该备份镜像。

将备份镜像恢复到与主服务器上相同的位置。在主服务器上，发出 LIST DB DIRECTORY 命令将显示：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            =
 Alternate server port number         =

数据库位于主服务器上的 C: 盘上。当在备用服务器上恢复备份镜像时，也将它恢复到 C: 盘。在备用服务器 server2 上，发出以下命令来恢复 TEST1 数据库：

RESTORE DB test1 ON C:

在主数据库和备用数据库上设置以下 HADR 配置参数：

HADR_LOCAL_HOST
HADR_LOCAL_SVC
HADR_REMOTE_HOST
HADR_REMOTE_SVC
HADR_REMOTE_INST
HADR_SYNCMODE
LOGINDEXBUILD

在主服务器上，为 HADR 使用端口号 70000。更新 Windows\System32\drivers\etc\services 文件，在其中添加以下一行：

Hadr_port 	70000/tcp

在备用服务器上的 services 文件中添加以下一行：

Hadr_port 	80000/tcp

为 HADR_SYNCMODE 使用默认值，即 NEARSYNC。

您已经有了配置 HADR 参数所需的所有信息。发出以下命令来配置备用服务器上的参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在主数据库服务器上，配置相同的一组参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在备用数据库上使用 START HADR 命令启动 HADR：
START HADR ON DB test1 AS STANDBY
在启动主数据库之前启动备用数据库。如果先启动主数据库，那么，如果没有在 HADR_TIMEOUT 数据库配置参数指定的期限内启动备用数据库，那么主数据库的启动过程就会失败。
在主数据库上启动 HADR，如下面的例子所示：
START HADR ON DB test1 AS PRIMARY
HADR 现在已经在主数据库和备用数据库上启动了。

当第一次启动主服务器时，它等待备用服务器与它联系。如果在指定期限内备用服务器没有与主服务器联系，那么 HADR 将不启动。这个期限可以用 HADR_TIMEOUT 配置参数（见表 1）来配置。这样做的目的是避免两个系统在偶然的情况下与主服务器同时启动。

在 HADR 启动过程中，数据库经历以下状态：local catch-up、remote catch-up pending、remote catch-up 和对等状态。日志被自动从主服务器传送到备用服务器，然后在备用服务器上重演。这是为了确保备用数据库跟上主数据库的变化。

强烈建议在主数据库和备用数据库所在的系统上使用相同的数据库配置参数和数据库管理器配置参数。否则，备用数据库就不会像主数据库一样执行。

一个例外是 LOGFILSIZ 数据库配置参数。这个参数的值被备用服务器所忽略。备用服务器自动创建与主数据库上的日志文件大小相匹配的日志文件。这保证了两个数据库上的日志文件是一致的。

在主数据库与备用数据库之间切换数据库角色，也就是说，备用数据库变成主数据库，主数据库变成备用数据库。
从主数据库故障转移到备用数据库。

   GET SNAPSHOT FOR DATABASE ON test1

下面的命令在备用数据库 TEST1 上开始 HADR 数据库切换角色操作：

   TAKEOVER HADR ON DB test1

故障转移方案不切换数据库角色。在故障转移操作期间，备用数据库接管主数据库角色，但是主数据库不会变成备用数据库。

下面的命令在数据库 TEST1 上开始一个 HADR 故障转移操作：

   TAKEOVER HADR ON DB test1 BY FORCE

表 3 和 4 总结了在备用数据库上发出的 TAKEOVER HADR 命令的行为，以及备用数据库所处的对应的 HADR 状态：

备用数据库的状态	接管行为
对等	主数据库和备用数据库都切换角色
Local catch-up or remote catch-up	错误
Remote catch-up pending	错误

备用数据库的状态	接管行为
对等	备用数据库通知主数据库关闭。备用数据库停止接收来自主数据库的日志，完成它已经收到的日志的重演，然后变成主数据库。备用数据库不用等到主数据库发来通知确认它受到接管通知或者它已经关闭
Local catch-up OR remote catch-up	错误
Remote catch-up pending	备用数据库变成主数据库

您已经看到了如何设置 HADR 环境，以及如何使用数据库角色切换和故障转移方案执行接管。

您学习了如何使用 HADR 使数据库具有高可用性。如果主数据库停机，那么它的备用数据库将接管，并成为新的主数据库。

为了启用自动客户机重路由特性，在主数据库上发出 UPDATE ALTERNATE SERVER 命令。该命令的语法如下：

UPDATE ALTERNATE SERVER FOR DATABASE database-alias
USING HOSTNAME alternate-server-hostname PORT port-number

为了在 server1 上的 TEST1 数据库上启用客户机重路由特性，以便在接管之后已有的和新的客户机连接被重新路由到 server2，在 server1 上发出以下命令：

UPDATE ALTERNATE SERVER FOR DATABASE test1 USING 
HOSTNAME server2.torolab.ibm.com PORT 50000

在这个例子中，50000 是 SVCENAME 端口，而不是 HADR 端口。

备用服务器信息存储在 server1 的数据库目录中。如果发出一个 LIST DB DIRECTORY 命令，那么可以注意到备用服务器信息（主机名和端口号）已经被添加：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

现在让我们来看一个关于如何在启用了自动客户机重路由特性的数据库上执行接管的例子。

在这个例子中，不带 BY FORCE 选项执行一个接管。

首先，建立到 server1 上的 TEST1 数据库的一个远程客户机连接。为此，只需在一个远程 DB2 客户机上发出一条 CONNECT TO DATABASE 命令：

CONNECT TO DB test1 USER user1

为了建立那样的连接，客户机必须已经被配置为连接到 server1。关于如何配置远程客户机连接的信息，请参考本系列中的第一篇教程。

在建立连接之后，主服务器上的备用服务器信息被获取并存储在客户机的数据库目录中：

 Database alias                       = TEST1
 Database name                        = TEST1
 Node name                            = server1
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Remote
 Catalog database partition number    = -1
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

确保该连接已成功建立，并且可以查询 TEST1 数据库。在 server1 上发出一条 LIST APPLICATION 命令，它应该显示数据库 TEST1 上的远程客户机连接：

D:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      8          9.26.94.149.24336.060601000305
                                                         TEST1    1

接着，在 TEST1 数据库上执行接管。在备用服务器 server2 上发出以下命令：

TAKEOVER HADR ON DB test1

让我们看看这次接管完成后远程客户机连接有什么变化。

再次尝试从客户机查询 TEST1 数据库。对 TEST1 数据库的任何查询应该都会返回一个错误消息。例如，从客户机连接发出一条 LIST TABLES 命令：

D:\Programs\IBM\SQLLIB\BIN>db2 list tables
SQL30108N A connection failed but has been re-established. 
The hostname or IP address is "server2" and the service name or port number is "50000". 
Special registers may or may not be re-attempted (Reason code = "1").  
SQLSTATE=08506

这证明客户机重路由特性在起作用。现在您已经连接到新的主服务器，即 server2。

在 server2 上发出一条 LIST APPLICATIONS 命令。您可以看到，远程客户机连接已经被重新路由到那里：

H:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      55         9.26.94.149.29200.060601001803
                                                         TEST1    1

如果再次查询数据库，那么可以从新的主服务器得到一个响应。而且，到原来主服务器的新连接也被重新路由到新的主服务器。

使用 GET SNAPSHOT 命令可以获得数据库的 HADR 状态。在 server2 上发出以下命令，应该可以看到 server2 已经接管了主数据库角色：

db2 "get snapshot for database on test1"

  HADR Status
  Role                   = Primary
  State                  = Peer
  Synchronization mode   = Nearsync
  Connection status      = Connected , 05/31/2006 20:17:24.989618
  Heartbeats missed      = 0
  Local host             = server2.torolab.ibm.com
  Local service          = 80000
  Remote host            = server1.torolab.ibm.com
  Remote service         = 70000
  Remote instance        = db2inst1
  timeout(seconds)       = 120
  Primary log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Standby log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Log gap running average(bytes) = 0

在执行接管操作之后，如果出故障的数据库又可以使用，它不会自动恢复主数据库的角色。

通过以下步骤可以使之重新成为主数据库：

修复原来的主数据库所在的系统。这包括修复有问题的硬件或者重新启动崩溃的操作系统。
重新启动出故障的主数据库，使之成为一个备用数据库。
执行一个接管操作，使之接管主数据库的角色。

当原来的主数据库重新以备用数据库的角色加入 HADR 对之后，执行一个接管操作来切换数据库的角色，使原来的主数据库再次成为主数据库。

为了停止 TEST1 数据库上的 HADR，发出：

STOP HADR ON DB test1

您可以看到，HADR 是实现高可用性解决方案的一个强大的特性。提供了一个名为 HADR 向导的图形化用户界面工具，以帮助您设置和配置 HADR。

如果选择 Set Up，那么就会打开一个如图 15 所示的逐步向导。

如果使用 Control Center 设置 HADR 环境，则会自动启用自动客户机重路由特性。

阅读(23809) | 评论(0) | 转发(0) |

上一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（4）

下一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（6）

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

16024965号-6

高可用性灾难恢复（HADR）

DB2 高可用性灾难恢复（HADR）是一种数据库复制特性，它提供了一种高可用性解决方案。目前，HADR 只用于单分区数据库环境。

为了设置 HADR 环境，要更新一些数据库配置参数。

首先，必须启用主数据库上的归档日志记录。请参阅备份和恢复教程，以了解如何启用归档日志记录。

表 1 列出了与 HADR 相关的数据库配置参数的描述。本教程后面将给出一个关于如何更新这些参数的例子。

与 HADR 相关的数据库配置参数	描述
HADR_LOCAL_HOST	指定 HADR TCPIP 通信的本地主机。主机名和 IP 地址都可以使用
HADR_LOCAL_SVC	指定 TCPIP 服务名和端口号，HADR 进程将在本地主机上接受该服务或端口的连接。这个端口不能与 HADR 实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_HOST	指定远程 HADR 节点的 TCPIP 主机名或 IP 地址
HADR_REMOTE_SVC	指定 TCPIP 服务名或端口号，HADR 进程将在远程节点上接受该服务或端口的连接。这个端口不能与远程实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_INST	指定远程服务器的实例名。DB2 Control Center 之类的管理工具将使用这个参数与远程服务器联系
HADR_TIMEOUT	HADR 进程在认为一次通信尝试失败之前所等待的时间（以秒为单位）。默认值为 120 秒
HADR_SYNCMODE	指定同步模式。它决定当系统处于对等状态时，主日志写与备用数据库如何同步。有效值有 SYNC、NEARSYNC 和 ASYNC。默认值为 NEARSYNC。（本节后面将讨论对等状态）。
HADR_DB_ROLE	指定一个数据库当前的角色。有效值有 STANDARD、PRIMARY 和 STANDBY。STANDARD 意味着数据库没有启用 HADR。

当备用数据库第一次启动时，它进入 local catch-up 状态。本地日志路径中的日志文件（如果有的话）将被读取，并应用到备用数据库。

当到达本地日志文件的最后时，备用数据库进入 remote catch-up 状态。它重演主数据库的归档日志和活动日志，直到备用数据库应用了最近的活动日志。

当主系统上的所有日志文件都已经被重演时，主数据库和备用数据库就进入对等（peer）状态。

在同步模式中，日志写只有在以下情况下才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库的日志文件中。

主数据库与备用数据库中的日志记录几乎（或近似）是同步的，因为只有在以下情况下，日志写才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库上的主存中。

在这种模式下，主数据库不等待收到备用数据库的通知。只有在以下情况下，日志写才被认为是成功的：

日志记录已经被写到主数据库上的日志文件中。
日志记录已经被传送到备用数据库；不需要通知。

HADR 是通过以下三个简单的命令来管理的：

START HADR
STOP HADR
TAKENOVER HADR

这些命令的语法如下：

START HADR ON DATABASE database-alias
[USER userid] [USING password] 
AS PRIMARY | STANDBY [BY FORCE]

STOP HADR ON DATABASE database-alias 
[USER userid] [USING password] 

TAKEOVER HADR ON DATABASE database-alias
[USER userid] [USING password] 
[BY FORCE]

您已经学习了 HADR 的概念，现在可以学习如何设置 HADR 环境。

使用另一个数据库服务器 server2.torolab.ibm.com 作为备用服务器。TEST1 当前不在备用服务器上。

服务名	实例名	SVCENAME 或端口号	数据库名
server1.torolab.ibm.com	DB2INST1	50000	TEST1
server2.torolab.ibm.com	DB2INST1	50000	--

第一次初始化 HADR 时，执行图 13 所示的五个步骤：

确定主服务器和备用服务器。决定主机名、主机 IP 地址和每个 HADR 数据库的服务名或端口号。
您已经确定了主服务器和备用服务器。主服务器是 server1。备用服务器是 server2。

确保这两个服务器是通过 TCPIP 相互通信的。尝试用主机名在这两个服务器上相互 ping 对方。应确保输出没有错误。如果主机名不能使用，那么尝试使用它们的 TCPIP 地址。选用两者中最好用的一种用于 HADR 配置。

通过克隆主数据库创建备用数据库。

有两种方案可用于克隆主数据库：

一种方案是为主数据库做一个备份，并在备用数据库上恢复这个数据库备份。这种方案使用标准备份和恢复方法。
克隆主数据库的另一种方案是使用分割镜像。为主数据库做一个分割镜像，然后在备用服务器上初始化该分割镜像。当初始化分割镜像时，必须在 db2inidb 命令中使用 standby 选项，以便使用 mirror 和 snapshot 选项。

在这个例子种，使用备份/恢复方法来创建备用数据库。

首先为 server1 上的主数据库 TEST1 做一个备份：

BACKUP DB test1

接着，通过 ftp 将备份镜像传送到备用服务器，并恢复该备份镜像。

将备份镜像恢复到与主服务器上相同的位置。在主服务器上，发出 LIST DB DIRECTORY 命令将显示：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            =
 Alternate server port number         =

数据库位于主服务器上的 C: 盘上。当在备用服务器上恢复备份镜像时，也将它恢复到 C: 盘。在备用服务器 server2 上，发出以下命令来恢复 TEST1 数据库：

RESTORE DB test1 ON C:

在主数据库和备用数据库上设置以下 HADR 配置参数：

HADR_LOCAL_HOST
HADR_LOCAL_SVC
HADR_REMOTE_HOST
HADR_REMOTE_SVC
HADR_REMOTE_INST
HADR_SYNCMODE
LOGINDEXBUILD

在主服务器上，为 HADR 使用端口号 70000。更新 Windows\System32\drivers\etc\services 文件，在其中添加以下一行：

Hadr_port 	70000/tcp

在备用服务器上的 services 文件中添加以下一行：

Hadr_port 	80000/tcp

为 HADR_SYNCMODE 使用默认值，即 NEARSYNC。

您已经有了配置 HADR 参数所需的所有信息。发出以下命令来配置备用服务器上的参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在主数据库服务器上，配置相同的一组参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在备用数据库上使用 START HADR 命令启动 HADR：
START HADR ON DB test1 AS STANDBY
在启动主数据库之前启动备用数据库。如果先启动主数据库，那么，如果没有在 HADR_TIMEOUT 数据库配置参数指定的期限内启动备用数据库，那么主数据库的启动过程就会失败。
在主数据库上启动 HADR，如下面的例子所示：
START HADR ON DB test1 AS PRIMARY
HADR 现在已经在主数据库和备用数据库上启动了。

当第一次启动主服务器时，它等待备用服务器与它联系。如果在指定期限内备用服务器没有与主服务器联系，那么 HADR 将不启动。这个期限可以用 HADR_TIMEOUT 配置参数（见表 1）来配置。这样做的目的是避免两个系统在偶然的情况下与主服务器同时启动。

在 HADR 启动过程中，数据库经历以下状态：local catch-up、remote catch-up pending、remote catch-up 和对等状态。日志被自动从主服务器传送到备用服务器，然后在备用服务器上重演。这是为了确保备用数据库跟上主数据库的变化。

强烈建议在主数据库和备用数据库所在的系统上使用相同的数据库配置参数和数据库管理器配置参数。否则，备用数据库就不会像主数据库一样执行。

一个例外是 LOGFILSIZ 数据库配置参数。这个参数的值被备用服务器所忽略。备用服务器自动创建与主数据库上的日志文件大小相匹配的日志文件。这保证了两个数据库上的日志文件是一致的。

在主数据库与备用数据库之间切换数据库角色，也就是说，备用数据库变成主数据库，主数据库变成备用数据库。
从主数据库故障转移到备用数据库。

   GET SNAPSHOT FOR DATABASE ON test1

下面的命令在备用数据库 TEST1 上开始 HADR 数据库切换角色操作：

   TAKEOVER HADR ON DB test1

故障转移方案不切换数据库角色。在故障转移操作期间，备用数据库接管主数据库角色，但是主数据库不会变成备用数据库。

下面的命令在数据库 TEST1 上开始一个 HADR 故障转移操作：

   TAKEOVER HADR ON DB test1 BY FORCE

表 3 和 4 总结了在备用数据库上发出的 TAKEOVER HADR 命令的行为，以及备用数据库所处的对应的 HADR 状态：

备用数据库的状态	接管行为
对等	主数据库和备用数据库都切换角色
Local catch-up or remote catch-up	错误
Remote catch-up pending	错误

备用数据库的状态	接管行为
对等	备用数据库通知主数据库关闭。备用数据库停止接收来自主数据库的日志，完成它已经收到的日志的重演，然后变成主数据库。备用数据库不用等到主数据库发来通知确认它受到接管通知或者它已经关闭
Local catch-up OR remote catch-up	错误
Remote catch-up pending	备用数据库变成主数据库

您已经看到了如何设置 HADR 环境，以及如何使用数据库角色切换和故障转移方案执行接管。

您学习了如何使用 HADR 使数据库具有高可用性。如果主数据库停机，那么它的备用数据库将接管，并成为新的主数据库。

为了启用自动客户机重路由特性，在主数据库上发出 UPDATE ALTERNATE SERVER 命令。该命令的语法如下：

UPDATE ALTERNATE SERVER FOR DATABASE database-alias
USING HOSTNAME alternate-server-hostname PORT port-number

为了在 server1 上的 TEST1 数据库上启用客户机重路由特性，以便在接管之后已有的和新的客户机连接被重新路由到 server2，在 server1 上发出以下命令：

UPDATE ALTERNATE SERVER FOR DATABASE test1 USING 
HOSTNAME server2.torolab.ibm.com PORT 50000

在这个例子中，50000 是 SVCENAME 端口，而不是 HADR 端口。

备用服务器信息存储在 server1 的数据库目录中。如果发出一个 LIST DB DIRECTORY 命令，那么可以注意到备用服务器信息（主机名和端口号）已经被添加：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

现在让我们来看一个关于如何在启用了自动客户机重路由特性的数据库上执行接管的例子。

在这个例子中，不带 BY FORCE 选项执行一个接管。

首先，建立到 server1 上的 TEST1 数据库的一个远程客户机连接。为此，只需在一个远程 DB2 客户机上发出一条 CONNECT TO DATABASE 命令：

CONNECT TO DB test1 USER user1

为了建立那样的连接，客户机必须已经被配置为连接到 server1。关于如何配置远程客户机连接的信息，请参考本系列中的第一篇教程。

在建立连接之后，主服务器上的备用服务器信息被获取并存储在客户机的数据库目录中：

 Database alias                       = TEST1
 Database name                        = TEST1
 Node name                            = server1
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Remote
 Catalog database partition number    = -1
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

确保该连接已成功建立，并且可以查询 TEST1 数据库。在 server1 上发出一条 LIST APPLICATION 命令，它应该显示数据库 TEST1 上的远程客户机连接：

D:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      8          9.26.94.149.24336.060601000305
                                                         TEST1    1

接着，在 TEST1 数据库上执行接管。在备用服务器 server2 上发出以下命令：

TAKEOVER HADR ON DB test1

让我们看看这次接管完成后远程客户机连接有什么变化。

再次尝试从客户机查询 TEST1 数据库。对 TEST1 数据库的任何查询应该都会返回一个错误消息。例如，从客户机连接发出一条 LIST TABLES 命令：

D:\Programs\IBM\SQLLIB\BIN>db2 list tables
SQL30108N A connection failed but has been re-established. 
The hostname or IP address is "server2" and the service name or port number is "50000". 
Special registers may or may not be re-attempted (Reason code = "1").  
SQLSTATE=08506

这证明客户机重路由特性在起作用。现在您已经连接到新的主服务器，即 server2。

在 server2 上发出一条 LIST APPLICATIONS 命令。您可以看到，远程客户机连接已经被重新路由到那里：

H:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      55         9.26.94.149.29200.060601001803
                                                         TEST1    1

如果再次查询数据库，那么可以从新的主服务器得到一个响应。而且，到原来主服务器的新连接也被重新路由到新的主服务器。

使用 GET SNAPSHOT 命令可以获得数据库的 HADR 状态。在 server2 上发出以下命令，应该可以看到 server2 已经接管了主数据库角色：

db2 "get snapshot for database on test1"

  HADR Status
  Role                   = Primary
  State                  = Peer
  Synchronization mode   = Nearsync
  Connection status      = Connected , 05/31/2006 20:17:24.989618
  Heartbeats missed      = 0
  Local host             = server2.torolab.ibm.com
  Local service          = 80000
  Remote host            = server1.torolab.ibm.com
  Remote service         = 70000
  Remote instance        = db2inst1
  timeout(seconds)       = 120
  Primary log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Standby log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Log gap running average(bytes) = 0

在执行接管操作之后，如果出故障的数据库又可以使用，它不会自动恢复主数据库的角色。

通过以下步骤可以使之重新成为主数据库：

修复原来的主数据库所在的系统。这包括修复有问题的硬件或者重新启动崩溃的操作系统。
重新启动出故障的主数据库，使之成为一个备用数据库。
执行一个接管操作，使之接管主数据库的角色。

当原来的主数据库重新以备用数据库的角色加入 HADR 对之后，执行一个接管操作来切换数据库的角色，使原来的主数据库再次成为主数据库。

为了停止 TEST1 数据库上的 HADR，发出：

STOP HADR ON DB test1

您可以看到，HADR 是实现高可用性解决方案的一个强大的特性。提供了一个名为 HADR 向导的图形化用户界面工具，以帮助您设置和配置 HADR。

如果选择 Set Up，那么就会打开一个如图 15 所示的逐步向导。

如果使用 Control Center 设置 HADR 环境，则会自动启用自动客户机重路由特性。

阅读(23808) | 评论(0) | 转发(0) |

上一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（4）

下一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（6）

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

16024965号-6

高可用性灾难恢复（HADR）

DB2 高可用性灾难恢复（HADR）是一种数据库复制特性，它提供了一种高可用性解决方案。目前，HADR 只用于单分区数据库环境。

为了设置 HADR 环境，要更新一些数据库配置参数。

首先，必须启用主数据库上的归档日志记录。请参阅备份和恢复教程，以了解如何启用归档日志记录。

表 1 列出了与 HADR 相关的数据库配置参数的描述。本教程后面将给出一个关于如何更新这些参数的例子。

与 HADR 相关的数据库配置参数	描述
HADR_LOCAL_HOST	指定 HADR TCPIP 通信的本地主机。主机名和 IP 地址都可以使用
HADR_LOCAL_SVC	指定 TCPIP 服务名和端口号，HADR 进程将在本地主机上接受该服务或端口的连接。这个端口不能与 HADR 实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_HOST	指定远程 HADR 节点的 TCPIP 主机名或 IP 地址
HADR_REMOTE_SVC	指定 TCPIP 服务名或端口号，HADR 进程将在远程节点上接受该服务或端口的连接。这个端口不能与远程实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_INST	指定远程服务器的实例名。DB2 Control Center 之类的管理工具将使用这个参数与远程服务器联系
HADR_TIMEOUT	HADR 进程在认为一次通信尝试失败之前所等待的时间（以秒为单位）。默认值为 120 秒
HADR_SYNCMODE	指定同步模式。它决定当系统处于对等状态时，主日志写与备用数据库如何同步。有效值有 SYNC、NEARSYNC 和 ASYNC。默认值为 NEARSYNC。（本节后面将讨论对等状态）。
HADR_DB_ROLE	指定一个数据库当前的角色。有效值有 STANDARD、PRIMARY 和 STANDBY。STANDARD 意味着数据库没有启用 HADR。

当备用数据库第一次启动时，它进入 local catch-up 状态。本地日志路径中的日志文件（如果有的话）将被读取，并应用到备用数据库。

当到达本地日志文件的最后时，备用数据库进入 remote catch-up 状态。它重演主数据库的归档日志和活动日志，直到备用数据库应用了最近的活动日志。

当主系统上的所有日志文件都已经被重演时，主数据库和备用数据库就进入对等（peer）状态。

在同步模式中，日志写只有在以下情况下才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库的日志文件中。

主数据库与备用数据库中的日志记录几乎（或近似）是同步的，因为只有在以下情况下，日志写才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库上的主存中。

在这种模式下，主数据库不等待收到备用数据库的通知。只有在以下情况下，日志写才被认为是成功的：

日志记录已经被写到主数据库上的日志文件中。
日志记录已经被传送到备用数据库；不需要通知。

HADR 是通过以下三个简单的命令来管理的：

START HADR
STOP HADR
TAKENOVER HADR

这些命令的语法如下：

START HADR ON DATABASE database-alias
[USER userid] [USING password] 
AS PRIMARY | STANDBY [BY FORCE]

STOP HADR ON DATABASE database-alias 
[USER userid] [USING password] 

TAKEOVER HADR ON DATABASE database-alias
[USER userid] [USING password] 
[BY FORCE]

您已经学习了 HADR 的概念，现在可以学习如何设置 HADR 环境。

使用另一个数据库服务器 server2.torolab.ibm.com 作为备用服务器。TEST1 当前不在备用服务器上。

服务名	实例名	SVCENAME 或端口号	数据库名
server1.torolab.ibm.com	DB2INST1	50000	TEST1
server2.torolab.ibm.com	DB2INST1	50000	--

第一次初始化 HADR 时，执行图 13 所示的五个步骤：

确定主服务器和备用服务器。决定主机名、主机 IP 地址和每个 HADR 数据库的服务名或端口号。
您已经确定了主服务器和备用服务器。主服务器是 server1。备用服务器是 server2。

确保这两个服务器是通过 TCPIP 相互通信的。尝试用主机名在这两个服务器上相互 ping 对方。应确保输出没有错误。如果主机名不能使用，那么尝试使用它们的 TCPIP 地址。选用两者中最好用的一种用于 HADR 配置。

通过克隆主数据库创建备用数据库。

有两种方案可用于克隆主数据库：

一种方案是为主数据库做一个备份，并在备用数据库上恢复这个数据库备份。这种方案使用标准备份和恢复方法。
克隆主数据库的另一种方案是使用分割镜像。为主数据库做一个分割镜像，然后在备用服务器上初始化该分割镜像。当初始化分割镜像时，必须在 db2inidb 命令中使用 standby 选项，以便使用 mirror 和 snapshot 选项。

在这个例子种，使用备份/恢复方法来创建备用数据库。

首先为 server1 上的主数据库 TEST1 做一个备份：

BACKUP DB test1

接着，通过 ftp 将备份镜像传送到备用服务器，并恢复该备份镜像。

将备份镜像恢复到与主服务器上相同的位置。在主服务器上，发出 LIST DB DIRECTORY 命令将显示：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            =
 Alternate server port number         =

数据库位于主服务器上的 C: 盘上。当在备用服务器上恢复备份镜像时，也将它恢复到 C: 盘。在备用服务器 server2 上，发出以下命令来恢复 TEST1 数据库：

RESTORE DB test1 ON C:

在主数据库和备用数据库上设置以下 HADR 配置参数：

HADR_LOCAL_HOST
HADR_LOCAL_SVC
HADR_REMOTE_HOST
HADR_REMOTE_SVC
HADR_REMOTE_INST
HADR_SYNCMODE
LOGINDEXBUILD

在主服务器上，为 HADR 使用端口号 70000。更新 Windows\System32\drivers\etc\services 文件，在其中添加以下一行：

Hadr_port 	70000/tcp

在备用服务器上的 services 文件中添加以下一行：

Hadr_port 	80000/tcp

为 HADR_SYNCMODE 使用默认值，即 NEARSYNC。

您已经有了配置 HADR 参数所需的所有信息。发出以下命令来配置备用服务器上的参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在主数据库服务器上，配置相同的一组参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在备用数据库上使用 START HADR 命令启动 HADR：
START HADR ON DB test1 AS STANDBY
在启动主数据库之前启动备用数据库。如果先启动主数据库，那么，如果没有在 HADR_TIMEOUT 数据库配置参数指定的期限内启动备用数据库，那么主数据库的启动过程就会失败。
在主数据库上启动 HADR，如下面的例子所示：
START HADR ON DB test1 AS PRIMARY
HADR 现在已经在主数据库和备用数据库上启动了。

当第一次启动主服务器时，它等待备用服务器与它联系。如果在指定期限内备用服务器没有与主服务器联系，那么 HADR 将不启动。这个期限可以用 HADR_TIMEOUT 配置参数（见表 1）来配置。这样做的目的是避免两个系统在偶然的情况下与主服务器同时启动。

在 HADR 启动过程中，数据库经历以下状态：local catch-up、remote catch-up pending、remote catch-up 和对等状态。日志被自动从主服务器传送到备用服务器，然后在备用服务器上重演。这是为了确保备用数据库跟上主数据库的变化。

强烈建议在主数据库和备用数据库所在的系统上使用相同的数据库配置参数和数据库管理器配置参数。否则，备用数据库就不会像主数据库一样执行。

一个例外是 LOGFILSIZ 数据库配置参数。这个参数的值被备用服务器所忽略。备用服务器自动创建与主数据库上的日志文件大小相匹配的日志文件。这保证了两个数据库上的日志文件是一致的。

在主数据库与备用数据库之间切换数据库角色，也就是说，备用数据库变成主数据库，主数据库变成备用数据库。
从主数据库故障转移到备用数据库。

   GET SNAPSHOT FOR DATABASE ON test1

下面的命令在备用数据库 TEST1 上开始 HADR 数据库切换角色操作：

   TAKEOVER HADR ON DB test1

故障转移方案不切换数据库角色。在故障转移操作期间，备用数据库接管主数据库角色，但是主数据库不会变成备用数据库。

下面的命令在数据库 TEST1 上开始一个 HADR 故障转移操作：

   TAKEOVER HADR ON DB test1 BY FORCE

表 3 和 4 总结了在备用数据库上发出的 TAKEOVER HADR 命令的行为，以及备用数据库所处的对应的 HADR 状态：

备用数据库的状态	接管行为
对等	主数据库和备用数据库都切换角色
Local catch-up or remote catch-up	错误
Remote catch-up pending	错误

备用数据库的状态	接管行为
对等	备用数据库通知主数据库关闭。备用数据库停止接收来自主数据库的日志，完成它已经收到的日志的重演，然后变成主数据库。备用数据库不用等到主数据库发来通知确认它受到接管通知或者它已经关闭
Local catch-up OR remote catch-up	错误
Remote catch-up pending	备用数据库变成主数据库

您已经看到了如何设置 HADR 环境，以及如何使用数据库角色切换和故障转移方案执行接管。

您学习了如何使用 HADR 使数据库具有高可用性。如果主数据库停机，那么它的备用数据库将接管，并成为新的主数据库。

为了启用自动客户机重路由特性，在主数据库上发出 UPDATE ALTERNATE SERVER 命令。该命令的语法如下：

UPDATE ALTERNATE SERVER FOR DATABASE database-alias
USING HOSTNAME alternate-server-hostname PORT port-number

为了在 server1 上的 TEST1 数据库上启用客户机重路由特性，以便在接管之后已有的和新的客户机连接被重新路由到 server2，在 server1 上发出以下命令：

UPDATE ALTERNATE SERVER FOR DATABASE test1 USING 
HOSTNAME server2.torolab.ibm.com PORT 50000

在这个例子中，50000 是 SVCENAME 端口，而不是 HADR 端口。

备用服务器信息存储在 server1 的数据库目录中。如果发出一个 LIST DB DIRECTORY 命令，那么可以注意到备用服务器信息（主机名和端口号）已经被添加：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

现在让我们来看一个关于如何在启用了自动客户机重路由特性的数据库上执行接管的例子。

在这个例子中，不带 BY FORCE 选项执行一个接管。

首先，建立到 server1 上的 TEST1 数据库的一个远程客户机连接。为此，只需在一个远程 DB2 客户机上发出一条 CONNECT TO DATABASE 命令：

CONNECT TO DB test1 USER user1

为了建立那样的连接，客户机必须已经被配置为连接到 server1。关于如何配置远程客户机连接的信息，请参考本系列中的第一篇教程。

在建立连接之后，主服务器上的备用服务器信息被获取并存储在客户机的数据库目录中：

 Database alias                       = TEST1
 Database name                        = TEST1
 Node name                            = server1
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Remote
 Catalog database partition number    = -1
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

确保该连接已成功建立，并且可以查询 TEST1 数据库。在 server1 上发出一条 LIST APPLICATION 命令，它应该显示数据库 TEST1 上的远程客户机连接：

D:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      8          9.26.94.149.24336.060601000305
                                                         TEST1    1

接着，在 TEST1 数据库上执行接管。在备用服务器 server2 上发出以下命令：

TAKEOVER HADR ON DB test1

让我们看看这次接管完成后远程客户机连接有什么变化。

再次尝试从客户机查询 TEST1 数据库。对 TEST1 数据库的任何查询应该都会返回一个错误消息。例如，从客户机连接发出一条 LIST TABLES 命令：

D:\Programs\IBM\SQLLIB\BIN>db2 list tables
SQL30108N A connection failed but has been re-established. 
The hostname or IP address is "server2" and the service name or port number is "50000". 
Special registers may or may not be re-attempted (Reason code = "1").  
SQLSTATE=08506

这证明客户机重路由特性在起作用。现在您已经连接到新的主服务器，即 server2。

在 server2 上发出一条 LIST APPLICATIONS 命令。您可以看到，远程客户机连接已经被重新路由到那里：

H:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      55         9.26.94.149.29200.060601001803
                                                         TEST1    1

如果再次查询数据库，那么可以从新的主服务器得到一个响应。而且，到原来主服务器的新连接也被重新路由到新的主服务器。

使用 GET SNAPSHOT 命令可以获得数据库的 HADR 状态。在 server2 上发出以下命令，应该可以看到 server2 已经接管了主数据库角色：

db2 "get snapshot for database on test1"

  HADR Status
  Role                   = Primary
  State                  = Peer
  Synchronization mode   = Nearsync
  Connection status      = Connected , 05/31/2006 20:17:24.989618
  Heartbeats missed      = 0
  Local host             = server2.torolab.ibm.com
  Local service          = 80000
  Remote host            = server1.torolab.ibm.com
  Remote service         = 70000
  Remote instance        = db2inst1
  timeout(seconds)       = 120
  Primary log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Standby log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Log gap running average(bytes) = 0

在执行接管操作之后，如果出故障的数据库又可以使用，它不会自动恢复主数据库的角色。

通过以下步骤可以使之重新成为主数据库：

修复原来的主数据库所在的系统。这包括修复有问题的硬件或者重新启动崩溃的操作系统。
重新启动出故障的主数据库，使之成为一个备用数据库。
执行一个接管操作，使之接管主数据库的角色。

当原来的主数据库重新以备用数据库的角色加入 HADR 对之后，执行一个接管操作来切换数据库的角色，使原来的主数据库再次成为主数据库。

为了停止 TEST1 数据库上的 HADR，发出：

STOP HADR ON DB test1

您可以看到，HADR 是实现高可用性解决方案的一个强大的特性。提供了一个名为 HADR 向导的图形化用户界面工具，以帮助您设置和配置 HADR。

如果选择 Set Up，那么就会打开一个如图 15 所示的逐步向导。

如果使用 Control Center 设置 HADR 环境，则会自动启用自动客户机重路由特性。

阅读(23807) | 评论(0) | 转发(0) |

上一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（4）

下一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（6）

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

16024965号-6

高可用性灾难恢复（HADR）

DB2 高可用性灾难恢复（HADR）是一种数据库复制特性，它提供了一种高可用性解决方案。目前，HADR 只用于单分区数据库环境。

为了设置 HADR 环境，要更新一些数据库配置参数。

首先，必须启用主数据库上的归档日志记录。请参阅备份和恢复教程，以了解如何启用归档日志记录。

表 1 列出了与 HADR 相关的数据库配置参数的描述。本教程后面将给出一个关于如何更新这些参数的例子。

与 HADR 相关的数据库配置参数	描述
HADR_LOCAL_HOST	指定 HADR TCPIP 通信的本地主机。主机名和 IP 地址都可以使用
HADR_LOCAL_SVC	指定 TCPIP 服务名和端口号，HADR 进程将在本地主机上接受该服务或端口的连接。这个端口不能与 HADR 实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_HOST	指定远程 HADR 节点的 TCPIP 主机名或 IP 地址
HADR_REMOTE_SVC	指定 TCPIP 服务名或端口号，HADR 进程将在远程节点上接受该服务或端口的连接。这个端口不能与远程实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_INST	指定远程服务器的实例名。DB2 Control Center 之类的管理工具将使用这个参数与远程服务器联系
HADR_TIMEOUT	HADR 进程在认为一次通信尝试失败之前所等待的时间（以秒为单位）。默认值为 120 秒
HADR_SYNCMODE	指定同步模式。它决定当系统处于对等状态时，主日志写与备用数据库如何同步。有效值有 SYNC、NEARSYNC 和 ASYNC。默认值为 NEARSYNC。（本节后面将讨论对等状态）。
HADR_DB_ROLE	指定一个数据库当前的角色。有效值有 STANDARD、PRIMARY 和 STANDBY。STANDARD 意味着数据库没有启用 HADR。

当备用数据库第一次启动时，它进入 local catch-up 状态。本地日志路径中的日志文件（如果有的话）将被读取，并应用到备用数据库。

当到达本地日志文件的最后时，备用数据库进入 remote catch-up 状态。它重演主数据库的归档日志和活动日志，直到备用数据库应用了最近的活动日志。

当主系统上的所有日志文件都已经被重演时，主数据库和备用数据库就进入对等（peer）状态。

在同步模式中，日志写只有在以下情况下才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库的日志文件中。

主数据库与备用数据库中的日志记录几乎（或近似）是同步的，因为只有在以下情况下，日志写才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库上的主存中。

在这种模式下，主数据库不等待收到备用数据库的通知。只有在以下情况下，日志写才被认为是成功的：

日志记录已经被写到主数据库上的日志文件中。
日志记录已经被传送到备用数据库；不需要通知。

HADR 是通过以下三个简单的命令来管理的：

START HADR
STOP HADR
TAKENOVER HADR

这些命令的语法如下：

START HADR ON DATABASE database-alias
[USER userid] [USING password] 
AS PRIMARY | STANDBY [BY FORCE]

STOP HADR ON DATABASE database-alias 
[USER userid] [USING password] 

TAKEOVER HADR ON DATABASE database-alias
[USER userid] [USING password] 
[BY FORCE]

您已经学习了 HADR 的概念，现在可以学习如何设置 HADR 环境。

使用另一个数据库服务器 server2.torolab.ibm.com 作为备用服务器。TEST1 当前不在备用服务器上。

服务名	实例名	SVCENAME 或端口号	数据库名
server1.torolab.ibm.com	DB2INST1	50000	TEST1
server2.torolab.ibm.com	DB2INST1	50000	--

第一次初始化 HADR 时，执行图 13 所示的五个步骤：

确定主服务器和备用服务器。决定主机名、主机 IP 地址和每个 HADR 数据库的服务名或端口号。
您已经确定了主服务器和备用服务器。主服务器是 server1。备用服务器是 server2。

确保这两个服务器是通过 TCPIP 相互通信的。尝试用主机名在这两个服务器上相互 ping 对方。应确保输出没有错误。如果主机名不能使用，那么尝试使用它们的 TCPIP 地址。选用两者中最好用的一种用于 HADR 配置。

通过克隆主数据库创建备用数据库。

有两种方案可用于克隆主数据库：

一种方案是为主数据库做一个备份，并在备用数据库上恢复这个数据库备份。这种方案使用标准备份和恢复方法。
克隆主数据库的另一种方案是使用分割镜像。为主数据库做一个分割镜像，然后在备用服务器上初始化该分割镜像。当初始化分割镜像时，必须在 db2inidb 命令中使用 standby 选项，以便使用 mirror 和 snapshot 选项。

在这个例子种，使用备份/恢复方法来创建备用数据库。

首先为 server1 上的主数据库 TEST1 做一个备份：

BACKUP DB test1

接着，通过 ftp 将备份镜像传送到备用服务器，并恢复该备份镜像。

将备份镜像恢复到与主服务器上相同的位置。在主服务器上，发出 LIST DB DIRECTORY 命令将显示：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            =
 Alternate server port number         =

数据库位于主服务器上的 C: 盘上。当在备用服务器上恢复备份镜像时，也将它恢复到 C: 盘。在备用服务器 server2 上，发出以下命令来恢复 TEST1 数据库：

RESTORE DB test1 ON C:

在主数据库和备用数据库上设置以下 HADR 配置参数：

HADR_LOCAL_HOST
HADR_LOCAL_SVC
HADR_REMOTE_HOST
HADR_REMOTE_SVC
HADR_REMOTE_INST
HADR_SYNCMODE
LOGINDEXBUILD

在主服务器上，为 HADR 使用端口号 70000。更新 Windows\System32\drivers\etc\services 文件，在其中添加以下一行：

Hadr_port 	70000/tcp

在备用服务器上的 services 文件中添加以下一行：

Hadr_port 	80000/tcp

为 HADR_SYNCMODE 使用默认值，即 NEARSYNC。

您已经有了配置 HADR 参数所需的所有信息。发出以下命令来配置备用服务器上的参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在主数据库服务器上，配置相同的一组参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在备用数据库上使用 START HADR 命令启动 HADR：
START HADR ON DB test1 AS STANDBY
在启动主数据库之前启动备用数据库。如果先启动主数据库，那么，如果没有在 HADR_TIMEOUT 数据库配置参数指定的期限内启动备用数据库，那么主数据库的启动过程就会失败。
在主数据库上启动 HADR，如下面的例子所示：
START HADR ON DB test1 AS PRIMARY
HADR 现在已经在主数据库和备用数据库上启动了。

当第一次启动主服务器时，它等待备用服务器与它联系。如果在指定期限内备用服务器没有与主服务器联系，那么 HADR 将不启动。这个期限可以用 HADR_TIMEOUT 配置参数（见表 1）来配置。这样做的目的是避免两个系统在偶然的情况下与主服务器同时启动。

在 HADR 启动过程中，数据库经历以下状态：local catch-up、remote catch-up pending、remote catch-up 和对等状态。日志被自动从主服务器传送到备用服务器，然后在备用服务器上重演。这是为了确保备用数据库跟上主数据库的变化。

强烈建议在主数据库和备用数据库所在的系统上使用相同的数据库配置参数和数据库管理器配置参数。否则，备用数据库就不会像主数据库一样执行。

一个例外是 LOGFILSIZ 数据库配置参数。这个参数的值被备用服务器所忽略。备用服务器自动创建与主数据库上的日志文件大小相匹配的日志文件。这保证了两个数据库上的日志文件是一致的。

在主数据库与备用数据库之间切换数据库角色，也就是说，备用数据库变成主数据库，主数据库变成备用数据库。
从主数据库故障转移到备用数据库。

   GET SNAPSHOT FOR DATABASE ON test1

下面的命令在备用数据库 TEST1 上开始 HADR 数据库切换角色操作：

   TAKEOVER HADR ON DB test1

故障转移方案不切换数据库角色。在故障转移操作期间，备用数据库接管主数据库角色，但是主数据库不会变成备用数据库。

下面的命令在数据库 TEST1 上开始一个 HADR 故障转移操作：

   TAKEOVER HADR ON DB test1 BY FORCE

表 3 和 4 总结了在备用数据库上发出的 TAKEOVER HADR 命令的行为，以及备用数据库所处的对应的 HADR 状态：

备用数据库的状态	接管行为
对等	主数据库和备用数据库都切换角色
Local catch-up or remote catch-up	错误
Remote catch-up pending	错误

备用数据库的状态	接管行为
对等	备用数据库通知主数据库关闭。备用数据库停止接收来自主数据库的日志，完成它已经收到的日志的重演，然后变成主数据库。备用数据库不用等到主数据库发来通知确认它受到接管通知或者它已经关闭
Local catch-up OR remote catch-up	错误
Remote catch-up pending	备用数据库变成主数据库

您已经看到了如何设置 HADR 环境，以及如何使用数据库角色切换和故障转移方案执行接管。

您学习了如何使用 HADR 使数据库具有高可用性。如果主数据库停机，那么它的备用数据库将接管，并成为新的主数据库。

为了启用自动客户机重路由特性，在主数据库上发出 UPDATE ALTERNATE SERVER 命令。该命令的语法如下：

UPDATE ALTERNATE SERVER FOR DATABASE database-alias
USING HOSTNAME alternate-server-hostname PORT port-number

为了在 server1 上的 TEST1 数据库上启用客户机重路由特性，以便在接管之后已有的和新的客户机连接被重新路由到 server2，在 server1 上发出以下命令：

UPDATE ALTERNATE SERVER FOR DATABASE test1 USING 
HOSTNAME server2.torolab.ibm.com PORT 50000

在这个例子中，50000 是 SVCENAME 端口，而不是 HADR 端口。

备用服务器信息存储在 server1 的数据库目录中。如果发出一个 LIST DB DIRECTORY 命令，那么可以注意到备用服务器信息（主机名和端口号）已经被添加：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

现在让我们来看一个关于如何在启用了自动客户机重路由特性的数据库上执行接管的例子。

在这个例子中，不带 BY FORCE 选项执行一个接管。

首先，建立到 server1 上的 TEST1 数据库的一个远程客户机连接。为此，只需在一个远程 DB2 客户机上发出一条 CONNECT TO DATABASE 命令：

CONNECT TO DB test1 USER user1

为了建立那样的连接，客户机必须已经被配置为连接到 server1。关于如何配置远程客户机连接的信息，请参考本系列中的第一篇教程。

在建立连接之后，主服务器上的备用服务器信息被获取并存储在客户机的数据库目录中：

 Database alias                       = TEST1
 Database name                        = TEST1
 Node name                            = server1
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Remote
 Catalog database partition number    = -1
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

确保该连接已成功建立，并且可以查询 TEST1 数据库。在 server1 上发出一条 LIST APPLICATION 命令，它应该显示数据库 TEST1 上的远程客户机连接：

D:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      8          9.26.94.149.24336.060601000305
                                                         TEST1    1

接着，在 TEST1 数据库上执行接管。在备用服务器 server2 上发出以下命令：

TAKEOVER HADR ON DB test1

让我们看看这次接管完成后远程客户机连接有什么变化。

再次尝试从客户机查询 TEST1 数据库。对 TEST1 数据库的任何查询应该都会返回一个错误消息。例如，从客户机连接发出一条 LIST TABLES 命令：

D:\Programs\IBM\SQLLIB\BIN>db2 list tables
SQL30108N A connection failed but has been re-established. 
The hostname or IP address is "server2" and the service name or port number is "50000". 
Special registers may or may not be re-attempted (Reason code = "1").  
SQLSTATE=08506

这证明客户机重路由特性在起作用。现在您已经连接到新的主服务器，即 server2。

在 server2 上发出一条 LIST APPLICATIONS 命令。您可以看到，远程客户机连接已经被重新路由到那里：

H:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      55         9.26.94.149.29200.060601001803
                                                         TEST1    1

如果再次查询数据库，那么可以从新的主服务器得到一个响应。而且，到原来主服务器的新连接也被重新路由到新的主服务器。

使用 GET SNAPSHOT 命令可以获得数据库的 HADR 状态。在 server2 上发出以下命令，应该可以看到 server2 已经接管了主数据库角色：

db2 "get snapshot for database on test1"

  HADR Status
  Role                   = Primary
  State                  = Peer
  Synchronization mode   = Nearsync
  Connection status      = Connected , 05/31/2006 20:17:24.989618
  Heartbeats missed      = 0
  Local host             = server2.torolab.ibm.com
  Local service          = 80000
  Remote host            = server1.torolab.ibm.com
  Remote service         = 70000
  Remote instance        = db2inst1
  timeout(seconds)       = 120
  Primary log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Standby log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Log gap running average(bytes) = 0

在执行接管操作之后，如果出故障的数据库又可以使用，它不会自动恢复主数据库的角色。

通过以下步骤可以使之重新成为主数据库：

修复原来的主数据库所在的系统。这包括修复有问题的硬件或者重新启动崩溃的操作系统。
重新启动出故障的主数据库，使之成为一个备用数据库。
执行一个接管操作，使之接管主数据库的角色。

当原来的主数据库重新以备用数据库的角色加入 HADR 对之后，执行一个接管操作来切换数据库的角色，使原来的主数据库再次成为主数据库。

为了停止 TEST1 数据库上的 HADR，发出：

STOP HADR ON DB test1

您可以看到，HADR 是实现高可用性解决方案的一个强大的特性。提供了一个名为 HADR 向导的图形化用户界面工具，以帮助您设置和配置 HADR。

如果选择 Set Up，那么就会打开一个如图 15 所示的逐步向导。

如果使用 Control Center 设置 HADR 环境，则会自动启用自动客户机重路由特性。

阅读(23806) | 评论(0) | 转发(0) |

上一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（4）

下一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（6）

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

16024965号-6

高可用性灾难恢复（HADR）

DB2 高可用性灾难恢复（HADR）是一种数据库复制特性，它提供了一种高可用性解决方案。目前，HADR 只用于单分区数据库环境。

为了设置 HADR 环境，要更新一些数据库配置参数。

首先，必须启用主数据库上的归档日志记录。请参阅备份和恢复教程，以了解如何启用归档日志记录。

表 1 列出了与 HADR 相关的数据库配置参数的描述。本教程后面将给出一个关于如何更新这些参数的例子。

与 HADR 相关的数据库配置参数	描述
HADR_LOCAL_HOST	指定 HADR TCPIP 通信的本地主机。主机名和 IP 地址都可以使用
HADR_LOCAL_SVC	指定 TCPIP 服务名和端口号，HADR 进程将在本地主机上接受该服务或端口的连接。这个端口不能与 HADR 实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_HOST	指定远程 HADR 节点的 TCPIP 主机名或 IP 地址
HADR_REMOTE_SVC	指定 TCPIP 服务名或端口号，HADR 进程将在远程节点上接受该服务或端口的连接。这个端口不能与远程实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_INST	指定远程服务器的实例名。DB2 Control Center 之类的管理工具将使用这个参数与远程服务器联系
HADR_TIMEOUT	HADR 进程在认为一次通信尝试失败之前所等待的时间（以秒为单位）。默认值为 120 秒
HADR_SYNCMODE	指定同步模式。它决定当系统处于对等状态时，主日志写与备用数据库如何同步。有效值有 SYNC、NEARSYNC 和 ASYNC。默认值为 NEARSYNC。（本节后面将讨论对等状态）。
HADR_DB_ROLE	指定一个数据库当前的角色。有效值有 STANDARD、PRIMARY 和 STANDBY。STANDARD 意味着数据库没有启用 HADR。

当备用数据库第一次启动时，它进入 local catch-up 状态。本地日志路径中的日志文件（如果有的话）将被读取，并应用到备用数据库。

当到达本地日志文件的最后时，备用数据库进入 remote catch-up 状态。它重演主数据库的归档日志和活动日志，直到备用数据库应用了最近的活动日志。

当主系统上的所有日志文件都已经被重演时，主数据库和备用数据库就进入对等（peer）状态。

在同步模式中，日志写只有在以下情况下才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库的日志文件中。

主数据库与备用数据库中的日志记录几乎（或近似）是同步的，因为只有在以下情况下，日志写才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库上的主存中。

在这种模式下，主数据库不等待收到备用数据库的通知。只有在以下情况下，日志写才被认为是成功的：

日志记录已经被写到主数据库上的日志文件中。
日志记录已经被传送到备用数据库；不需要通知。

HADR 是通过以下三个简单的命令来管理的：

START HADR
STOP HADR
TAKENOVER HADR

这些命令的语法如下：

START HADR ON DATABASE database-alias
[USER userid] [USING password] 
AS PRIMARY | STANDBY [BY FORCE]

STOP HADR ON DATABASE database-alias 
[USER userid] [USING password] 

TAKEOVER HADR ON DATABASE database-alias
[USER userid] [USING password] 
[BY FORCE]

您已经学习了 HADR 的概念，现在可以学习如何设置 HADR 环境。

使用另一个数据库服务器 server2.torolab.ibm.com 作为备用服务器。TEST1 当前不在备用服务器上。

服务名	实例名	SVCENAME 或端口号	数据库名
server1.torolab.ibm.com	DB2INST1	50000	TEST1
server2.torolab.ibm.com	DB2INST1	50000	--

第一次初始化 HADR 时，执行图 13 所示的五个步骤：

确定主服务器和备用服务器。决定主机名、主机 IP 地址和每个 HADR 数据库的服务名或端口号。
您已经确定了主服务器和备用服务器。主服务器是 server1。备用服务器是 server2。

确保这两个服务器是通过 TCPIP 相互通信的。尝试用主机名在这两个服务器上相互 ping 对方。应确保输出没有错误。如果主机名不能使用，那么尝试使用它们的 TCPIP 地址。选用两者中最好用的一种用于 HADR 配置。

通过克隆主数据库创建备用数据库。

有两种方案可用于克隆主数据库：

一种方案是为主数据库做一个备份，并在备用数据库上恢复这个数据库备份。这种方案使用标准备份和恢复方法。
克隆主数据库的另一种方案是使用分割镜像。为主数据库做一个分割镜像，然后在备用服务器上初始化该分割镜像。当初始化分割镜像时，必须在 db2inidb 命令中使用 standby 选项，以便使用 mirror 和 snapshot 选项。

在这个例子种，使用备份/恢复方法来创建备用数据库。

首先为 server1 上的主数据库 TEST1 做一个备份：

BACKUP DB test1

接着，通过 ftp 将备份镜像传送到备用服务器，并恢复该备份镜像。

将备份镜像恢复到与主服务器上相同的位置。在主服务器上，发出 LIST DB DIRECTORY 命令将显示：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            =
 Alternate server port number         =

数据库位于主服务器上的 C: 盘上。当在备用服务器上恢复备份镜像时，也将它恢复到 C: 盘。在备用服务器 server2 上，发出以下命令来恢复 TEST1 数据库：

RESTORE DB test1 ON C:

在主数据库和备用数据库上设置以下 HADR 配置参数：

HADR_LOCAL_HOST
HADR_LOCAL_SVC
HADR_REMOTE_HOST
HADR_REMOTE_SVC
HADR_REMOTE_INST
HADR_SYNCMODE
LOGINDEXBUILD

在主服务器上，为 HADR 使用端口号 70000。更新 Windows\System32\drivers\etc\services 文件，在其中添加以下一行：

Hadr_port 	70000/tcp

在备用服务器上的 services 文件中添加以下一行：

Hadr_port 	80000/tcp

为 HADR_SYNCMODE 使用默认值，即 NEARSYNC。

您已经有了配置 HADR 参数所需的所有信息。发出以下命令来配置备用服务器上的参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在主数据库服务器上，配置相同的一组参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在备用数据库上使用 START HADR 命令启动 HADR：
START HADR ON DB test1 AS STANDBY
在启动主数据库之前启动备用数据库。如果先启动主数据库，那么，如果没有在 HADR_TIMEOUT 数据库配置参数指定的期限内启动备用数据库，那么主数据库的启动过程就会失败。
在主数据库上启动 HADR，如下面的例子所示：
START HADR ON DB test1 AS PRIMARY
HADR 现在已经在主数据库和备用数据库上启动了。

当第一次启动主服务器时，它等待备用服务器与它联系。如果在指定期限内备用服务器没有与主服务器联系，那么 HADR 将不启动。这个期限可以用 HADR_TIMEOUT 配置参数（见表 1）来配置。这样做的目的是避免两个系统在偶然的情况下与主服务器同时启动。

在 HADR 启动过程中，数据库经历以下状态：local catch-up、remote catch-up pending、remote catch-up 和对等状态。日志被自动从主服务器传送到备用服务器，然后在备用服务器上重演。这是为了确保备用数据库跟上主数据库的变化。

强烈建议在主数据库和备用数据库所在的系统上使用相同的数据库配置参数和数据库管理器配置参数。否则，备用数据库就不会像主数据库一样执行。

一个例外是 LOGFILSIZ 数据库配置参数。这个参数的值被备用服务器所忽略。备用服务器自动创建与主数据库上的日志文件大小相匹配的日志文件。这保证了两个数据库上的日志文件是一致的。

在主数据库与备用数据库之间切换数据库角色，也就是说，备用数据库变成主数据库，主数据库变成备用数据库。
从主数据库故障转移到备用数据库。

   GET SNAPSHOT FOR DATABASE ON test1

下面的命令在备用数据库 TEST1 上开始 HADR 数据库切换角色操作：

   TAKEOVER HADR ON DB test1

故障转移方案不切换数据库角色。在故障转移操作期间，备用数据库接管主数据库角色，但是主数据库不会变成备用数据库。

下面的命令在数据库 TEST1 上开始一个 HADR 故障转移操作：

   TAKEOVER HADR ON DB test1 BY FORCE

表 3 和 4 总结了在备用数据库上发出的 TAKEOVER HADR 命令的行为，以及备用数据库所处的对应的 HADR 状态：

备用数据库的状态	接管行为
对等	主数据库和备用数据库都切换角色
Local catch-up or remote catch-up	错误
Remote catch-up pending	错误

备用数据库的状态	接管行为
对等	备用数据库通知主数据库关闭。备用数据库停止接收来自主数据库的日志，完成它已经收到的日志的重演，然后变成主数据库。备用数据库不用等到主数据库发来通知确认它受到接管通知或者它已经关闭
Local catch-up OR remote catch-up	错误
Remote catch-up pending	备用数据库变成主数据库

您已经看到了如何设置 HADR 环境，以及如何使用数据库角色切换和故障转移方案执行接管。

您学习了如何使用 HADR 使数据库具有高可用性。如果主数据库停机，那么它的备用数据库将接管，并成为新的主数据库。

为了启用自动客户机重路由特性，在主数据库上发出 UPDATE ALTERNATE SERVER 命令。该命令的语法如下：

UPDATE ALTERNATE SERVER FOR DATABASE database-alias
USING HOSTNAME alternate-server-hostname PORT port-number

为了在 server1 上的 TEST1 数据库上启用客户机重路由特性，以便在接管之后已有的和新的客户机连接被重新路由到 server2，在 server1 上发出以下命令：

UPDATE ALTERNATE SERVER FOR DATABASE test1 USING 
HOSTNAME server2.torolab.ibm.com PORT 50000

在这个例子中，50000 是 SVCENAME 端口，而不是 HADR 端口。

备用服务器信息存储在 server1 的数据库目录中。如果发出一个 LIST DB DIRECTORY 命令，那么可以注意到备用服务器信息（主机名和端口号）已经被添加：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

现在让我们来看一个关于如何在启用了自动客户机重路由特性的数据库上执行接管的例子。

在这个例子中，不带 BY FORCE 选项执行一个接管。

首先，建立到 server1 上的 TEST1 数据库的一个远程客户机连接。为此，只需在一个远程 DB2 客户机上发出一条 CONNECT TO DATABASE 命令：

CONNECT TO DB test1 USER user1

为了建立那样的连接，客户机必须已经被配置为连接到 server1。关于如何配置远程客户机连接的信息，请参考本系列中的第一篇教程。

在建立连接之后，主服务器上的备用服务器信息被获取并存储在客户机的数据库目录中：

 Database alias                       = TEST1
 Database name                        = TEST1
 Node name                            = server1
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Remote
 Catalog database partition number    = -1
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

确保该连接已成功建立，并且可以查询 TEST1 数据库。在 server1 上发出一条 LIST APPLICATION 命令，它应该显示数据库 TEST1 上的远程客户机连接：

D:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      8          9.26.94.149.24336.060601000305
                                                         TEST1    1

接着，在 TEST1 数据库上执行接管。在备用服务器 server2 上发出以下命令：

TAKEOVER HADR ON DB test1

让我们看看这次接管完成后远程客户机连接有什么变化。

再次尝试从客户机查询 TEST1 数据库。对 TEST1 数据库的任何查询应该都会返回一个错误消息。例如，从客户机连接发出一条 LIST TABLES 命令：

D:\Programs\IBM\SQLLIB\BIN>db2 list tables
SQL30108N A connection failed but has been re-established. 
The hostname or IP address is "server2" and the service name or port number is "50000". 
Special registers may or may not be re-attempted (Reason code = "1").  
SQLSTATE=08506

这证明客户机重路由特性在起作用。现在您已经连接到新的主服务器，即 server2。

在 server2 上发出一条 LIST APPLICATIONS 命令。您可以看到，远程客户机连接已经被重新路由到那里：

H:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      55         9.26.94.149.29200.060601001803
                                                         TEST1    1

如果再次查询数据库，那么可以从新的主服务器得到一个响应。而且，到原来主服务器的新连接也被重新路由到新的主服务器。

使用 GET SNAPSHOT 命令可以获得数据库的 HADR 状态。在 server2 上发出以下命令，应该可以看到 server2 已经接管了主数据库角色：

db2 "get snapshot for database on test1"

  HADR Status
  Role                   = Primary
  State                  = Peer
  Synchronization mode   = Nearsync
  Connection status      = Connected , 05/31/2006 20:17:24.989618
  Heartbeats missed      = 0
  Local host             = server2.torolab.ibm.com
  Local service          = 80000
  Remote host            = server1.torolab.ibm.com
  Remote service         = 70000
  Remote instance        = db2inst1
  timeout(seconds)       = 120
  Primary log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Standby log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Log gap running average(bytes) = 0

在执行接管操作之后，如果出故障的数据库又可以使用，它不会自动恢复主数据库的角色。

通过以下步骤可以使之重新成为主数据库：

修复原来的主数据库所在的系统。这包括修复有问题的硬件或者重新启动崩溃的操作系统。
重新启动出故障的主数据库，使之成为一个备用数据库。
执行一个接管操作，使之接管主数据库的角色。

当原来的主数据库重新以备用数据库的角色加入 HADR 对之后，执行一个接管操作来切换数据库的角色，使原来的主数据库再次成为主数据库。

为了停止 TEST1 数据库上的 HADR，发出：

STOP HADR ON DB test1

您可以看到，HADR 是实现高可用性解决方案的一个强大的特性。提供了一个名为 HADR 向导的图形化用户界面工具，以帮助您设置和配置 HADR。

如果选择 Set Up，那么就会打开一个如图 15 所示的逐步向导。

如果使用 Control Center 设置 HADR 环境，则会自动启用自动客户机重路由特性。

阅读(23805) | 评论(0) | 转发(0) |

上一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（4）

下一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（6）

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

16024965号-6

高可用性灾难恢复（HADR）

DB2 高可用性灾难恢复（HADR）是一种数据库复制特性，它提供了一种高可用性解决方案。目前，HADR 只用于单分区数据库环境。

为了设置 HADR 环境，要更新一些数据库配置参数。

首先，必须启用主数据库上的归档日志记录。请参阅备份和恢复教程，以了解如何启用归档日志记录。

表 1 列出了与 HADR 相关的数据库配置参数的描述。本教程后面将给出一个关于如何更新这些参数的例子。

与 HADR 相关的数据库配置参数	描述
HADR_LOCAL_HOST	指定 HADR TCPIP 通信的本地主机。主机名和 IP 地址都可以使用
HADR_LOCAL_SVC	指定 TCPIP 服务名和端口号，HADR 进程将在本地主机上接受该服务或端口的连接。这个端口不能与 HADR 实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_HOST	指定远程 HADR 节点的 TCPIP 主机名或 IP 地址
HADR_REMOTE_SVC	指定 TCPIP 服务名或端口号，HADR 进程将在远程节点上接受该服务或端口的连接。这个端口不能与远程实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_INST	指定远程服务器的实例名。DB2 Control Center 之类的管理工具将使用这个参数与远程服务器联系
HADR_TIMEOUT	HADR 进程在认为一次通信尝试失败之前所等待的时间（以秒为单位）。默认值为 120 秒
HADR_SYNCMODE	指定同步模式。它决定当系统处于对等状态时，主日志写与备用数据库如何同步。有效值有 SYNC、NEARSYNC 和 ASYNC。默认值为 NEARSYNC。（本节后面将讨论对等状态）。
HADR_DB_ROLE	指定一个数据库当前的角色。有效值有 STANDARD、PRIMARY 和 STANDBY。STANDARD 意味着数据库没有启用 HADR。

当备用数据库第一次启动时，它进入 local catch-up 状态。本地日志路径中的日志文件（如果有的话）将被读取，并应用到备用数据库。

当到达本地日志文件的最后时，备用数据库进入 remote catch-up 状态。它重演主数据库的归档日志和活动日志，直到备用数据库应用了最近的活动日志。

当主系统上的所有日志文件都已经被重演时，主数据库和备用数据库就进入对等（peer）状态。

在同步模式中，日志写只有在以下情况下才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库的日志文件中。

主数据库与备用数据库中的日志记录几乎（或近似）是同步的，因为只有在以下情况下，日志写才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库上的主存中。

在这种模式下，主数据库不等待收到备用数据库的通知。只有在以下情况下，日志写才被认为是成功的：

日志记录已经被写到主数据库上的日志文件中。
日志记录已经被传送到备用数据库；不需要通知。

HADR 是通过以下三个简单的命令来管理的：

START HADR
STOP HADR
TAKENOVER HADR

这些命令的语法如下：

START HADR ON DATABASE database-alias
[USER userid] [USING password] 
AS PRIMARY | STANDBY [BY FORCE]

STOP HADR ON DATABASE database-alias 
[USER userid] [USING password] 

TAKEOVER HADR ON DATABASE database-alias
[USER userid] [USING password] 
[BY FORCE]

您已经学习了 HADR 的概念，现在可以学习如何设置 HADR 环境。

使用另一个数据库服务器 server2.torolab.ibm.com 作为备用服务器。TEST1 当前不在备用服务器上。

服务名	实例名	SVCENAME 或端口号	数据库名
server1.torolab.ibm.com	DB2INST1	50000	TEST1
server2.torolab.ibm.com	DB2INST1	50000	--

第一次初始化 HADR 时，执行图 13 所示的五个步骤：

确定主服务器和备用服务器。决定主机名、主机 IP 地址和每个 HADR 数据库的服务名或端口号。
您已经确定了主服务器和备用服务器。主服务器是 server1。备用服务器是 server2。

确保这两个服务器是通过 TCPIP 相互通信的。尝试用主机名在这两个服务器上相互 ping 对方。应确保输出没有错误。如果主机名不能使用，那么尝试使用它们的 TCPIP 地址。选用两者中最好用的一种用于 HADR 配置。

通过克隆主数据库创建备用数据库。

有两种方案可用于克隆主数据库：

一种方案是为主数据库做一个备份，并在备用数据库上恢复这个数据库备份。这种方案使用标准备份和恢复方法。
克隆主数据库的另一种方案是使用分割镜像。为主数据库做一个分割镜像，然后在备用服务器上初始化该分割镜像。当初始化分割镜像时，必须在 db2inidb 命令中使用 standby 选项，以便使用 mirror 和 snapshot 选项。

在这个例子种，使用备份/恢复方法来创建备用数据库。

首先为 server1 上的主数据库 TEST1 做一个备份：

BACKUP DB test1

接着，通过 ftp 将备份镜像传送到备用服务器，并恢复该备份镜像。

将备份镜像恢复到与主服务器上相同的位置。在主服务器上，发出 LIST DB DIRECTORY 命令将显示：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            =
 Alternate server port number         =

数据库位于主服务器上的 C: 盘上。当在备用服务器上恢复备份镜像时，也将它恢复到 C: 盘。在备用服务器 server2 上，发出以下命令来恢复 TEST1 数据库：

RESTORE DB test1 ON C:

在主数据库和备用数据库上设置以下 HADR 配置参数：

HADR_LOCAL_HOST
HADR_LOCAL_SVC
HADR_REMOTE_HOST
HADR_REMOTE_SVC
HADR_REMOTE_INST
HADR_SYNCMODE
LOGINDEXBUILD

在主服务器上，为 HADR 使用端口号 70000。更新 Windows\System32\drivers\etc\services 文件，在其中添加以下一行：

Hadr_port 	70000/tcp

在备用服务器上的 services 文件中添加以下一行：

Hadr_port 	80000/tcp

为 HADR_SYNCMODE 使用默认值，即 NEARSYNC。

您已经有了配置 HADR 参数所需的所有信息。发出以下命令来配置备用服务器上的参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在主数据库服务器上，配置相同的一组参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在备用数据库上使用 START HADR 命令启动 HADR：
START HADR ON DB test1 AS STANDBY
在启动主数据库之前启动备用数据库。如果先启动主数据库，那么，如果没有在 HADR_TIMEOUT 数据库配置参数指定的期限内启动备用数据库，那么主数据库的启动过程就会失败。
在主数据库上启动 HADR，如下面的例子所示：
START HADR ON DB test1 AS PRIMARY
HADR 现在已经在主数据库和备用数据库上启动了。

当第一次启动主服务器时，它等待备用服务器与它联系。如果在指定期限内备用服务器没有与主服务器联系，那么 HADR 将不启动。这个期限可以用 HADR_TIMEOUT 配置参数（见表 1）来配置。这样做的目的是避免两个系统在偶然的情况下与主服务器同时启动。

在 HADR 启动过程中，数据库经历以下状态：local catch-up、remote catch-up pending、remote catch-up 和对等状态。日志被自动从主服务器传送到备用服务器，然后在备用服务器上重演。这是为了确保备用数据库跟上主数据库的变化。

强烈建议在主数据库和备用数据库所在的系统上使用相同的数据库配置参数和数据库管理器配置参数。否则，备用数据库就不会像主数据库一样执行。

一个例外是 LOGFILSIZ 数据库配置参数。这个参数的值被备用服务器所忽略。备用服务器自动创建与主数据库上的日志文件大小相匹配的日志文件。这保证了两个数据库上的日志文件是一致的。

在主数据库与备用数据库之间切换数据库角色，也就是说，备用数据库变成主数据库，主数据库变成备用数据库。
从主数据库故障转移到备用数据库。

   GET SNAPSHOT FOR DATABASE ON test1

下面的命令在备用数据库 TEST1 上开始 HADR 数据库切换角色操作：

   TAKEOVER HADR ON DB test1

故障转移方案不切换数据库角色。在故障转移操作期间，备用数据库接管主数据库角色，但是主数据库不会变成备用数据库。

下面的命令在数据库 TEST1 上开始一个 HADR 故障转移操作：

   TAKEOVER HADR ON DB test1 BY FORCE

表 3 和 4 总结了在备用数据库上发出的 TAKEOVER HADR 命令的行为，以及备用数据库所处的对应的 HADR 状态：

备用数据库的状态	接管行为
对等	主数据库和备用数据库都切换角色
Local catch-up or remote catch-up	错误
Remote catch-up pending	错误

备用数据库的状态	接管行为
对等	备用数据库通知主数据库关闭。备用数据库停止接收来自主数据库的日志，完成它已经收到的日志的重演，然后变成主数据库。备用数据库不用等到主数据库发来通知确认它受到接管通知或者它已经关闭
Local catch-up OR remote catch-up	错误
Remote catch-up pending	备用数据库变成主数据库

您已经看到了如何设置 HADR 环境，以及如何使用数据库角色切换和故障转移方案执行接管。

您学习了如何使用 HADR 使数据库具有高可用性。如果主数据库停机，那么它的备用数据库将接管，并成为新的主数据库。

为了启用自动客户机重路由特性，在主数据库上发出 UPDATE ALTERNATE SERVER 命令。该命令的语法如下：

UPDATE ALTERNATE SERVER FOR DATABASE database-alias
USING HOSTNAME alternate-server-hostname PORT port-number

为了在 server1 上的 TEST1 数据库上启用客户机重路由特性，以便在接管之后已有的和新的客户机连接被重新路由到 server2，在 server1 上发出以下命令：

UPDATE ALTERNATE SERVER FOR DATABASE test1 USING 
HOSTNAME server2.torolab.ibm.com PORT 50000

在这个例子中，50000 是 SVCENAME 端口，而不是 HADR 端口。

备用服务器信息存储在 server1 的数据库目录中。如果发出一个 LIST DB DIRECTORY 命令，那么可以注意到备用服务器信息（主机名和端口号）已经被添加：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

现在让我们来看一个关于如何在启用了自动客户机重路由特性的数据库上执行接管的例子。

在这个例子中，不带 BY FORCE 选项执行一个接管。

首先，建立到 server1 上的 TEST1 数据库的一个远程客户机连接。为此，只需在一个远程 DB2 客户机上发出一条 CONNECT TO DATABASE 命令：

CONNECT TO DB test1 USER user1

为了建立那样的连接，客户机必须已经被配置为连接到 server1。关于如何配置远程客户机连接的信息，请参考本系列中的第一篇教程。

在建立连接之后，主服务器上的备用服务器信息被获取并存储在客户机的数据库目录中：

 Database alias                       = TEST1
 Database name                        = TEST1
 Node name                            = server1
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Remote
 Catalog database partition number    = -1
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

确保该连接已成功建立，并且可以查询 TEST1 数据库。在 server1 上发出一条 LIST APPLICATION 命令，它应该显示数据库 TEST1 上的远程客户机连接：

D:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      8          9.26.94.149.24336.060601000305
                                                         TEST1    1

接着，在 TEST1 数据库上执行接管。在备用服务器 server2 上发出以下命令：

TAKEOVER HADR ON DB test1

让我们看看这次接管完成后远程客户机连接有什么变化。

再次尝试从客户机查询 TEST1 数据库。对 TEST1 数据库的任何查询应该都会返回一个错误消息。例如，从客户机连接发出一条 LIST TABLES 命令：

D:\Programs\IBM\SQLLIB\BIN>db2 list tables
SQL30108N A connection failed but has been re-established. 
The hostname or IP address is "server2" and the service name or port number is "50000". 
Special registers may or may not be re-attempted (Reason code = "1").  
SQLSTATE=08506

这证明客户机重路由特性在起作用。现在您已经连接到新的主服务器，即 server2。

在 server2 上发出一条 LIST APPLICATIONS 命令。您可以看到，远程客户机连接已经被重新路由到那里：

H:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      55         9.26.94.149.29200.060601001803
                                                         TEST1    1

如果再次查询数据库，那么可以从新的主服务器得到一个响应。而且，到原来主服务器的新连接也被重新路由到新的主服务器。

使用 GET SNAPSHOT 命令可以获得数据库的 HADR 状态。在 server2 上发出以下命令，应该可以看到 server2 已经接管了主数据库角色：

db2 "get snapshot for database on test1"

  HADR Status
  Role                   = Primary
  State                  = Peer
  Synchronization mode   = Nearsync
  Connection status      = Connected , 05/31/2006 20:17:24.989618
  Heartbeats missed      = 0
  Local host             = server2.torolab.ibm.com
  Local service          = 80000
  Remote host            = server1.torolab.ibm.com
  Remote service         = 70000
  Remote instance        = db2inst1
  timeout(seconds)       = 120
  Primary log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Standby log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Log gap running average(bytes) = 0

在执行接管操作之后，如果出故障的数据库又可以使用，它不会自动恢复主数据库的角色。

通过以下步骤可以使之重新成为主数据库：

修复原来的主数据库所在的系统。这包括修复有问题的硬件或者重新启动崩溃的操作系统。
重新启动出故障的主数据库，使之成为一个备用数据库。
执行一个接管操作，使之接管主数据库的角色。

当原来的主数据库重新以备用数据库的角色加入 HADR 对之后，执行一个接管操作来切换数据库的角色，使原来的主数据库再次成为主数据库。

为了停止 TEST1 数据库上的 HADR，发出：

STOP HADR ON DB test1

您可以看到，HADR 是实现高可用性解决方案的一个强大的特性。提供了一个名为 HADR 向导的图形化用户界面工具，以帮助您设置和配置 HADR。

如果选择 Set Up，那么就会打开一个如图 15 所示的逐步向导。

如果使用 Control Center 设置 HADR 环境，则会自动启用自动客户机重路由特性。

阅读(23804) | 评论(0) | 转发(0) |

上一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（4）

下一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（6）

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

16024965号-6

高可用性灾难恢复（HADR）

DB2 高可用性灾难恢复（HADR）是一种数据库复制特性，它提供了一种高可用性解决方案。目前，HADR 只用于单分区数据库环境。

为了设置 HADR 环境，要更新一些数据库配置参数。

首先，必须启用主数据库上的归档日志记录。请参阅备份和恢复教程，以了解如何启用归档日志记录。

表 1 列出了与 HADR 相关的数据库配置参数的描述。本教程后面将给出一个关于如何更新这些参数的例子。

与 HADR 相关的数据库配置参数	描述
HADR_LOCAL_HOST	指定 HADR TCPIP 通信的本地主机。主机名和 IP 地址都可以使用
HADR_LOCAL_SVC	指定 TCPIP 服务名和端口号，HADR 进程将在本地主机上接受该服务或端口的连接。这个端口不能与 HADR 实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_HOST	指定远程 HADR 节点的 TCPIP 主机名或 IP 地址
HADR_REMOTE_SVC	指定 TCPIP 服务名或端口号，HADR 进程将在远程节点上接受该服务或端口的连接。这个端口不能与远程实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_INST	指定远程服务器的实例名。DB2 Control Center 之类的管理工具将使用这个参数与远程服务器联系
HADR_TIMEOUT	HADR 进程在认为一次通信尝试失败之前所等待的时间（以秒为单位）。默认值为 120 秒
HADR_SYNCMODE	指定同步模式。它决定当系统处于对等状态时，主日志写与备用数据库如何同步。有效值有 SYNC、NEARSYNC 和 ASYNC。默认值为 NEARSYNC。（本节后面将讨论对等状态）。
HADR_DB_ROLE	指定一个数据库当前的角色。有效值有 STANDARD、PRIMARY 和 STANDBY。STANDARD 意味着数据库没有启用 HADR。

当备用数据库第一次启动时，它进入 local catch-up 状态。本地日志路径中的日志文件（如果有的话）将被读取，并应用到备用数据库。

当到达本地日志文件的最后时，备用数据库进入 remote catch-up 状态。它重演主数据库的归档日志和活动日志，直到备用数据库应用了最近的活动日志。

当主系统上的所有日志文件都已经被重演时，主数据库和备用数据库就进入对等（peer）状态。

在同步模式中，日志写只有在以下情况下才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库的日志文件中。

主数据库与备用数据库中的日志记录几乎（或近似）是同步的，因为只有在以下情况下，日志写才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库上的主存中。

在这种模式下，主数据库不等待收到备用数据库的通知。只有在以下情况下，日志写才被认为是成功的：

日志记录已经被写到主数据库上的日志文件中。
日志记录已经被传送到备用数据库；不需要通知。

HADR 是通过以下三个简单的命令来管理的：

START HADR
STOP HADR
TAKENOVER HADR

这些命令的语法如下：

START HADR ON DATABASE database-alias
[USER userid] [USING password] 
AS PRIMARY | STANDBY [BY FORCE]

STOP HADR ON DATABASE database-alias 
[USER userid] [USING password] 

TAKEOVER HADR ON DATABASE database-alias
[USER userid] [USING password] 
[BY FORCE]

您已经学习了 HADR 的概念，现在可以学习如何设置 HADR 环境。

使用另一个数据库服务器 server2.torolab.ibm.com 作为备用服务器。TEST1 当前不在备用服务器上。

服务名	实例名	SVCENAME 或端口号	数据库名
server1.torolab.ibm.com	DB2INST1	50000	TEST1
server2.torolab.ibm.com	DB2INST1	50000	--

第一次初始化 HADR 时，执行图 13 所示的五个步骤：

确定主服务器和备用服务器。决定主机名、主机 IP 地址和每个 HADR 数据库的服务名或端口号。
您已经确定了主服务器和备用服务器。主服务器是 server1。备用服务器是 server2。

确保这两个服务器是通过 TCPIP 相互通信的。尝试用主机名在这两个服务器上相互 ping 对方。应确保输出没有错误。如果主机名不能使用，那么尝试使用它们的 TCPIP 地址。选用两者中最好用的一种用于 HADR 配置。

通过克隆主数据库创建备用数据库。

有两种方案可用于克隆主数据库：

一种方案是为主数据库做一个备份，并在备用数据库上恢复这个数据库备份。这种方案使用标准备份和恢复方法。
克隆主数据库的另一种方案是使用分割镜像。为主数据库做一个分割镜像，然后在备用服务器上初始化该分割镜像。当初始化分割镜像时，必须在 db2inidb 命令中使用 standby 选项，以便使用 mirror 和 snapshot 选项。

在这个例子种，使用备份/恢复方法来创建备用数据库。

首先为 server1 上的主数据库 TEST1 做一个备份：

BACKUP DB test1

接着，通过 ftp 将备份镜像传送到备用服务器，并恢复该备份镜像。

将备份镜像恢复到与主服务器上相同的位置。在主服务器上，发出 LIST DB DIRECTORY 命令将显示：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            =
 Alternate server port number         =

数据库位于主服务器上的 C: 盘上。当在备用服务器上恢复备份镜像时，也将它恢复到 C: 盘。在备用服务器 server2 上，发出以下命令来恢复 TEST1 数据库：

RESTORE DB test1 ON C:

在主数据库和备用数据库上设置以下 HADR 配置参数：

HADR_LOCAL_HOST
HADR_LOCAL_SVC
HADR_REMOTE_HOST
HADR_REMOTE_SVC
HADR_REMOTE_INST
HADR_SYNCMODE
LOGINDEXBUILD

在主服务器上，为 HADR 使用端口号 70000。更新 Windows\System32\drivers\etc\services 文件，在其中添加以下一行：

Hadr_port 	70000/tcp

在备用服务器上的 services 文件中添加以下一行：

Hadr_port 	80000/tcp

为 HADR_SYNCMODE 使用默认值，即 NEARSYNC。

您已经有了配置 HADR 参数所需的所有信息。发出以下命令来配置备用服务器上的参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在主数据库服务器上，配置相同的一组参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在备用数据库上使用 START HADR 命令启动 HADR：
START HADR ON DB test1 AS STANDBY
在启动主数据库之前启动备用数据库。如果先启动主数据库，那么，如果没有在 HADR_TIMEOUT 数据库配置参数指定的期限内启动备用数据库，那么主数据库的启动过程就会失败。
在主数据库上启动 HADR，如下面的例子所示：
START HADR ON DB test1 AS PRIMARY
HADR 现在已经在主数据库和备用数据库上启动了。

当第一次启动主服务器时，它等待备用服务器与它联系。如果在指定期限内备用服务器没有与主服务器联系，那么 HADR 将不启动。这个期限可以用 HADR_TIMEOUT 配置参数（见表 1）来配置。这样做的目的是避免两个系统在偶然的情况下与主服务器同时启动。

在 HADR 启动过程中，数据库经历以下状态：local catch-up、remote catch-up pending、remote catch-up 和对等状态。日志被自动从主服务器传送到备用服务器，然后在备用服务器上重演。这是为了确保备用数据库跟上主数据库的变化。

强烈建议在主数据库和备用数据库所在的系统上使用相同的数据库配置参数和数据库管理器配置参数。否则，备用数据库就不会像主数据库一样执行。

一个例外是 LOGFILSIZ 数据库配置参数。这个参数的值被备用服务器所忽略。备用服务器自动创建与主数据库上的日志文件大小相匹配的日志文件。这保证了两个数据库上的日志文件是一致的。

在主数据库与备用数据库之间切换数据库角色，也就是说，备用数据库变成主数据库，主数据库变成备用数据库。
从主数据库故障转移到备用数据库。

   GET SNAPSHOT FOR DATABASE ON test1

下面的命令在备用数据库 TEST1 上开始 HADR 数据库切换角色操作：

   TAKEOVER HADR ON DB test1

故障转移方案不切换数据库角色。在故障转移操作期间，备用数据库接管主数据库角色，但是主数据库不会变成备用数据库。

下面的命令在数据库 TEST1 上开始一个 HADR 故障转移操作：

   TAKEOVER HADR ON DB test1 BY FORCE

表 3 和 4 总结了在备用数据库上发出的 TAKEOVER HADR 命令的行为，以及备用数据库所处的对应的 HADR 状态：

备用数据库的状态	接管行为
对等	主数据库和备用数据库都切换角色
Local catch-up or remote catch-up	错误
Remote catch-up pending	错误

备用数据库的状态	接管行为
对等	备用数据库通知主数据库关闭。备用数据库停止接收来自主数据库的日志，完成它已经收到的日志的重演，然后变成主数据库。备用数据库不用等到主数据库发来通知确认它受到接管通知或者它已经关闭
Local catch-up OR remote catch-up	错误
Remote catch-up pending	备用数据库变成主数据库

您已经看到了如何设置 HADR 环境，以及如何使用数据库角色切换和故障转移方案执行接管。

您学习了如何使用 HADR 使数据库具有高可用性。如果主数据库停机，那么它的备用数据库将接管，并成为新的主数据库。

为了启用自动客户机重路由特性，在主数据库上发出 UPDATE ALTERNATE SERVER 命令。该命令的语法如下：

UPDATE ALTERNATE SERVER FOR DATABASE database-alias
USING HOSTNAME alternate-server-hostname PORT port-number

为了在 server1 上的 TEST1 数据库上启用客户机重路由特性，以便在接管之后已有的和新的客户机连接被重新路由到 server2，在 server1 上发出以下命令：

UPDATE ALTERNATE SERVER FOR DATABASE test1 USING 
HOSTNAME server2.torolab.ibm.com PORT 50000

在这个例子中，50000 是 SVCENAME 端口，而不是 HADR 端口。

备用服务器信息存储在 server1 的数据库目录中。如果发出一个 LIST DB DIRECTORY 命令，那么可以注意到备用服务器信息（主机名和端口号）已经被添加：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

现在让我们来看一个关于如何在启用了自动客户机重路由特性的数据库上执行接管的例子。

在这个例子中，不带 BY FORCE 选项执行一个接管。

首先，建立到 server1 上的 TEST1 数据库的一个远程客户机连接。为此，只需在一个远程 DB2 客户机上发出一条 CONNECT TO DATABASE 命令：

CONNECT TO DB test1 USER user1

为了建立那样的连接，客户机必须已经被配置为连接到 server1。关于如何配置远程客户机连接的信息，请参考本系列中的第一篇教程。

在建立连接之后，主服务器上的备用服务器信息被获取并存储在客户机的数据库目录中：

 Database alias                       = TEST1
 Database name                        = TEST1
 Node name                            = server1
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Remote
 Catalog database partition number    = -1
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

确保该连接已成功建立，并且可以查询 TEST1 数据库。在 server1 上发出一条 LIST APPLICATION 命令，它应该显示数据库 TEST1 上的远程客户机连接：

D:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      8          9.26.94.149.24336.060601000305
                                                         TEST1    1

接着，在 TEST1 数据库上执行接管。在备用服务器 server2 上发出以下命令：

TAKEOVER HADR ON DB test1

让我们看看这次接管完成后远程客户机连接有什么变化。

再次尝试从客户机查询 TEST1 数据库。对 TEST1 数据库的任何查询应该都会返回一个错误消息。例如，从客户机连接发出一条 LIST TABLES 命令：

D:\Programs\IBM\SQLLIB\BIN>db2 list tables
SQL30108N A connection failed but has been re-established. 
The hostname or IP address is "server2" and the service name or port number is "50000". 
Special registers may or may not be re-attempted (Reason code = "1").  
SQLSTATE=08506

这证明客户机重路由特性在起作用。现在您已经连接到新的主服务器，即 server2。

在 server2 上发出一条 LIST APPLICATIONS 命令。您可以看到，远程客户机连接已经被重新路由到那里：

H:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      55         9.26.94.149.29200.060601001803
                                                         TEST1    1

如果再次查询数据库，那么可以从新的主服务器得到一个响应。而且，到原来主服务器的新连接也被重新路由到新的主服务器。

使用 GET SNAPSHOT 命令可以获得数据库的 HADR 状态。在 server2 上发出以下命令，应该可以看到 server2 已经接管了主数据库角色：

db2 "get snapshot for database on test1"

  HADR Status
  Role                   = Primary
  State                  = Peer
  Synchronization mode   = Nearsync
  Connection status      = Connected , 05/31/2006 20:17:24.989618
  Heartbeats missed      = 0
  Local host             = server2.torolab.ibm.com
  Local service          = 80000
  Remote host            = server1.torolab.ibm.com
  Remote service         = 70000
  Remote instance        = db2inst1
  timeout(seconds)       = 120
  Primary log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Standby log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Log gap running average(bytes) = 0

在执行接管操作之后，如果出故障的数据库又可以使用，它不会自动恢复主数据库的角色。

通过以下步骤可以使之重新成为主数据库：

修复原来的主数据库所在的系统。这包括修复有问题的硬件或者重新启动崩溃的操作系统。
重新启动出故障的主数据库，使之成为一个备用数据库。
执行一个接管操作，使之接管主数据库的角色。

当原来的主数据库重新以备用数据库的角色加入 HADR 对之后，执行一个接管操作来切换数据库的角色，使原来的主数据库再次成为主数据库。

为了停止 TEST1 数据库上的 HADR，发出：

STOP HADR ON DB test1

您可以看到，HADR 是实现高可用性解决方案的一个强大的特性。提供了一个名为 HADR 向导的图形化用户界面工具，以帮助您设置和配置 HADR。

如果选择 Set Up，那么就会打开一个如图 15 所示的逐步向导。

如果使用 Control Center 设置 HADR 环境，则会自动启用自动客户机重路由特性。

阅读(23803) | 评论(0) | 转发(0) |

上一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（4）

下一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（6）

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

16024965号-6

高可用性灾难恢复（HADR）

DB2 高可用性灾难恢复（HADR）是一种数据库复制特性，它提供了一种高可用性解决方案。目前，HADR 只用于单分区数据库环境。

为了设置 HADR 环境，要更新一些数据库配置参数。

首先，必须启用主数据库上的归档日志记录。请参阅备份和恢复教程，以了解如何启用归档日志记录。

表 1 列出了与 HADR 相关的数据库配置参数的描述。本教程后面将给出一个关于如何更新这些参数的例子。

与 HADR 相关的数据库配置参数	描述
HADR_LOCAL_HOST	指定 HADR TCPIP 通信的本地主机。主机名和 IP 地址都可以使用
HADR_LOCAL_SVC	指定 TCPIP 服务名和端口号，HADR 进程将在本地主机上接受该服务或端口的连接。这个端口不能与 HADR 实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_HOST	指定远程 HADR 节点的 TCPIP 主机名或 IP 地址
HADR_REMOTE_SVC	指定 TCPIP 服务名或端口号，HADR 进程将在远程节点上接受该服务或端口的连接。这个端口不能与远程实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_INST	指定远程服务器的实例名。DB2 Control Center 之类的管理工具将使用这个参数与远程服务器联系
HADR_TIMEOUT	HADR 进程在认为一次通信尝试失败之前所等待的时间（以秒为单位）。默认值为 120 秒
HADR_SYNCMODE	指定同步模式。它决定当系统处于对等状态时，主日志写与备用数据库如何同步。有效值有 SYNC、NEARSYNC 和 ASYNC。默认值为 NEARSYNC。（本节后面将讨论对等状态）。
HADR_DB_ROLE	指定一个数据库当前的角色。有效值有 STANDARD、PRIMARY 和 STANDBY。STANDARD 意味着数据库没有启用 HADR。

当备用数据库第一次启动时，它进入 local catch-up 状态。本地日志路径中的日志文件（如果有的话）将被读取，并应用到备用数据库。

当到达本地日志文件的最后时，备用数据库进入 remote catch-up 状态。它重演主数据库的归档日志和活动日志，直到备用数据库应用了最近的活动日志。

当主系统上的所有日志文件都已经被重演时，主数据库和备用数据库就进入对等（peer）状态。

在同步模式中，日志写只有在以下情况下才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库的日志文件中。

主数据库与备用数据库中的日志记录几乎（或近似）是同步的，因为只有在以下情况下，日志写才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库上的主存中。

在这种模式下，主数据库不等待收到备用数据库的通知。只有在以下情况下，日志写才被认为是成功的：

日志记录已经被写到主数据库上的日志文件中。
日志记录已经被传送到备用数据库；不需要通知。

HADR 是通过以下三个简单的命令来管理的：

START HADR
STOP HADR
TAKENOVER HADR

这些命令的语法如下：

START HADR ON DATABASE database-alias
[USER userid] [USING password] 
AS PRIMARY | STANDBY [BY FORCE]

STOP HADR ON DATABASE database-alias 
[USER userid] [USING password] 

TAKEOVER HADR ON DATABASE database-alias
[USER userid] [USING password] 
[BY FORCE]

您已经学习了 HADR 的概念，现在可以学习如何设置 HADR 环境。

使用另一个数据库服务器 server2.torolab.ibm.com 作为备用服务器。TEST1 当前不在备用服务器上。

服务名	实例名	SVCENAME 或端口号	数据库名
server1.torolab.ibm.com	DB2INST1	50000	TEST1
server2.torolab.ibm.com	DB2INST1	50000	--

第一次初始化 HADR 时，执行图 13 所示的五个步骤：

确定主服务器和备用服务器。决定主机名、主机 IP 地址和每个 HADR 数据库的服务名或端口号。
您已经确定了主服务器和备用服务器。主服务器是 server1。备用服务器是 server2。

确保这两个服务器是通过 TCPIP 相互通信的。尝试用主机名在这两个服务器上相互 ping 对方。应确保输出没有错误。如果主机名不能使用，那么尝试使用它们的 TCPIP 地址。选用两者中最好用的一种用于 HADR 配置。

通过克隆主数据库创建备用数据库。

有两种方案可用于克隆主数据库：

一种方案是为主数据库做一个备份，并在备用数据库上恢复这个数据库备份。这种方案使用标准备份和恢复方法。
克隆主数据库的另一种方案是使用分割镜像。为主数据库做一个分割镜像，然后在备用服务器上初始化该分割镜像。当初始化分割镜像时，必须在 db2inidb 命令中使用 standby 选项，以便使用 mirror 和 snapshot 选项。

在这个例子种，使用备份/恢复方法来创建备用数据库。

首先为 server1 上的主数据库 TEST1 做一个备份：

BACKUP DB test1

接着，通过 ftp 将备份镜像传送到备用服务器，并恢复该备份镜像。

将备份镜像恢复到与主服务器上相同的位置。在主服务器上，发出 LIST DB DIRECTORY 命令将显示：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            =
 Alternate server port number         =

数据库位于主服务器上的 C: 盘上。当在备用服务器上恢复备份镜像时，也将它恢复到 C: 盘。在备用服务器 server2 上，发出以下命令来恢复 TEST1 数据库：

RESTORE DB test1 ON C:

在主数据库和备用数据库上设置以下 HADR 配置参数：

HADR_LOCAL_HOST
HADR_LOCAL_SVC
HADR_REMOTE_HOST
HADR_REMOTE_SVC
HADR_REMOTE_INST
HADR_SYNCMODE
LOGINDEXBUILD

在主服务器上，为 HADR 使用端口号 70000。更新 Windows\System32\drivers\etc\services 文件，在其中添加以下一行：

Hadr_port 	70000/tcp

在备用服务器上的 services 文件中添加以下一行：

Hadr_port 	80000/tcp

为 HADR_SYNCMODE 使用默认值，即 NEARSYNC。

您已经有了配置 HADR 参数所需的所有信息。发出以下命令来配置备用服务器上的参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在主数据库服务器上，配置相同的一组参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在备用数据库上使用 START HADR 命令启动 HADR：
START HADR ON DB test1 AS STANDBY
在启动主数据库之前启动备用数据库。如果先启动主数据库，那么，如果没有在 HADR_TIMEOUT 数据库配置参数指定的期限内启动备用数据库，那么主数据库的启动过程就会失败。
在主数据库上启动 HADR，如下面的例子所示：
START HADR ON DB test1 AS PRIMARY
HADR 现在已经在主数据库和备用数据库上启动了。

当第一次启动主服务器时，它等待备用服务器与它联系。如果在指定期限内备用服务器没有与主服务器联系，那么 HADR 将不启动。这个期限可以用 HADR_TIMEOUT 配置参数（见表 1）来配置。这样做的目的是避免两个系统在偶然的情况下与主服务器同时启动。

在 HADR 启动过程中，数据库经历以下状态：local catch-up、remote catch-up pending、remote catch-up 和对等状态。日志被自动从主服务器传送到备用服务器，然后在备用服务器上重演。这是为了确保备用数据库跟上主数据库的变化。

强烈建议在主数据库和备用数据库所在的系统上使用相同的数据库配置参数和数据库管理器配置参数。否则，备用数据库就不会像主数据库一样执行。

一个例外是 LOGFILSIZ 数据库配置参数。这个参数的值被备用服务器所忽略。备用服务器自动创建与主数据库上的日志文件大小相匹配的日志文件。这保证了两个数据库上的日志文件是一致的。

在主数据库与备用数据库之间切换数据库角色，也就是说，备用数据库变成主数据库，主数据库变成备用数据库。
从主数据库故障转移到备用数据库。

   GET SNAPSHOT FOR DATABASE ON test1

下面的命令在备用数据库 TEST1 上开始 HADR 数据库切换角色操作：

   TAKEOVER HADR ON DB test1

故障转移方案不切换数据库角色。在故障转移操作期间，备用数据库接管主数据库角色，但是主数据库不会变成备用数据库。

下面的命令在数据库 TEST1 上开始一个 HADR 故障转移操作：

   TAKEOVER HADR ON DB test1 BY FORCE

表 3 和 4 总结了在备用数据库上发出的 TAKEOVER HADR 命令的行为，以及备用数据库所处的对应的 HADR 状态：

备用数据库的状态	接管行为
对等	主数据库和备用数据库都切换角色
Local catch-up or remote catch-up	错误
Remote catch-up pending	错误

备用数据库的状态	接管行为
对等	备用数据库通知主数据库关闭。备用数据库停止接收来自主数据库的日志，完成它已经收到的日志的重演，然后变成主数据库。备用数据库不用等到主数据库发来通知确认它受到接管通知或者它已经关闭
Local catch-up OR remote catch-up	错误
Remote catch-up pending	备用数据库变成主数据库

您已经看到了如何设置 HADR 环境，以及如何使用数据库角色切换和故障转移方案执行接管。

您学习了如何使用 HADR 使数据库具有高可用性。如果主数据库停机，那么它的备用数据库将接管，并成为新的主数据库。

为了启用自动客户机重路由特性，在主数据库上发出 UPDATE ALTERNATE SERVER 命令。该命令的语法如下：

UPDATE ALTERNATE SERVER FOR DATABASE database-alias
USING HOSTNAME alternate-server-hostname PORT port-number

为了在 server1 上的 TEST1 数据库上启用客户机重路由特性，以便在接管之后已有的和新的客户机连接被重新路由到 server2，在 server1 上发出以下命令：

UPDATE ALTERNATE SERVER FOR DATABASE test1 USING 
HOSTNAME server2.torolab.ibm.com PORT 50000

在这个例子中，50000 是 SVCENAME 端口，而不是 HADR 端口。

备用服务器信息存储在 server1 的数据库目录中。如果发出一个 LIST DB DIRECTORY 命令，那么可以注意到备用服务器信息（主机名和端口号）已经被添加：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

现在让我们来看一个关于如何在启用了自动客户机重路由特性的数据库上执行接管的例子。

在这个例子中，不带 BY FORCE 选项执行一个接管。

首先，建立到 server1 上的 TEST1 数据库的一个远程客户机连接。为此，只需在一个远程 DB2 客户机上发出一条 CONNECT TO DATABASE 命令：

CONNECT TO DB test1 USER user1

为了建立那样的连接，客户机必须已经被配置为连接到 server1。关于如何配置远程客户机连接的信息，请参考本系列中的第一篇教程。

在建立连接之后，主服务器上的备用服务器信息被获取并存储在客户机的数据库目录中：

 Database alias                       = TEST1
 Database name                        = TEST1
 Node name                            = server1
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Remote
 Catalog database partition number    = -1
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

确保该连接已成功建立，并且可以查询 TEST1 数据库。在 server1 上发出一条 LIST APPLICATION 命令，它应该显示数据库 TEST1 上的远程客户机连接：

D:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      8          9.26.94.149.24336.060601000305
                                                         TEST1    1

接着，在 TEST1 数据库上执行接管。在备用服务器 server2 上发出以下命令：

TAKEOVER HADR ON DB test1

让我们看看这次接管完成后远程客户机连接有什么变化。

再次尝试从客户机查询 TEST1 数据库。对 TEST1 数据库的任何查询应该都会返回一个错误消息。例如，从客户机连接发出一条 LIST TABLES 命令：

D:\Programs\IBM\SQLLIB\BIN>db2 list tables
SQL30108N A connection failed but has been re-established. 
The hostname or IP address is "server2" and the service name or port number is "50000". 
Special registers may or may not be re-attempted (Reason code = "1").  
SQLSTATE=08506

这证明客户机重路由特性在起作用。现在您已经连接到新的主服务器，即 server2。

在 server2 上发出一条 LIST APPLICATIONS 命令。您可以看到，远程客户机连接已经被重新路由到那里：

H:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      55         9.26.94.149.29200.060601001803
                                                         TEST1    1

如果再次查询数据库，那么可以从新的主服务器得到一个响应。而且，到原来主服务器的新连接也被重新路由到新的主服务器。

使用 GET SNAPSHOT 命令可以获得数据库的 HADR 状态。在 server2 上发出以下命令，应该可以看到 server2 已经接管了主数据库角色：

db2 "get snapshot for database on test1"

  HADR Status
  Role                   = Primary
  State                  = Peer
  Synchronization mode   = Nearsync
  Connection status      = Connected , 05/31/2006 20:17:24.989618
  Heartbeats missed      = 0
  Local host             = server2.torolab.ibm.com
  Local service          = 80000
  Remote host            = server1.torolab.ibm.com
  Remote service         = 70000
  Remote instance        = db2inst1
  timeout(seconds)       = 120
  Primary log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Standby log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Log gap running average(bytes) = 0

在执行接管操作之后，如果出故障的数据库又可以使用，它不会自动恢复主数据库的角色。

通过以下步骤可以使之重新成为主数据库：

修复原来的主数据库所在的系统。这包括修复有问题的硬件或者重新启动崩溃的操作系统。
重新启动出故障的主数据库，使之成为一个备用数据库。
执行一个接管操作，使之接管主数据库的角色。

当原来的主数据库重新以备用数据库的角色加入 HADR 对之后，执行一个接管操作来切换数据库的角色，使原来的主数据库再次成为主数据库。

为了停止 TEST1 数据库上的 HADR，发出：

STOP HADR ON DB test1

您可以看到，HADR 是实现高可用性解决方案的一个强大的特性。提供了一个名为 HADR 向导的图形化用户界面工具，以帮助您设置和配置 HADR。

如果选择 Set Up，那么就会打开一个如图 15 所示的逐步向导。

如果使用 Control Center 设置 HADR 环境，则会自动启用自动客户机重路由特性。

阅读(23802) | 评论(0) | 转发(0) |

上一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（4）

下一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（6）

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

16024965号-6

高可用性灾难恢复（HADR）

DB2 高可用性灾难恢复（HADR）是一种数据库复制特性，它提供了一种高可用性解决方案。目前，HADR 只用于单分区数据库环境。

为了设置 HADR 环境，要更新一些数据库配置参数。

首先，必须启用主数据库上的归档日志记录。请参阅备份和恢复教程，以了解如何启用归档日志记录。

表 1 列出了与 HADR 相关的数据库配置参数的描述。本教程后面将给出一个关于如何更新这些参数的例子。

与 HADR 相关的数据库配置参数	描述
HADR_LOCAL_HOST	指定 HADR TCPIP 通信的本地主机。主机名和 IP 地址都可以使用
HADR_LOCAL_SVC	指定 TCPIP 服务名和端口号，HADR 进程将在本地主机上接受该服务或端口的连接。这个端口不能与 HADR 实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_HOST	指定远程 HADR 节点的 TCPIP 主机名或 IP 地址
HADR_REMOTE_SVC	指定 TCPIP 服务名或端口号，HADR 进程将在远程节点上接受该服务或端口的连接。这个端口不能与远程实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_INST	指定远程服务器的实例名。DB2 Control Center 之类的管理工具将使用这个参数与远程服务器联系
HADR_TIMEOUT	HADR 进程在认为一次通信尝试失败之前所等待的时间（以秒为单位）。默认值为 120 秒
HADR_SYNCMODE	指定同步模式。它决定当系统处于对等状态时，主日志写与备用数据库如何同步。有效值有 SYNC、NEARSYNC 和 ASYNC。默认值为 NEARSYNC。（本节后面将讨论对等状态）。
HADR_DB_ROLE	指定一个数据库当前的角色。有效值有 STANDARD、PRIMARY 和 STANDBY。STANDARD 意味着数据库没有启用 HADR。

当备用数据库第一次启动时，它进入 local catch-up 状态。本地日志路径中的日志文件（如果有的话）将被读取，并应用到备用数据库。

当到达本地日志文件的最后时，备用数据库进入 remote catch-up 状态。它重演主数据库的归档日志和活动日志，直到备用数据库应用了最近的活动日志。

当主系统上的所有日志文件都已经被重演时，主数据库和备用数据库就进入对等（peer）状态。

在同步模式中，日志写只有在以下情况下才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库的日志文件中。

主数据库与备用数据库中的日志记录几乎（或近似）是同步的，因为只有在以下情况下，日志写才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库上的主存中。

在这种模式下，主数据库不等待收到备用数据库的通知。只有在以下情况下，日志写才被认为是成功的：

日志记录已经被写到主数据库上的日志文件中。
日志记录已经被传送到备用数据库；不需要通知。

HADR 是通过以下三个简单的命令来管理的：

START HADR
STOP HADR
TAKENOVER HADR

这些命令的语法如下：

START HADR ON DATABASE database-alias
[USER userid] [USING password] 
AS PRIMARY | STANDBY [BY FORCE]

STOP HADR ON DATABASE database-alias 
[USER userid] [USING password] 

TAKEOVER HADR ON DATABASE database-alias
[USER userid] [USING password] 
[BY FORCE]

您已经学习了 HADR 的概念，现在可以学习如何设置 HADR 环境。

使用另一个数据库服务器 server2.torolab.ibm.com 作为备用服务器。TEST1 当前不在备用服务器上。

服务名	实例名	SVCENAME 或端口号	数据库名
server1.torolab.ibm.com	DB2INST1	50000	TEST1
server2.torolab.ibm.com	DB2INST1	50000	--

第一次初始化 HADR 时，执行图 13 所示的五个步骤：

确定主服务器和备用服务器。决定主机名、主机 IP 地址和每个 HADR 数据库的服务名或端口号。
您已经确定了主服务器和备用服务器。主服务器是 server1。备用服务器是 server2。

确保这两个服务器是通过 TCPIP 相互通信的。尝试用主机名在这两个服务器上相互 ping 对方。应确保输出没有错误。如果主机名不能使用，那么尝试使用它们的 TCPIP 地址。选用两者中最好用的一种用于 HADR 配置。

通过克隆主数据库创建备用数据库。

有两种方案可用于克隆主数据库：

一种方案是为主数据库做一个备份，并在备用数据库上恢复这个数据库备份。这种方案使用标准备份和恢复方法。
克隆主数据库的另一种方案是使用分割镜像。为主数据库做一个分割镜像，然后在备用服务器上初始化该分割镜像。当初始化分割镜像时，必须在 db2inidb 命令中使用 standby 选项，以便使用 mirror 和 snapshot 选项。

在这个例子种，使用备份/恢复方法来创建备用数据库。

首先为 server1 上的主数据库 TEST1 做一个备份：

BACKUP DB test1

接着，通过 ftp 将备份镜像传送到备用服务器，并恢复该备份镜像。

将备份镜像恢复到与主服务器上相同的位置。在主服务器上，发出 LIST DB DIRECTORY 命令将显示：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            =
 Alternate server port number         =

数据库位于主服务器上的 C: 盘上。当在备用服务器上恢复备份镜像时，也将它恢复到 C: 盘。在备用服务器 server2 上，发出以下命令来恢复 TEST1 数据库：

RESTORE DB test1 ON C:

在主数据库和备用数据库上设置以下 HADR 配置参数：

HADR_LOCAL_HOST
HADR_LOCAL_SVC
HADR_REMOTE_HOST
HADR_REMOTE_SVC
HADR_REMOTE_INST
HADR_SYNCMODE
LOGINDEXBUILD

在主服务器上，为 HADR 使用端口号 70000。更新 Windows\System32\drivers\etc\services 文件，在其中添加以下一行：

Hadr_port 	70000/tcp

在备用服务器上的 services 文件中添加以下一行：

Hadr_port 	80000/tcp

为 HADR_SYNCMODE 使用默认值，即 NEARSYNC。

您已经有了配置 HADR 参数所需的所有信息。发出以下命令来配置备用服务器上的参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在主数据库服务器上，配置相同的一组参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在备用数据库上使用 START HADR 命令启动 HADR：
START HADR ON DB test1 AS STANDBY
在启动主数据库之前启动备用数据库。如果先启动主数据库，那么，如果没有在 HADR_TIMEOUT 数据库配置参数指定的期限内启动备用数据库，那么主数据库的启动过程就会失败。
在主数据库上启动 HADR，如下面的例子所示：
START HADR ON DB test1 AS PRIMARY
HADR 现在已经在主数据库和备用数据库上启动了。

当第一次启动主服务器时，它等待备用服务器与它联系。如果在指定期限内备用服务器没有与主服务器联系，那么 HADR 将不启动。这个期限可以用 HADR_TIMEOUT 配置参数（见表 1）来配置。这样做的目的是避免两个系统在偶然的情况下与主服务器同时启动。

在 HADR 启动过程中，数据库经历以下状态：local catch-up、remote catch-up pending、remote catch-up 和对等状态。日志被自动从主服务器传送到备用服务器，然后在备用服务器上重演。这是为了确保备用数据库跟上主数据库的变化。

强烈建议在主数据库和备用数据库所在的系统上使用相同的数据库配置参数和数据库管理器配置参数。否则，备用数据库就不会像主数据库一样执行。

一个例外是 LOGFILSIZ 数据库配置参数。这个参数的值被备用服务器所忽略。备用服务器自动创建与主数据库上的日志文件大小相匹配的日志文件。这保证了两个数据库上的日志文件是一致的。

在主数据库与备用数据库之间切换数据库角色，也就是说，备用数据库变成主数据库，主数据库变成备用数据库。
从主数据库故障转移到备用数据库。

   GET SNAPSHOT FOR DATABASE ON test1

下面的命令在备用数据库 TEST1 上开始 HADR 数据库切换角色操作：

   TAKEOVER HADR ON DB test1

故障转移方案不切换数据库角色。在故障转移操作期间，备用数据库接管主数据库角色，但是主数据库不会变成备用数据库。

下面的命令在数据库 TEST1 上开始一个 HADR 故障转移操作：

   TAKEOVER HADR ON DB test1 BY FORCE

表 3 和 4 总结了在备用数据库上发出的 TAKEOVER HADR 命令的行为，以及备用数据库所处的对应的 HADR 状态：

备用数据库的状态	接管行为
对等	主数据库和备用数据库都切换角色
Local catch-up or remote catch-up	错误
Remote catch-up pending	错误

备用数据库的状态	接管行为
对等	备用数据库通知主数据库关闭。备用数据库停止接收来自主数据库的日志，完成它已经收到的日志的重演，然后变成主数据库。备用数据库不用等到主数据库发来通知确认它受到接管通知或者它已经关闭
Local catch-up OR remote catch-up	错误
Remote catch-up pending	备用数据库变成主数据库

您已经看到了如何设置 HADR 环境，以及如何使用数据库角色切换和故障转移方案执行接管。

您学习了如何使用 HADR 使数据库具有高可用性。如果主数据库停机，那么它的备用数据库将接管，并成为新的主数据库。

为了启用自动客户机重路由特性，在主数据库上发出 UPDATE ALTERNATE SERVER 命令。该命令的语法如下：

UPDATE ALTERNATE SERVER FOR DATABASE database-alias
USING HOSTNAME alternate-server-hostname PORT port-number

为了在 server1 上的 TEST1 数据库上启用客户机重路由特性，以便在接管之后已有的和新的客户机连接被重新路由到 server2，在 server1 上发出以下命令：

UPDATE ALTERNATE SERVER FOR DATABASE test1 USING 
HOSTNAME server2.torolab.ibm.com PORT 50000

在这个例子中，50000 是 SVCENAME 端口，而不是 HADR 端口。

备用服务器信息存储在 server1 的数据库目录中。如果发出一个 LIST DB DIRECTORY 命令，那么可以注意到备用服务器信息（主机名和端口号）已经被添加：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

现在让我们来看一个关于如何在启用了自动客户机重路由特性的数据库上执行接管的例子。

在这个例子中，不带 BY FORCE 选项执行一个接管。

首先，建立到 server1 上的 TEST1 数据库的一个远程客户机连接。为此，只需在一个远程 DB2 客户机上发出一条 CONNECT TO DATABASE 命令：

CONNECT TO DB test1 USER user1

为了建立那样的连接，客户机必须已经被配置为连接到 server1。关于如何配置远程客户机连接的信息，请参考本系列中的第一篇教程。

在建立连接之后，主服务器上的备用服务器信息被获取并存储在客户机的数据库目录中：

 Database alias                       = TEST1
 Database name                        = TEST1
 Node name                            = server1
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Remote
 Catalog database partition number    = -1
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

确保该连接已成功建立，并且可以查询 TEST1 数据库。在 server1 上发出一条 LIST APPLICATION 命令，它应该显示数据库 TEST1 上的远程客户机连接：

D:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      8          9.26.94.149.24336.060601000305
                                                         TEST1    1

接着，在 TEST1 数据库上执行接管。在备用服务器 server2 上发出以下命令：

TAKEOVER HADR ON DB test1

让我们看看这次接管完成后远程客户机连接有什么变化。

再次尝试从客户机查询 TEST1 数据库。对 TEST1 数据库的任何查询应该都会返回一个错误消息。例如，从客户机连接发出一条 LIST TABLES 命令：

D:\Programs\IBM\SQLLIB\BIN>db2 list tables
SQL30108N A connection failed but has been re-established. 
The hostname or IP address is "server2" and the service name or port number is "50000". 
Special registers may or may not be re-attempted (Reason code = "1").  
SQLSTATE=08506

这证明客户机重路由特性在起作用。现在您已经连接到新的主服务器，即 server2。

在 server2 上发出一条 LIST APPLICATIONS 命令。您可以看到，远程客户机连接已经被重新路由到那里：

H:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      55         9.26.94.149.29200.060601001803
                                                         TEST1    1

如果再次查询数据库，那么可以从新的主服务器得到一个响应。而且，到原来主服务器的新连接也被重新路由到新的主服务器。

使用 GET SNAPSHOT 命令可以获得数据库的 HADR 状态。在 server2 上发出以下命令，应该可以看到 server2 已经接管了主数据库角色：

db2 "get snapshot for database on test1"

  HADR Status
  Role                   = Primary
  State                  = Peer
  Synchronization mode   = Nearsync
  Connection status      = Connected , 05/31/2006 20:17:24.989618
  Heartbeats missed      = 0
  Local host             = server2.torolab.ibm.com
  Local service          = 80000
  Remote host            = server1.torolab.ibm.com
  Remote service         = 70000
  Remote instance        = db2inst1
  timeout(seconds)       = 120
  Primary log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Standby log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Log gap running average(bytes) = 0

在执行接管操作之后，如果出故障的数据库又可以使用，它不会自动恢复主数据库的角色。

通过以下步骤可以使之重新成为主数据库：

修复原来的主数据库所在的系统。这包括修复有问题的硬件或者重新启动崩溃的操作系统。
重新启动出故障的主数据库，使之成为一个备用数据库。
执行一个接管操作，使之接管主数据库的角色。

当原来的主数据库重新以备用数据库的角色加入 HADR 对之后，执行一个接管操作来切换数据库的角色，使原来的主数据库再次成为主数据库。

为了停止 TEST1 数据库上的 HADR，发出：

STOP HADR ON DB test1

您可以看到，HADR 是实现高可用性解决方案的一个强大的特性。提供了一个名为 HADR 向导的图形化用户界面工具，以帮助您设置和配置 HADR。

如果选择 Set Up，那么就会打开一个如图 15 所示的逐步向导。

如果使用 Control Center 设置 HADR 环境，则会自动启用自动客户机重路由特性。

阅读(23801) | 评论(0) | 转发(0) |

上一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（4）

下一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（6）

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

16024965号-6

高可用性灾难恢复（HADR）

DB2 高可用性灾难恢复（HADR）是一种数据库复制特性，它提供了一种高可用性解决方案。目前，HADR 只用于单分区数据库环境。

为了设置 HADR 环境，要更新一些数据库配置参数。

首先，必须启用主数据库上的归档日志记录。请参阅备份和恢复教程，以了解如何启用归档日志记录。

表 1 列出了与 HADR 相关的数据库配置参数的描述。本教程后面将给出一个关于如何更新这些参数的例子。

与 HADR 相关的数据库配置参数	描述
HADR_LOCAL_HOST	指定 HADR TCPIP 通信的本地主机。主机名和 IP 地址都可以使用
HADR_LOCAL_SVC	指定 TCPIP 服务名和端口号，HADR 进程将在本地主机上接受该服务或端口的连接。这个端口不能与 HADR 实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_HOST	指定远程 HADR 节点的 TCPIP 主机名或 IP 地址
HADR_REMOTE_SVC	指定 TCPIP 服务名或端口号，HADR 进程将在远程节点上接受该服务或端口的连接。这个端口不能与远程实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_INST	指定远程服务器的实例名。DB2 Control Center 之类的管理工具将使用这个参数与远程服务器联系
HADR_TIMEOUT	HADR 进程在认为一次通信尝试失败之前所等待的时间（以秒为单位）。默认值为 120 秒
HADR_SYNCMODE	指定同步模式。它决定当系统处于对等状态时，主日志写与备用数据库如何同步。有效值有 SYNC、NEARSYNC 和 ASYNC。默认值为 NEARSYNC。（本节后面将讨论对等状态）。
HADR_DB_ROLE	指定一个数据库当前的角色。有效值有 STANDARD、PRIMARY 和 STANDBY。STANDARD 意味着数据库没有启用 HADR。

当备用数据库第一次启动时，它进入 local catch-up 状态。本地日志路径中的日志文件（如果有的话）将被读取，并应用到备用数据库。

当到达本地日志文件的最后时，备用数据库进入 remote catch-up 状态。它重演主数据库的归档日志和活动日志，直到备用数据库应用了最近的活动日志。

当主系统上的所有日志文件都已经被重演时，主数据库和备用数据库就进入对等（peer）状态。

在同步模式中，日志写只有在以下情况下才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库的日志文件中。

主数据库与备用数据库中的日志记录几乎（或近似）是同步的，因为只有在以下情况下，日志写才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库上的主存中。

在这种模式下，主数据库不等待收到备用数据库的通知。只有在以下情况下，日志写才被认为是成功的：

日志记录已经被写到主数据库上的日志文件中。
日志记录已经被传送到备用数据库；不需要通知。

HADR 是通过以下三个简单的命令来管理的：

START HADR
STOP HADR
TAKENOVER HADR

这些命令的语法如下：

START HADR ON DATABASE database-alias
[USER userid] [USING password] 
AS PRIMARY | STANDBY [BY FORCE]

STOP HADR ON DATABASE database-alias 
[USER userid] [USING password] 

TAKEOVER HADR ON DATABASE database-alias
[USER userid] [USING password] 
[BY FORCE]

您已经学习了 HADR 的概念，现在可以学习如何设置 HADR 环境。

使用另一个数据库服务器 server2.torolab.ibm.com 作为备用服务器。TEST1 当前不在备用服务器上。

服务名	实例名	SVCENAME 或端口号	数据库名
server1.torolab.ibm.com	DB2INST1	50000	TEST1
server2.torolab.ibm.com	DB2INST1	50000	--

第一次初始化 HADR 时，执行图 13 所示的五个步骤：

确定主服务器和备用服务器。决定主机名、主机 IP 地址和每个 HADR 数据库的服务名或端口号。
您已经确定了主服务器和备用服务器。主服务器是 server1。备用服务器是 server2。

确保这两个服务器是通过 TCPIP 相互通信的。尝试用主机名在这两个服务器上相互 ping 对方。应确保输出没有错误。如果主机名不能使用，那么尝试使用它们的 TCPIP 地址。选用两者中最好用的一种用于 HADR 配置。

通过克隆主数据库创建备用数据库。

有两种方案可用于克隆主数据库：

一种方案是为主数据库做一个备份，并在备用数据库上恢复这个数据库备份。这种方案使用标准备份和恢复方法。
克隆主数据库的另一种方案是使用分割镜像。为主数据库做一个分割镜像，然后在备用服务器上初始化该分割镜像。当初始化分割镜像时，必须在 db2inidb 命令中使用 standby 选项，以便使用 mirror 和 snapshot 选项。

在这个例子种，使用备份/恢复方法来创建备用数据库。

首先为 server1 上的主数据库 TEST1 做一个备份：

BACKUP DB test1

接着，通过 ftp 将备份镜像传送到备用服务器，并恢复该备份镜像。

将备份镜像恢复到与主服务器上相同的位置。在主服务器上，发出 LIST DB DIRECTORY 命令将显示：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            =
 Alternate server port number         =

数据库位于主服务器上的 C: 盘上。当在备用服务器上恢复备份镜像时，也将它恢复到 C: 盘。在备用服务器 server2 上，发出以下命令来恢复 TEST1 数据库：

RESTORE DB test1 ON C:

在主数据库和备用数据库上设置以下 HADR 配置参数：

HADR_LOCAL_HOST
HADR_LOCAL_SVC
HADR_REMOTE_HOST
HADR_REMOTE_SVC
HADR_REMOTE_INST
HADR_SYNCMODE
LOGINDEXBUILD

在主服务器上，为 HADR 使用端口号 70000。更新 Windows\System32\drivers\etc\services 文件，在其中添加以下一行：

Hadr_port 	70000/tcp

在备用服务器上的 services 文件中添加以下一行：

Hadr_port 	80000/tcp

为 HADR_SYNCMODE 使用默认值，即 NEARSYNC。

您已经有了配置 HADR 参数所需的所有信息。发出以下命令来配置备用服务器上的参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在主数据库服务器上，配置相同的一组参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在备用数据库上使用 START HADR 命令启动 HADR：
START HADR ON DB test1 AS STANDBY
在启动主数据库之前启动备用数据库。如果先启动主数据库，那么，如果没有在 HADR_TIMEOUT 数据库配置参数指定的期限内启动备用数据库，那么主数据库的启动过程就会失败。
在主数据库上启动 HADR，如下面的例子所示：
START HADR ON DB test1 AS PRIMARY
HADR 现在已经在主数据库和备用数据库上启动了。

当第一次启动主服务器时，它等待备用服务器与它联系。如果在指定期限内备用服务器没有与主服务器联系，那么 HADR 将不启动。这个期限可以用 HADR_TIMEOUT 配置参数（见表 1）来配置。这样做的目的是避免两个系统在偶然的情况下与主服务器同时启动。

在 HADR 启动过程中，数据库经历以下状态：local catch-up、remote catch-up pending、remote catch-up 和对等状态。日志被自动从主服务器传送到备用服务器，然后在备用服务器上重演。这是为了确保备用数据库跟上主数据库的变化。

强烈建议在主数据库和备用数据库所在的系统上使用相同的数据库配置参数和数据库管理器配置参数。否则，备用数据库就不会像主数据库一样执行。

一个例外是 LOGFILSIZ 数据库配置参数。这个参数的值被备用服务器所忽略。备用服务器自动创建与主数据库上的日志文件大小相匹配的日志文件。这保证了两个数据库上的日志文件是一致的。

在主数据库与备用数据库之间切换数据库角色，也就是说，备用数据库变成主数据库，主数据库变成备用数据库。
从主数据库故障转移到备用数据库。

   GET SNAPSHOT FOR DATABASE ON test1

下面的命令在备用数据库 TEST1 上开始 HADR 数据库切换角色操作：

   TAKEOVER HADR ON DB test1

故障转移方案不切换数据库角色。在故障转移操作期间，备用数据库接管主数据库角色，但是主数据库不会变成备用数据库。

下面的命令在数据库 TEST1 上开始一个 HADR 故障转移操作：

   TAKEOVER HADR ON DB test1 BY FORCE

表 3 和 4 总结了在备用数据库上发出的 TAKEOVER HADR 命令的行为，以及备用数据库所处的对应的 HADR 状态：

备用数据库的状态	接管行为
对等	主数据库和备用数据库都切换角色
Local catch-up or remote catch-up	错误
Remote catch-up pending	错误

备用数据库的状态	接管行为
对等	备用数据库通知主数据库关闭。备用数据库停止接收来自主数据库的日志，完成它已经收到的日志的重演，然后变成主数据库。备用数据库不用等到主数据库发来通知确认它受到接管通知或者它已经关闭
Local catch-up OR remote catch-up	错误
Remote catch-up pending	备用数据库变成主数据库

您已经看到了如何设置 HADR 环境，以及如何使用数据库角色切换和故障转移方案执行接管。

您学习了如何使用 HADR 使数据库具有高可用性。如果主数据库停机，那么它的备用数据库将接管，并成为新的主数据库。

为了启用自动客户机重路由特性，在主数据库上发出 UPDATE ALTERNATE SERVER 命令。该命令的语法如下：

UPDATE ALTERNATE SERVER FOR DATABASE database-alias
USING HOSTNAME alternate-server-hostname PORT port-number

为了在 server1 上的 TEST1 数据库上启用客户机重路由特性，以便在接管之后已有的和新的客户机连接被重新路由到 server2，在 server1 上发出以下命令：

UPDATE ALTERNATE SERVER FOR DATABASE test1 USING 
HOSTNAME server2.torolab.ibm.com PORT 50000

在这个例子中，50000 是 SVCENAME 端口，而不是 HADR 端口。

备用服务器信息存储在 server1 的数据库目录中。如果发出一个 LIST DB DIRECTORY 命令，那么可以注意到备用服务器信息（主机名和端口号）已经被添加：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

现在让我们来看一个关于如何在启用了自动客户机重路由特性的数据库上执行接管的例子。

在这个例子中，不带 BY FORCE 选项执行一个接管。

首先，建立到 server1 上的 TEST1 数据库的一个远程客户机连接。为此，只需在一个远程 DB2 客户机上发出一条 CONNECT TO DATABASE 命令：

CONNECT TO DB test1 USER user1

为了建立那样的连接，客户机必须已经被配置为连接到 server1。关于如何配置远程客户机连接的信息，请参考本系列中的第一篇教程。

在建立连接之后，主服务器上的备用服务器信息被获取并存储在客户机的数据库目录中：

 Database alias                       = TEST1
 Database name                        = TEST1
 Node name                            = server1
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Remote
 Catalog database partition number    = -1
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

确保该连接已成功建立，并且可以查询 TEST1 数据库。在 server1 上发出一条 LIST APPLICATION 命令，它应该显示数据库 TEST1 上的远程客户机连接：

D:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      8          9.26.94.149.24336.060601000305
                                                         TEST1    1

接着，在 TEST1 数据库上执行接管。在备用服务器 server2 上发出以下命令：

TAKEOVER HADR ON DB test1

让我们看看这次接管完成后远程客户机连接有什么变化。

再次尝试从客户机查询 TEST1 数据库。对 TEST1 数据库的任何查询应该都会返回一个错误消息。例如，从客户机连接发出一条 LIST TABLES 命令：

D:\Programs\IBM\SQLLIB\BIN>db2 list tables
SQL30108N A connection failed but has been re-established. 
The hostname or IP address is "server2" and the service name or port number is "50000". 
Special registers may or may not be re-attempted (Reason code = "1").  
SQLSTATE=08506

这证明客户机重路由特性在起作用。现在您已经连接到新的主服务器，即 server2。

在 server2 上发出一条 LIST APPLICATIONS 命令。您可以看到，远程客户机连接已经被重新路由到那里：

H:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      55         9.26.94.149.29200.060601001803
                                                         TEST1    1

如果再次查询数据库，那么可以从新的主服务器得到一个响应。而且，到原来主服务器的新连接也被重新路由到新的主服务器。

使用 GET SNAPSHOT 命令可以获得数据库的 HADR 状态。在 server2 上发出以下命令，应该可以看到 server2 已经接管了主数据库角色：

db2 "get snapshot for database on test1"

  HADR Status
  Role                   = Primary
  State                  = Peer
  Synchronization mode   = Nearsync
  Connection status      = Connected , 05/31/2006 20:17:24.989618
  Heartbeats missed      = 0
  Local host             = server2.torolab.ibm.com
  Local service          = 80000
  Remote host            = server1.torolab.ibm.com
  Remote service         = 70000
  Remote instance        = db2inst1
  timeout(seconds)       = 120
  Primary log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Standby log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Log gap running average(bytes) = 0

在执行接管操作之后，如果出故障的数据库又可以使用，它不会自动恢复主数据库的角色。

通过以下步骤可以使之重新成为主数据库：

修复原来的主数据库所在的系统。这包括修复有问题的硬件或者重新启动崩溃的操作系统。
重新启动出故障的主数据库，使之成为一个备用数据库。
执行一个接管操作，使之接管主数据库的角色。

当原来的主数据库重新以备用数据库的角色加入 HADR 对之后，执行一个接管操作来切换数据库的角色，使原来的主数据库再次成为主数据库。

为了停止 TEST1 数据库上的 HADR，发出：

STOP HADR ON DB test1

您可以看到，HADR 是实现高可用性解决方案的一个强大的特性。提供了一个名为 HADR 向导的图形化用户界面工具，以帮助您设置和配置 HADR。

如果选择 Set Up，那么就会打开一个如图 15 所示的逐步向导。

如果使用 Control Center 设置 HADR 环境，则会自动启用自动客户机重路由特性。

阅读(23800) | 评论(0) | 转发(0) |

上一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（4）

下一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（6）

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

16024965号-6

高可用性灾难恢复（HADR）

DB2 高可用性灾难恢复（HADR）是一种数据库复制特性，它提供了一种高可用性解决方案。目前，HADR 只用于单分区数据库环境。

为了设置 HADR 环境，要更新一些数据库配置参数。

首先，必须启用主数据库上的归档日志记录。请参阅备份和恢复教程，以了解如何启用归档日志记录。

表 1 列出了与 HADR 相关的数据库配置参数的描述。本教程后面将给出一个关于如何更新这些参数的例子。

与 HADR 相关的数据库配置参数	描述
HADR_LOCAL_HOST	指定 HADR TCPIP 通信的本地主机。主机名和 IP 地址都可以使用
HADR_LOCAL_SVC	指定 TCPIP 服务名和端口号，HADR 进程将在本地主机上接受该服务或端口的连接。这个端口不能与 HADR 实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_HOST	指定远程 HADR 节点的 TCPIP 主机名或 IP 地址
HADR_REMOTE_SVC	指定 TCPIP 服务名或端口号，HADR 进程将在远程节点上接受该服务或端口的连接。这个端口不能与远程实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_INST	指定远程服务器的实例名。DB2 Control Center 之类的管理工具将使用这个参数与远程服务器联系
HADR_TIMEOUT	HADR 进程在认为一次通信尝试失败之前所等待的时间（以秒为单位）。默认值为 120 秒
HADR_SYNCMODE	指定同步模式。它决定当系统处于对等状态时，主日志写与备用数据库如何同步。有效值有 SYNC、NEARSYNC 和 ASYNC。默认值为 NEARSYNC。（本节后面将讨论对等状态）。
HADR_DB_ROLE	指定一个数据库当前的角色。有效值有 STANDARD、PRIMARY 和 STANDBY。STANDARD 意味着数据库没有启用 HADR。

当备用数据库第一次启动时，它进入 local catch-up 状态。本地日志路径中的日志文件（如果有的话）将被读取，并应用到备用数据库。

当到达本地日志文件的最后时，备用数据库进入 remote catch-up 状态。它重演主数据库的归档日志和活动日志，直到备用数据库应用了最近的活动日志。

当主系统上的所有日志文件都已经被重演时，主数据库和备用数据库就进入对等（peer）状态。

在同步模式中，日志写只有在以下情况下才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库的日志文件中。

主数据库与备用数据库中的日志记录几乎（或近似）是同步的，因为只有在以下情况下，日志写才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库上的主存中。

在这种模式下，主数据库不等待收到备用数据库的通知。只有在以下情况下，日志写才被认为是成功的：

日志记录已经被写到主数据库上的日志文件中。
日志记录已经被传送到备用数据库；不需要通知。

HADR 是通过以下三个简单的命令来管理的：

START HADR
STOP HADR
TAKENOVER HADR

这些命令的语法如下：

START HADR ON DATABASE database-alias
[USER userid] [USING password] 
AS PRIMARY | STANDBY [BY FORCE]

STOP HADR ON DATABASE database-alias 
[USER userid] [USING password] 

TAKEOVER HADR ON DATABASE database-alias
[USER userid] [USING password] 
[BY FORCE]

您已经学习了 HADR 的概念，现在可以学习如何设置 HADR 环境。

使用另一个数据库服务器 server2.torolab.ibm.com 作为备用服务器。TEST1 当前不在备用服务器上。

服务名	实例名	SVCENAME 或端口号	数据库名
server1.torolab.ibm.com	DB2INST1	50000	TEST1
server2.torolab.ibm.com	DB2INST1	50000	--

第一次初始化 HADR 时，执行图 13 所示的五个步骤：

确定主服务器和备用服务器。决定主机名、主机 IP 地址和每个 HADR 数据库的服务名或端口号。
您已经确定了主服务器和备用服务器。主服务器是 server1。备用服务器是 server2。

确保这两个服务器是通过 TCPIP 相互通信的。尝试用主机名在这两个服务器上相互 ping 对方。应确保输出没有错误。如果主机名不能使用，那么尝试使用它们的 TCPIP 地址。选用两者中最好用的一种用于 HADR 配置。

通过克隆主数据库创建备用数据库。

有两种方案可用于克隆主数据库：

一种方案是为主数据库做一个备份，并在备用数据库上恢复这个数据库备份。这种方案使用标准备份和恢复方法。
克隆主数据库的另一种方案是使用分割镜像。为主数据库做一个分割镜像，然后在备用服务器上初始化该分割镜像。当初始化分割镜像时，必须在 db2inidb 命令中使用 standby 选项，以便使用 mirror 和 snapshot 选项。

在这个例子种，使用备份/恢复方法来创建备用数据库。

首先为 server1 上的主数据库 TEST1 做一个备份：

BACKUP DB test1

接着，通过 ftp 将备份镜像传送到备用服务器，并恢复该备份镜像。

将备份镜像恢复到与主服务器上相同的位置。在主服务器上，发出 LIST DB DIRECTORY 命令将显示：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            =
 Alternate server port number         =

数据库位于主服务器上的 C: 盘上。当在备用服务器上恢复备份镜像时，也将它恢复到 C: 盘。在备用服务器 server2 上，发出以下命令来恢复 TEST1 数据库：

RESTORE DB test1 ON C:

在主数据库和备用数据库上设置以下 HADR 配置参数：

HADR_LOCAL_HOST
HADR_LOCAL_SVC
HADR_REMOTE_HOST
HADR_REMOTE_SVC
HADR_REMOTE_INST
HADR_SYNCMODE
LOGINDEXBUILD

在主服务器上，为 HADR 使用端口号 70000。更新 Windows\System32\drivers\etc\services 文件，在其中添加以下一行：

Hadr_port 	70000/tcp

在备用服务器上的 services 文件中添加以下一行：

Hadr_port 	80000/tcp

为 HADR_SYNCMODE 使用默认值，即 NEARSYNC。

您已经有了配置 HADR 参数所需的所有信息。发出以下命令来配置备用服务器上的参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在主数据库服务器上，配置相同的一组参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在备用数据库上使用 START HADR 命令启动 HADR：
START HADR ON DB test1 AS STANDBY
在启动主数据库之前启动备用数据库。如果先启动主数据库，那么，如果没有在 HADR_TIMEOUT 数据库配置参数指定的期限内启动备用数据库，那么主数据库的启动过程就会失败。
在主数据库上启动 HADR，如下面的例子所示：
START HADR ON DB test1 AS PRIMARY
HADR 现在已经在主数据库和备用数据库上启动了。

当第一次启动主服务器时，它等待备用服务器与它联系。如果在指定期限内备用服务器没有与主服务器联系，那么 HADR 将不启动。这个期限可以用 HADR_TIMEOUT 配置参数（见表 1）来配置。这样做的目的是避免两个系统在偶然的情况下与主服务器同时启动。

在 HADR 启动过程中，数据库经历以下状态：local catch-up、remote catch-up pending、remote catch-up 和对等状态。日志被自动从主服务器传送到备用服务器，然后在备用服务器上重演。这是为了确保备用数据库跟上主数据库的变化。

强烈建议在主数据库和备用数据库所在的系统上使用相同的数据库配置参数和数据库管理器配置参数。否则，备用数据库就不会像主数据库一样执行。

一个例外是 LOGFILSIZ 数据库配置参数。这个参数的值被备用服务器所忽略。备用服务器自动创建与主数据库上的日志文件大小相匹配的日志文件。这保证了两个数据库上的日志文件是一致的。

在主数据库与备用数据库之间切换数据库角色，也就是说，备用数据库变成主数据库，主数据库变成备用数据库。
从主数据库故障转移到备用数据库。

   GET SNAPSHOT FOR DATABASE ON test1

下面的命令在备用数据库 TEST1 上开始 HADR 数据库切换角色操作：

   TAKEOVER HADR ON DB test1

故障转移方案不切换数据库角色。在故障转移操作期间，备用数据库接管主数据库角色，但是主数据库不会变成备用数据库。

下面的命令在数据库 TEST1 上开始一个 HADR 故障转移操作：

   TAKEOVER HADR ON DB test1 BY FORCE

表 3 和 4 总结了在备用数据库上发出的 TAKEOVER HADR 命令的行为，以及备用数据库所处的对应的 HADR 状态：

备用数据库的状态	接管行为
对等	主数据库和备用数据库都切换角色
Local catch-up or remote catch-up	错误
Remote catch-up pending	错误

备用数据库的状态	接管行为
对等	备用数据库通知主数据库关闭。备用数据库停止接收来自主数据库的日志，完成它已经收到的日志的重演，然后变成主数据库。备用数据库不用等到主数据库发来通知确认它受到接管通知或者它已经关闭
Local catch-up OR remote catch-up	错误
Remote catch-up pending	备用数据库变成主数据库

您已经看到了如何设置 HADR 环境，以及如何使用数据库角色切换和故障转移方案执行接管。

您学习了如何使用 HADR 使数据库具有高可用性。如果主数据库停机，那么它的备用数据库将接管，并成为新的主数据库。

为了启用自动客户机重路由特性，在主数据库上发出 UPDATE ALTERNATE SERVER 命令。该命令的语法如下：

UPDATE ALTERNATE SERVER FOR DATABASE database-alias
USING HOSTNAME alternate-server-hostname PORT port-number

为了在 server1 上的 TEST1 数据库上启用客户机重路由特性，以便在接管之后已有的和新的客户机连接被重新路由到 server2，在 server1 上发出以下命令：

UPDATE ALTERNATE SERVER FOR DATABASE test1 USING 
HOSTNAME server2.torolab.ibm.com PORT 50000

在这个例子中，50000 是 SVCENAME 端口，而不是 HADR 端口。

备用服务器信息存储在 server1 的数据库目录中。如果发出一个 LIST DB DIRECTORY 命令，那么可以注意到备用服务器信息（主机名和端口号）已经被添加：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

现在让我们来看一个关于如何在启用了自动客户机重路由特性的数据库上执行接管的例子。

在这个例子中，不带 BY FORCE 选项执行一个接管。

首先，建立到 server1 上的 TEST1 数据库的一个远程客户机连接。为此，只需在一个远程 DB2 客户机上发出一条 CONNECT TO DATABASE 命令：

CONNECT TO DB test1 USER user1

为了建立那样的连接，客户机必须已经被配置为连接到 server1。关于如何配置远程客户机连接的信息，请参考本系列中的第一篇教程。

在建立连接之后，主服务器上的备用服务器信息被获取并存储在客户机的数据库目录中：

 Database alias                       = TEST1
 Database name                        = TEST1
 Node name                            = server1
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Remote
 Catalog database partition number    = -1
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

确保该连接已成功建立，并且可以查询 TEST1 数据库。在 server1 上发出一条 LIST APPLICATION 命令，它应该显示数据库 TEST1 上的远程客户机连接：

D:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      8          9.26.94.149.24336.060601000305
                                                         TEST1    1

接着，在 TEST1 数据库上执行接管。在备用服务器 server2 上发出以下命令：

TAKEOVER HADR ON DB test1

让我们看看这次接管完成后远程客户机连接有什么变化。

再次尝试从客户机查询 TEST1 数据库。对 TEST1 数据库的任何查询应该都会返回一个错误消息。例如，从客户机连接发出一条 LIST TABLES 命令：

D:\Programs\IBM\SQLLIB\BIN>db2 list tables
SQL30108N A connection failed but has been re-established. 
The hostname or IP address is "server2" and the service name or port number is "50000". 
Special registers may or may not be re-attempted (Reason code = "1").  
SQLSTATE=08506

这证明客户机重路由特性在起作用。现在您已经连接到新的主服务器，即 server2。

在 server2 上发出一条 LIST APPLICATIONS 命令。您可以看到，远程客户机连接已经被重新路由到那里：

H:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      55         9.26.94.149.29200.060601001803
                                                         TEST1    1

如果再次查询数据库，那么可以从新的主服务器得到一个响应。而且，到原来主服务器的新连接也被重新路由到新的主服务器。

使用 GET SNAPSHOT 命令可以获得数据库的 HADR 状态。在 server2 上发出以下命令，应该可以看到 server2 已经接管了主数据库角色：

db2 "get snapshot for database on test1"

  HADR Status
  Role                   = Primary
  State                  = Peer
  Synchronization mode   = Nearsync
  Connection status      = Connected , 05/31/2006 20:17:24.989618
  Heartbeats missed      = 0
  Local host             = server2.torolab.ibm.com
  Local service          = 80000
  Remote host            = server1.torolab.ibm.com
  Remote service         = 70000
  Remote instance        = db2inst1
  timeout(seconds)       = 120
  Primary log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Standby log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Log gap running average(bytes) = 0

在执行接管操作之后，如果出故障的数据库又可以使用，它不会自动恢复主数据库的角色。

通过以下步骤可以使之重新成为主数据库：

修复原来的主数据库所在的系统。这包括修复有问题的硬件或者重新启动崩溃的操作系统。
重新启动出故障的主数据库，使之成为一个备用数据库。
执行一个接管操作，使之接管主数据库的角色。

当原来的主数据库重新以备用数据库的角色加入 HADR 对之后，执行一个接管操作来切换数据库的角色，使原来的主数据库再次成为主数据库。

为了停止 TEST1 数据库上的 HADR，发出：

STOP HADR ON DB test1

您可以看到，HADR 是实现高可用性解决方案的一个强大的特性。提供了一个名为 HADR 向导的图形化用户界面工具，以帮助您设置和配置 HADR。

如果选择 Set Up，那么就会打开一个如图 15 所示的逐步向导。

如果使用 Control Center 设置 HADR 环境，则会自动启用自动客户机重路由特性。

阅读(23799) | 评论(0) | 转发(0) |

上一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（4）

下一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（6）

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

16024965号-6

高可用性灾难恢复（HADR）

DB2 高可用性灾难恢复（HADR）是一种数据库复制特性，它提供了一种高可用性解决方案。目前，HADR 只用于单分区数据库环境。

为了设置 HADR 环境，要更新一些数据库配置参数。

首先，必须启用主数据库上的归档日志记录。请参阅备份和恢复教程，以了解如何启用归档日志记录。

表 1 列出了与 HADR 相关的数据库配置参数的描述。本教程后面将给出一个关于如何更新这些参数的例子。

与 HADR 相关的数据库配置参数	描述
HADR_LOCAL_HOST	指定 HADR TCPIP 通信的本地主机。主机名和 IP 地址都可以使用
HADR_LOCAL_SVC	指定 TCPIP 服务名和端口号，HADR 进程将在本地主机上接受该服务或端口的连接。这个端口不能与 HADR 实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_HOST	指定远程 HADR 节点的 TCPIP 主机名或 IP 地址
HADR_REMOTE_SVC	指定 TCPIP 服务名或端口号，HADR 进程将在远程节点上接受该服务或端口的连接。这个端口不能与远程实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_INST	指定远程服务器的实例名。DB2 Control Center 之类的管理工具将使用这个参数与远程服务器联系
HADR_TIMEOUT	HADR 进程在认为一次通信尝试失败之前所等待的时间（以秒为单位）。默认值为 120 秒
HADR_SYNCMODE	指定同步模式。它决定当系统处于对等状态时，主日志写与备用数据库如何同步。有效值有 SYNC、NEARSYNC 和 ASYNC。默认值为 NEARSYNC。（本节后面将讨论对等状态）。
HADR_DB_ROLE	指定一个数据库当前的角色。有效值有 STANDARD、PRIMARY 和 STANDBY。STANDARD 意味着数据库没有启用 HADR。

当备用数据库第一次启动时，它进入 local catch-up 状态。本地日志路径中的日志文件（如果有的话）将被读取，并应用到备用数据库。

当到达本地日志文件的最后时，备用数据库进入 remote catch-up 状态。它重演主数据库的归档日志和活动日志，直到备用数据库应用了最近的活动日志。

当主系统上的所有日志文件都已经被重演时，主数据库和备用数据库就进入对等（peer）状态。

在同步模式中，日志写只有在以下情况下才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库的日志文件中。

主数据库与备用数据库中的日志记录几乎（或近似）是同步的，因为只有在以下情况下，日志写才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库上的主存中。

在这种模式下，主数据库不等待收到备用数据库的通知。只有在以下情况下，日志写才被认为是成功的：

日志记录已经被写到主数据库上的日志文件中。
日志记录已经被传送到备用数据库；不需要通知。

HADR 是通过以下三个简单的命令来管理的：

START HADR
STOP HADR
TAKENOVER HADR

这些命令的语法如下：

START HADR ON DATABASE database-alias
[USER userid] [USING password] 
AS PRIMARY | STANDBY [BY FORCE]

STOP HADR ON DATABASE database-alias 
[USER userid] [USING password] 

TAKEOVER HADR ON DATABASE database-alias
[USER userid] [USING password] 
[BY FORCE]

您已经学习了 HADR 的概念，现在可以学习如何设置 HADR 环境。

使用另一个数据库服务器 server2.torolab.ibm.com 作为备用服务器。TEST1 当前不在备用服务器上。

服务名	实例名	SVCENAME 或端口号	数据库名
server1.torolab.ibm.com	DB2INST1	50000	TEST1
server2.torolab.ibm.com	DB2INST1	50000	--

第一次初始化 HADR 时，执行图 13 所示的五个步骤：

确定主服务器和备用服务器。决定主机名、主机 IP 地址和每个 HADR 数据库的服务名或端口号。
您已经确定了主服务器和备用服务器。主服务器是 server1。备用服务器是 server2。

确保这两个服务器是通过 TCPIP 相互通信的。尝试用主机名在这两个服务器上相互 ping 对方。应确保输出没有错误。如果主机名不能使用，那么尝试使用它们的 TCPIP 地址。选用两者中最好用的一种用于 HADR 配置。

通过克隆主数据库创建备用数据库。

有两种方案可用于克隆主数据库：

一种方案是为主数据库做一个备份，并在备用数据库上恢复这个数据库备份。这种方案使用标准备份和恢复方法。
克隆主数据库的另一种方案是使用分割镜像。为主数据库做一个分割镜像，然后在备用服务器上初始化该分割镜像。当初始化分割镜像时，必须在 db2inidb 命令中使用 standby 选项，以便使用 mirror 和 snapshot 选项。

在这个例子种，使用备份/恢复方法来创建备用数据库。

首先为 server1 上的主数据库 TEST1 做一个备份：

BACKUP DB test1

接着，通过 ftp 将备份镜像传送到备用服务器，并恢复该备份镜像。

将备份镜像恢复到与主服务器上相同的位置。在主服务器上，发出 LIST DB DIRECTORY 命令将显示：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            =
 Alternate server port number         =

数据库位于主服务器上的 C: 盘上。当在备用服务器上恢复备份镜像时，也将它恢复到 C: 盘。在备用服务器 server2 上，发出以下命令来恢复 TEST1 数据库：

RESTORE DB test1 ON C:

在主数据库和备用数据库上设置以下 HADR 配置参数：

HADR_LOCAL_HOST
HADR_LOCAL_SVC
HADR_REMOTE_HOST
HADR_REMOTE_SVC
HADR_REMOTE_INST
HADR_SYNCMODE
LOGINDEXBUILD

在主服务器上，为 HADR 使用端口号 70000。更新 Windows\System32\drivers\etc\services 文件，在其中添加以下一行：

Hadr_port 	70000/tcp

在备用服务器上的 services 文件中添加以下一行：

Hadr_port 	80000/tcp

为 HADR_SYNCMODE 使用默认值，即 NEARSYNC。

您已经有了配置 HADR 参数所需的所有信息。发出以下命令来配置备用服务器上的参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在主数据库服务器上，配置相同的一组参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在备用数据库上使用 START HADR 命令启动 HADR：
START HADR ON DB test1 AS STANDBY
在启动主数据库之前启动备用数据库。如果先启动主数据库，那么，如果没有在 HADR_TIMEOUT 数据库配置参数指定的期限内启动备用数据库，那么主数据库的启动过程就会失败。
在主数据库上启动 HADR，如下面的例子所示：
START HADR ON DB test1 AS PRIMARY
HADR 现在已经在主数据库和备用数据库上启动了。

当第一次启动主服务器时，它等待备用服务器与它联系。如果在指定期限内备用服务器没有与主服务器联系，那么 HADR 将不启动。这个期限可以用 HADR_TIMEOUT 配置参数（见表 1）来配置。这样做的目的是避免两个系统在偶然的情况下与主服务器同时启动。

在 HADR 启动过程中，数据库经历以下状态：local catch-up、remote catch-up pending、remote catch-up 和对等状态。日志被自动从主服务器传送到备用服务器，然后在备用服务器上重演。这是为了确保备用数据库跟上主数据库的变化。

强烈建议在主数据库和备用数据库所在的系统上使用相同的数据库配置参数和数据库管理器配置参数。否则，备用数据库就不会像主数据库一样执行。

一个例外是 LOGFILSIZ 数据库配置参数。这个参数的值被备用服务器所忽略。备用服务器自动创建与主数据库上的日志文件大小相匹配的日志文件。这保证了两个数据库上的日志文件是一致的。

在主数据库与备用数据库之间切换数据库角色，也就是说，备用数据库变成主数据库，主数据库变成备用数据库。
从主数据库故障转移到备用数据库。

   GET SNAPSHOT FOR DATABASE ON test1

下面的命令在备用数据库 TEST1 上开始 HADR 数据库切换角色操作：

   TAKEOVER HADR ON DB test1

故障转移方案不切换数据库角色。在故障转移操作期间，备用数据库接管主数据库角色，但是主数据库不会变成备用数据库。

下面的命令在数据库 TEST1 上开始一个 HADR 故障转移操作：

   TAKEOVER HADR ON DB test1 BY FORCE

表 3 和 4 总结了在备用数据库上发出的 TAKEOVER HADR 命令的行为，以及备用数据库所处的对应的 HADR 状态：

备用数据库的状态	接管行为
对等	主数据库和备用数据库都切换角色
Local catch-up or remote catch-up	错误
Remote catch-up pending	错误

备用数据库的状态	接管行为
对等	备用数据库通知主数据库关闭。备用数据库停止接收来自主数据库的日志，完成它已经收到的日志的重演，然后变成主数据库。备用数据库不用等到主数据库发来通知确认它受到接管通知或者它已经关闭
Local catch-up OR remote catch-up	错误
Remote catch-up pending	备用数据库变成主数据库

您已经看到了如何设置 HADR 环境，以及如何使用数据库角色切换和故障转移方案执行接管。

您学习了如何使用 HADR 使数据库具有高可用性。如果主数据库停机，那么它的备用数据库将接管，并成为新的主数据库。

为了启用自动客户机重路由特性，在主数据库上发出 UPDATE ALTERNATE SERVER 命令。该命令的语法如下：

UPDATE ALTERNATE SERVER FOR DATABASE database-alias
USING HOSTNAME alternate-server-hostname PORT port-number

为了在 server1 上的 TEST1 数据库上启用客户机重路由特性，以便在接管之后已有的和新的客户机连接被重新路由到 server2，在 server1 上发出以下命令：

UPDATE ALTERNATE SERVER FOR DATABASE test1 USING 
HOSTNAME server2.torolab.ibm.com PORT 50000

在这个例子中，50000 是 SVCENAME 端口，而不是 HADR 端口。

备用服务器信息存储在 server1 的数据库目录中。如果发出一个 LIST DB DIRECTORY 命令，那么可以注意到备用服务器信息（主机名和端口号）已经被添加：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

现在让我们来看一个关于如何在启用了自动客户机重路由特性的数据库上执行接管的例子。

在这个例子中，不带 BY FORCE 选项执行一个接管。

首先，建立到 server1 上的 TEST1 数据库的一个远程客户机连接。为此，只需在一个远程 DB2 客户机上发出一条 CONNECT TO DATABASE 命令：

CONNECT TO DB test1 USER user1

为了建立那样的连接，客户机必须已经被配置为连接到 server1。关于如何配置远程客户机连接的信息，请参考本系列中的第一篇教程。

在建立连接之后，主服务器上的备用服务器信息被获取并存储在客户机的数据库目录中：

 Database alias                       = TEST1
 Database name                        = TEST1
 Node name                            = server1
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Remote
 Catalog database partition number    = -1
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

确保该连接已成功建立，并且可以查询 TEST1 数据库。在 server1 上发出一条 LIST APPLICATION 命令，它应该显示数据库 TEST1 上的远程客户机连接：

D:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      8          9.26.94.149.24336.060601000305
                                                         TEST1    1

接着，在 TEST1 数据库上执行接管。在备用服务器 server2 上发出以下命令：

TAKEOVER HADR ON DB test1

让我们看看这次接管完成后远程客户机连接有什么变化。

再次尝试从客户机查询 TEST1 数据库。对 TEST1 数据库的任何查询应该都会返回一个错误消息。例如，从客户机连接发出一条 LIST TABLES 命令：

D:\Programs\IBM\SQLLIB\BIN>db2 list tables
SQL30108N A connection failed but has been re-established. 
The hostname or IP address is "server2" and the service name or port number is "50000". 
Special registers may or may not be re-attempted (Reason code = "1").  
SQLSTATE=08506

这证明客户机重路由特性在起作用。现在您已经连接到新的主服务器，即 server2。

在 server2 上发出一条 LIST APPLICATIONS 命令。您可以看到，远程客户机连接已经被重新路由到那里：

H:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      55         9.26.94.149.29200.060601001803
                                                         TEST1    1

如果再次查询数据库，那么可以从新的主服务器得到一个响应。而且，到原来主服务器的新连接也被重新路由到新的主服务器。

使用 GET SNAPSHOT 命令可以获得数据库的 HADR 状态。在 server2 上发出以下命令，应该可以看到 server2 已经接管了主数据库角色：

db2 "get snapshot for database on test1"

  HADR Status
  Role                   = Primary
  State                  = Peer
  Synchronization mode   = Nearsync
  Connection status      = Connected , 05/31/2006 20:17:24.989618
  Heartbeats missed      = 0
  Local host             = server2.torolab.ibm.com
  Local service          = 80000
  Remote host            = server1.torolab.ibm.com
  Remote service         = 70000
  Remote instance        = db2inst1
  timeout(seconds)       = 120
  Primary log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Standby log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Log gap running average(bytes) = 0

在执行接管操作之后，如果出故障的数据库又可以使用，它不会自动恢复主数据库的角色。

通过以下步骤可以使之重新成为主数据库：

修复原来的主数据库所在的系统。这包括修复有问题的硬件或者重新启动崩溃的操作系统。
重新启动出故障的主数据库，使之成为一个备用数据库。
执行一个接管操作，使之接管主数据库的角色。

当原来的主数据库重新以备用数据库的角色加入 HADR 对之后，执行一个接管操作来切换数据库的角色，使原来的主数据库再次成为主数据库。

为了停止 TEST1 数据库上的 HADR，发出：

STOP HADR ON DB test1

您可以看到，HADR 是实现高可用性解决方案的一个强大的特性。提供了一个名为 HADR 向导的图形化用户界面工具，以帮助您设置和配置 HADR。

如果选择 Set Up，那么就会打开一个如图 15 所示的逐步向导。

如果使用 Control Center 设置 HADR 环境，则会自动启用自动客户机重路由特性。

阅读(23798) | 评论(0) | 转发(0) |

上一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（4）

下一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（6）

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

16024965号-6

高可用性灾难恢复（HADR）

DB2 高可用性灾难恢复（HADR）是一种数据库复制特性，它提供了一种高可用性解决方案。目前，HADR 只用于单分区数据库环境。

为了设置 HADR 环境，要更新一些数据库配置参数。

首先，必须启用主数据库上的归档日志记录。请参阅备份和恢复教程，以了解如何启用归档日志记录。

表 1 列出了与 HADR 相关的数据库配置参数的描述。本教程后面将给出一个关于如何更新这些参数的例子。

与 HADR 相关的数据库配置参数	描述
HADR_LOCAL_HOST	指定 HADR TCPIP 通信的本地主机。主机名和 IP 地址都可以使用
HADR_LOCAL_SVC	指定 TCPIP 服务名和端口号，HADR 进程将在本地主机上接受该服务或端口的连接。这个端口不能与 HADR 实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_HOST	指定远程 HADR 节点的 TCPIP 主机名或 IP 地址
HADR_REMOTE_SVC	指定 TCPIP 服务名或端口号，HADR 进程将在远程节点上接受该服务或端口的连接。这个端口不能与远程实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_INST	指定远程服务器的实例名。DB2 Control Center 之类的管理工具将使用这个参数与远程服务器联系
HADR_TIMEOUT	HADR 进程在认为一次通信尝试失败之前所等待的时间（以秒为单位）。默认值为 120 秒
HADR_SYNCMODE	指定同步模式。它决定当系统处于对等状态时，主日志写与备用数据库如何同步。有效值有 SYNC、NEARSYNC 和 ASYNC。默认值为 NEARSYNC。（本节后面将讨论对等状态）。
HADR_DB_ROLE	指定一个数据库当前的角色。有效值有 STANDARD、PRIMARY 和 STANDBY。STANDARD 意味着数据库没有启用 HADR。

当备用数据库第一次启动时，它进入 local catch-up 状态。本地日志路径中的日志文件（如果有的话）将被读取，并应用到备用数据库。

当到达本地日志文件的最后时，备用数据库进入 remote catch-up 状态。它重演主数据库的归档日志和活动日志，直到备用数据库应用了最近的活动日志。

当主系统上的所有日志文件都已经被重演时，主数据库和备用数据库就进入对等（peer）状态。

在同步模式中，日志写只有在以下情况下才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库的日志文件中。

主数据库与备用数据库中的日志记录几乎（或近似）是同步的，因为只有在以下情况下，日志写才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库上的主存中。

在这种模式下，主数据库不等待收到备用数据库的通知。只有在以下情况下，日志写才被认为是成功的：

日志记录已经被写到主数据库上的日志文件中。
日志记录已经被传送到备用数据库；不需要通知。

HADR 是通过以下三个简单的命令来管理的：

START HADR
STOP HADR
TAKENOVER HADR

这些命令的语法如下：

START HADR ON DATABASE database-alias
[USER userid] [USING password] 
AS PRIMARY | STANDBY [BY FORCE]

STOP HADR ON DATABASE database-alias 
[USER userid] [USING password] 

TAKEOVER HADR ON DATABASE database-alias
[USER userid] [USING password] 
[BY FORCE]

您已经学习了 HADR 的概念，现在可以学习如何设置 HADR 环境。

使用另一个数据库服务器 server2.torolab.ibm.com 作为备用服务器。TEST1 当前不在备用服务器上。

服务名	实例名	SVCENAME 或端口号	数据库名
server1.torolab.ibm.com	DB2INST1	50000	TEST1
server2.torolab.ibm.com	DB2INST1	50000	--

第一次初始化 HADR 时，执行图 13 所示的五个步骤：

确定主服务器和备用服务器。决定主机名、主机 IP 地址和每个 HADR 数据库的服务名或端口号。
您已经确定了主服务器和备用服务器。主服务器是 server1。备用服务器是 server2。

确保这两个服务器是通过 TCPIP 相互通信的。尝试用主机名在这两个服务器上相互 ping 对方。应确保输出没有错误。如果主机名不能使用，那么尝试使用它们的 TCPIP 地址。选用两者中最好用的一种用于 HADR 配置。

通过克隆主数据库创建备用数据库。

有两种方案可用于克隆主数据库：

一种方案是为主数据库做一个备份，并在备用数据库上恢复这个数据库备份。这种方案使用标准备份和恢复方法。
克隆主数据库的另一种方案是使用分割镜像。为主数据库做一个分割镜像，然后在备用服务器上初始化该分割镜像。当初始化分割镜像时，必须在 db2inidb 命令中使用 standby 选项，以便使用 mirror 和 snapshot 选项。

在这个例子种，使用备份/恢复方法来创建备用数据库。

首先为 server1 上的主数据库 TEST1 做一个备份：

BACKUP DB test1

接着，通过 ftp 将备份镜像传送到备用服务器，并恢复该备份镜像。

将备份镜像恢复到与主服务器上相同的位置。在主服务器上，发出 LIST DB DIRECTORY 命令将显示：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            =
 Alternate server port number         =

数据库位于主服务器上的 C: 盘上。当在备用服务器上恢复备份镜像时，也将它恢复到 C: 盘。在备用服务器 server2 上，发出以下命令来恢复 TEST1 数据库：

RESTORE DB test1 ON C:

在主数据库和备用数据库上设置以下 HADR 配置参数：

HADR_LOCAL_HOST
HADR_LOCAL_SVC
HADR_REMOTE_HOST
HADR_REMOTE_SVC
HADR_REMOTE_INST
HADR_SYNCMODE
LOGINDEXBUILD

在主服务器上，为 HADR 使用端口号 70000。更新 Windows\System32\drivers\etc\services 文件，在其中添加以下一行：

Hadr_port 	70000/tcp

在备用服务器上的 services 文件中添加以下一行：

Hadr_port 	80000/tcp

为 HADR_SYNCMODE 使用默认值，即 NEARSYNC。

您已经有了配置 HADR 参数所需的所有信息。发出以下命令来配置备用服务器上的参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在主数据库服务器上，配置相同的一组参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在备用数据库上使用 START HADR 命令启动 HADR：
START HADR ON DB test1 AS STANDBY
在启动主数据库之前启动备用数据库。如果先启动主数据库，那么，如果没有在 HADR_TIMEOUT 数据库配置参数指定的期限内启动备用数据库，那么主数据库的启动过程就会失败。
在主数据库上启动 HADR，如下面的例子所示：
START HADR ON DB test1 AS PRIMARY
HADR 现在已经在主数据库和备用数据库上启动了。

当第一次启动主服务器时，它等待备用服务器与它联系。如果在指定期限内备用服务器没有与主服务器联系，那么 HADR 将不启动。这个期限可以用 HADR_TIMEOUT 配置参数（见表 1）来配置。这样做的目的是避免两个系统在偶然的情况下与主服务器同时启动。

在 HADR 启动过程中，数据库经历以下状态：local catch-up、remote catch-up pending、remote catch-up 和对等状态。日志被自动从主服务器传送到备用服务器，然后在备用服务器上重演。这是为了确保备用数据库跟上主数据库的变化。

强烈建议在主数据库和备用数据库所在的系统上使用相同的数据库配置参数和数据库管理器配置参数。否则，备用数据库就不会像主数据库一样执行。

一个例外是 LOGFILSIZ 数据库配置参数。这个参数的值被备用服务器所忽略。备用服务器自动创建与主数据库上的日志文件大小相匹配的日志文件。这保证了两个数据库上的日志文件是一致的。

在主数据库与备用数据库之间切换数据库角色，也就是说，备用数据库变成主数据库，主数据库变成备用数据库。
从主数据库故障转移到备用数据库。

   GET SNAPSHOT FOR DATABASE ON test1

下面的命令在备用数据库 TEST1 上开始 HADR 数据库切换角色操作：

   TAKEOVER HADR ON DB test1

故障转移方案不切换数据库角色。在故障转移操作期间，备用数据库接管主数据库角色，但是主数据库不会变成备用数据库。

下面的命令在数据库 TEST1 上开始一个 HADR 故障转移操作：

   TAKEOVER HADR ON DB test1 BY FORCE

表 3 和 4 总结了在备用数据库上发出的 TAKEOVER HADR 命令的行为，以及备用数据库所处的对应的 HADR 状态：

备用数据库的状态	接管行为
对等	主数据库和备用数据库都切换角色
Local catch-up or remote catch-up	错误
Remote catch-up pending	错误

备用数据库的状态	接管行为
对等	备用数据库通知主数据库关闭。备用数据库停止接收来自主数据库的日志，完成它已经收到的日志的重演，然后变成主数据库。备用数据库不用等到主数据库发来通知确认它受到接管通知或者它已经关闭
Local catch-up OR remote catch-up	错误
Remote catch-up pending	备用数据库变成主数据库

您已经看到了如何设置 HADR 环境，以及如何使用数据库角色切换和故障转移方案执行接管。

您学习了如何使用 HADR 使数据库具有高可用性。如果主数据库停机，那么它的备用数据库将接管，并成为新的主数据库。

为了启用自动客户机重路由特性，在主数据库上发出 UPDATE ALTERNATE SERVER 命令。该命令的语法如下：

UPDATE ALTERNATE SERVER FOR DATABASE database-alias
USING HOSTNAME alternate-server-hostname PORT port-number

为了在 server1 上的 TEST1 数据库上启用客户机重路由特性，以便在接管之后已有的和新的客户机连接被重新路由到 server2，在 server1 上发出以下命令：

UPDATE ALTERNATE SERVER FOR DATABASE test1 USING 
HOSTNAME server2.torolab.ibm.com PORT 50000

在这个例子中，50000 是 SVCENAME 端口，而不是 HADR 端口。

备用服务器信息存储在 server1 的数据库目录中。如果发出一个 LIST DB DIRECTORY 命令，那么可以注意到备用服务器信息（主机名和端口号）已经被添加：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

现在让我们来看一个关于如何在启用了自动客户机重路由特性的数据库上执行接管的例子。

在这个例子中，不带 BY FORCE 选项执行一个接管。

首先，建立到 server1 上的 TEST1 数据库的一个远程客户机连接。为此，只需在一个远程 DB2 客户机上发出一条 CONNECT TO DATABASE 命令：

CONNECT TO DB test1 USER user1

为了建立那样的连接，客户机必须已经被配置为连接到 server1。关于如何配置远程客户机连接的信息，请参考本系列中的第一篇教程。

在建立连接之后，主服务器上的备用服务器信息被获取并存储在客户机的数据库目录中：

 Database alias                       = TEST1
 Database name                        = TEST1
 Node name                            = server1
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Remote
 Catalog database partition number    = -1
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

确保该连接已成功建立，并且可以查询 TEST1 数据库。在 server1 上发出一条 LIST APPLICATION 命令，它应该显示数据库 TEST1 上的远程客户机连接：

D:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      8          9.26.94.149.24336.060601000305
                                                         TEST1    1

接着，在 TEST1 数据库上执行接管。在备用服务器 server2 上发出以下命令：

TAKEOVER HADR ON DB test1

让我们看看这次接管完成后远程客户机连接有什么变化。

再次尝试从客户机查询 TEST1 数据库。对 TEST1 数据库的任何查询应该都会返回一个错误消息。例如，从客户机连接发出一条 LIST TABLES 命令：

D:\Programs\IBM\SQLLIB\BIN>db2 list tables
SQL30108N A connection failed but has been re-established. 
The hostname or IP address is "server2" and the service name or port number is "50000". 
Special registers may or may not be re-attempted (Reason code = "1").  
SQLSTATE=08506

这证明客户机重路由特性在起作用。现在您已经连接到新的主服务器，即 server2。

在 server2 上发出一条 LIST APPLICATIONS 命令。您可以看到，远程客户机连接已经被重新路由到那里：

H:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      55         9.26.94.149.29200.060601001803
                                                         TEST1    1

如果再次查询数据库，那么可以从新的主服务器得到一个响应。而且，到原来主服务器的新连接也被重新路由到新的主服务器。

使用 GET SNAPSHOT 命令可以获得数据库的 HADR 状态。在 server2 上发出以下命令，应该可以看到 server2 已经接管了主数据库角色：

db2 "get snapshot for database on test1"

  HADR Status
  Role                   = Primary
  State                  = Peer
  Synchronization mode   = Nearsync
  Connection status      = Connected , 05/31/2006 20:17:24.989618
  Heartbeats missed      = 0
  Local host             = server2.torolab.ibm.com
  Local service          = 80000
  Remote host            = server1.torolab.ibm.com
  Remote service         = 70000
  Remote instance        = db2inst1
  timeout(seconds)       = 120
  Primary log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Standby log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Log gap running average(bytes) = 0

在执行接管操作之后，如果出故障的数据库又可以使用，它不会自动恢复主数据库的角色。

通过以下步骤可以使之重新成为主数据库：

修复原来的主数据库所在的系统。这包括修复有问题的硬件或者重新启动崩溃的操作系统。
重新启动出故障的主数据库，使之成为一个备用数据库。
执行一个接管操作，使之接管主数据库的角色。

当原来的主数据库重新以备用数据库的角色加入 HADR 对之后，执行一个接管操作来切换数据库的角色，使原来的主数据库再次成为主数据库。

为了停止 TEST1 数据库上的 HADR，发出：

STOP HADR ON DB test1

您可以看到，HADR 是实现高可用性解决方案的一个强大的特性。提供了一个名为 HADR 向导的图形化用户界面工具，以帮助您设置和配置 HADR。

如果选择 Set Up，那么就会打开一个如图 15 所示的逐步向导。

如果使用 Control Center 设置 HADR 环境，则会自动启用自动客户机重路由特性。

阅读(23797) | 评论(0) | 转发(0) |

上一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（4）

下一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（6）

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

16024965号-6

高可用性灾难恢复（HADR）

DB2 高可用性灾难恢复（HADR）是一种数据库复制特性，它提供了一种高可用性解决方案。目前，HADR 只用于单分区数据库环境。

为了设置 HADR 环境，要更新一些数据库配置参数。

首先，必须启用主数据库上的归档日志记录。请参阅备份和恢复教程，以了解如何启用归档日志记录。

表 1 列出了与 HADR 相关的数据库配置参数的描述。本教程后面将给出一个关于如何更新这些参数的例子。

与 HADR 相关的数据库配置参数	描述
HADR_LOCAL_HOST	指定 HADR TCPIP 通信的本地主机。主机名和 IP 地址都可以使用
HADR_LOCAL_SVC	指定 TCPIP 服务名和端口号，HADR 进程将在本地主机上接受该服务或端口的连接。这个端口不能与 HADR 实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_HOST	指定远程 HADR 节点的 TCPIP 主机名或 IP 地址
HADR_REMOTE_SVC	指定 TCPIP 服务名或端口号，HADR 进程将在远程节点上接受该服务或端口的连接。这个端口不能与远程实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_INST	指定远程服务器的实例名。DB2 Control Center 之类的管理工具将使用这个参数与远程服务器联系
HADR_TIMEOUT	HADR 进程在认为一次通信尝试失败之前所等待的时间（以秒为单位）。默认值为 120 秒
HADR_SYNCMODE	指定同步模式。它决定当系统处于对等状态时，主日志写与备用数据库如何同步。有效值有 SYNC、NEARSYNC 和 ASYNC。默认值为 NEARSYNC。（本节后面将讨论对等状态）。
HADR_DB_ROLE	指定一个数据库当前的角色。有效值有 STANDARD、PRIMARY 和 STANDBY。STANDARD 意味着数据库没有启用 HADR。

当备用数据库第一次启动时，它进入 local catch-up 状态。本地日志路径中的日志文件（如果有的话）将被读取，并应用到备用数据库。

当到达本地日志文件的最后时，备用数据库进入 remote catch-up 状态。它重演主数据库的归档日志和活动日志，直到备用数据库应用了最近的活动日志。

当主系统上的所有日志文件都已经被重演时，主数据库和备用数据库就进入对等（peer）状态。

在同步模式中，日志写只有在以下情况下才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库的日志文件中。

主数据库与备用数据库中的日志记录几乎（或近似）是同步的，因为只有在以下情况下，日志写才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库上的主存中。

在这种模式下，主数据库不等待收到备用数据库的通知。只有在以下情况下，日志写才被认为是成功的：

日志记录已经被写到主数据库上的日志文件中。
日志记录已经被传送到备用数据库；不需要通知。

HADR 是通过以下三个简单的命令来管理的：

START HADR
STOP HADR
TAKENOVER HADR

这些命令的语法如下：

START HADR ON DATABASE database-alias
[USER userid] [USING password] 
AS PRIMARY | STANDBY [BY FORCE]

STOP HADR ON DATABASE database-alias 
[USER userid] [USING password] 

TAKEOVER HADR ON DATABASE database-alias
[USER userid] [USING password] 
[BY FORCE]

您已经学习了 HADR 的概念，现在可以学习如何设置 HADR 环境。

使用另一个数据库服务器 server2.torolab.ibm.com 作为备用服务器。TEST1 当前不在备用服务器上。

服务名	实例名	SVCENAME 或端口号	数据库名
server1.torolab.ibm.com	DB2INST1	50000	TEST1
server2.torolab.ibm.com	DB2INST1	50000	--

第一次初始化 HADR 时，执行图 13 所示的五个步骤：

确定主服务器和备用服务器。决定主机名、主机 IP 地址和每个 HADR 数据库的服务名或端口号。
您已经确定了主服务器和备用服务器。主服务器是 server1。备用服务器是 server2。

确保这两个服务器是通过 TCPIP 相互通信的。尝试用主机名在这两个服务器上相互 ping 对方。应确保输出没有错误。如果主机名不能使用，那么尝试使用它们的 TCPIP 地址。选用两者中最好用的一种用于 HADR 配置。

通过克隆主数据库创建备用数据库。

有两种方案可用于克隆主数据库：

一种方案是为主数据库做一个备份，并在备用数据库上恢复这个数据库备份。这种方案使用标准备份和恢复方法。
克隆主数据库的另一种方案是使用分割镜像。为主数据库做一个分割镜像，然后在备用服务器上初始化该分割镜像。当初始化分割镜像时，必须在 db2inidb 命令中使用 standby 选项，以便使用 mirror 和 snapshot 选项。

在这个例子种，使用备份/恢复方法来创建备用数据库。

首先为 server1 上的主数据库 TEST1 做一个备份：

BACKUP DB test1

接着，通过 ftp 将备份镜像传送到备用服务器，并恢复该备份镜像。

将备份镜像恢复到与主服务器上相同的位置。在主服务器上，发出 LIST DB DIRECTORY 命令将显示：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            =
 Alternate server port number         =

数据库位于主服务器上的 C: 盘上。当在备用服务器上恢复备份镜像时，也将它恢复到 C: 盘。在备用服务器 server2 上，发出以下命令来恢复 TEST1 数据库：

RESTORE DB test1 ON C:

在主数据库和备用数据库上设置以下 HADR 配置参数：

HADR_LOCAL_HOST
HADR_LOCAL_SVC
HADR_REMOTE_HOST
HADR_REMOTE_SVC
HADR_REMOTE_INST
HADR_SYNCMODE
LOGINDEXBUILD

在主服务器上，为 HADR 使用端口号 70000。更新 Windows\System32\drivers\etc\services 文件，在其中添加以下一行：

Hadr_port 	70000/tcp

在备用服务器上的 services 文件中添加以下一行：

Hadr_port 	80000/tcp

为 HADR_SYNCMODE 使用默认值，即 NEARSYNC。

您已经有了配置 HADR 参数所需的所有信息。发出以下命令来配置备用服务器上的参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在主数据库服务器上，配置相同的一组参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在备用数据库上使用 START HADR 命令启动 HADR：
START HADR ON DB test1 AS STANDBY
在启动主数据库之前启动备用数据库。如果先启动主数据库，那么，如果没有在 HADR_TIMEOUT 数据库配置参数指定的期限内启动备用数据库，那么主数据库的启动过程就会失败。
在主数据库上启动 HADR，如下面的例子所示：
START HADR ON DB test1 AS PRIMARY
HADR 现在已经在主数据库和备用数据库上启动了。

当第一次启动主服务器时，它等待备用服务器与它联系。如果在指定期限内备用服务器没有与主服务器联系，那么 HADR 将不启动。这个期限可以用 HADR_TIMEOUT 配置参数（见表 1）来配置。这样做的目的是避免两个系统在偶然的情况下与主服务器同时启动。

在 HADR 启动过程中，数据库经历以下状态：local catch-up、remote catch-up pending、remote catch-up 和对等状态。日志被自动从主服务器传送到备用服务器，然后在备用服务器上重演。这是为了确保备用数据库跟上主数据库的变化。

强烈建议在主数据库和备用数据库所在的系统上使用相同的数据库配置参数和数据库管理器配置参数。否则，备用数据库就不会像主数据库一样执行。

一个例外是 LOGFILSIZ 数据库配置参数。这个参数的值被备用服务器所忽略。备用服务器自动创建与主数据库上的日志文件大小相匹配的日志文件。这保证了两个数据库上的日志文件是一致的。

在主数据库与备用数据库之间切换数据库角色，也就是说，备用数据库变成主数据库，主数据库变成备用数据库。
从主数据库故障转移到备用数据库。

   GET SNAPSHOT FOR DATABASE ON test1

下面的命令在备用数据库 TEST1 上开始 HADR 数据库切换角色操作：

   TAKEOVER HADR ON DB test1

故障转移方案不切换数据库角色。在故障转移操作期间，备用数据库接管主数据库角色，但是主数据库不会变成备用数据库。

下面的命令在数据库 TEST1 上开始一个 HADR 故障转移操作：

   TAKEOVER HADR ON DB test1 BY FORCE

表 3 和 4 总结了在备用数据库上发出的 TAKEOVER HADR 命令的行为，以及备用数据库所处的对应的 HADR 状态：

备用数据库的状态	接管行为
对等	主数据库和备用数据库都切换角色
Local catch-up or remote catch-up	错误
Remote catch-up pending	错误

备用数据库的状态	接管行为
对等	备用数据库通知主数据库关闭。备用数据库停止接收来自主数据库的日志，完成它已经收到的日志的重演，然后变成主数据库。备用数据库不用等到主数据库发来通知确认它受到接管通知或者它已经关闭
Local catch-up OR remote catch-up	错误
Remote catch-up pending	备用数据库变成主数据库

您已经看到了如何设置 HADR 环境，以及如何使用数据库角色切换和故障转移方案执行接管。

您学习了如何使用 HADR 使数据库具有高可用性。如果主数据库停机，那么它的备用数据库将接管，并成为新的主数据库。

为了启用自动客户机重路由特性，在主数据库上发出 UPDATE ALTERNATE SERVER 命令。该命令的语法如下：

UPDATE ALTERNATE SERVER FOR DATABASE database-alias
USING HOSTNAME alternate-server-hostname PORT port-number

为了在 server1 上的 TEST1 数据库上启用客户机重路由特性，以便在接管之后已有的和新的客户机连接被重新路由到 server2，在 server1 上发出以下命令：

UPDATE ALTERNATE SERVER FOR DATABASE test1 USING 
HOSTNAME server2.torolab.ibm.com PORT 50000

在这个例子中，50000 是 SVCENAME 端口，而不是 HADR 端口。

备用服务器信息存储在 server1 的数据库目录中。如果发出一个 LIST DB DIRECTORY 命令，那么可以注意到备用服务器信息（主机名和端口号）已经被添加：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

现在让我们来看一个关于如何在启用了自动客户机重路由特性的数据库上执行接管的例子。

在这个例子中，不带 BY FORCE 选项执行一个接管。

首先，建立到 server1 上的 TEST1 数据库的一个远程客户机连接。为此，只需在一个远程 DB2 客户机上发出一条 CONNECT TO DATABASE 命令：

CONNECT TO DB test1 USER user1

为了建立那样的连接，客户机必须已经被配置为连接到 server1。关于如何配置远程客户机连接的信息，请参考本系列中的第一篇教程。

在建立连接之后，主服务器上的备用服务器信息被获取并存储在客户机的数据库目录中：

 Database alias                       = TEST1
 Database name                        = TEST1
 Node name                            = server1
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Remote
 Catalog database partition number    = -1
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

确保该连接已成功建立，并且可以查询 TEST1 数据库。在 server1 上发出一条 LIST APPLICATION 命令，它应该显示数据库 TEST1 上的远程客户机连接：

D:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      8          9.26.94.149.24336.060601000305
                                                         TEST1    1

接着，在 TEST1 数据库上执行接管。在备用服务器 server2 上发出以下命令：

TAKEOVER HADR ON DB test1

让我们看看这次接管完成后远程客户机连接有什么变化。

再次尝试从客户机查询 TEST1 数据库。对 TEST1 数据库的任何查询应该都会返回一个错误消息。例如，从客户机连接发出一条 LIST TABLES 命令：

D:\Programs\IBM\SQLLIB\BIN>db2 list tables
SQL30108N A connection failed but has been re-established. 
The hostname or IP address is "server2" and the service name or port number is "50000". 
Special registers may or may not be re-attempted (Reason code = "1").  
SQLSTATE=08506

这证明客户机重路由特性在起作用。现在您已经连接到新的主服务器，即 server2。

在 server2 上发出一条 LIST APPLICATIONS 命令。您可以看到，远程客户机连接已经被重新路由到那里：

H:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      55         9.26.94.149.29200.060601001803
                                                         TEST1    1

如果再次查询数据库，那么可以从新的主服务器得到一个响应。而且，到原来主服务器的新连接也被重新路由到新的主服务器。

使用 GET SNAPSHOT 命令可以获得数据库的 HADR 状态。在 server2 上发出以下命令，应该可以看到 server2 已经接管了主数据库角色：

db2 "get snapshot for database on test1"

  HADR Status
  Role                   = Primary
  State                  = Peer
  Synchronization mode   = Nearsync
  Connection status      = Connected , 05/31/2006 20:17:24.989618
  Heartbeats missed      = 0
  Local host             = server2.torolab.ibm.com
  Local service          = 80000
  Remote host            = server1.torolab.ibm.com
  Remote service         = 70000
  Remote instance        = db2inst1
  timeout(seconds)       = 120
  Primary log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Standby log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Log gap running average(bytes) = 0

在执行接管操作之后，如果出故障的数据库又可以使用，它不会自动恢复主数据库的角色。

通过以下步骤可以使之重新成为主数据库：

修复原来的主数据库所在的系统。这包括修复有问题的硬件或者重新启动崩溃的操作系统。
重新启动出故障的主数据库，使之成为一个备用数据库。
执行一个接管操作，使之接管主数据库的角色。

当原来的主数据库重新以备用数据库的角色加入 HADR 对之后，执行一个接管操作来切换数据库的角色，使原来的主数据库再次成为主数据库。

为了停止 TEST1 数据库上的 HADR，发出：

STOP HADR ON DB test1

您可以看到，HADR 是实现高可用性解决方案的一个强大的特性。提供了一个名为 HADR 向导的图形化用户界面工具，以帮助您设置和配置 HADR。

如果选择 Set Up，那么就会打开一个如图 15 所示的逐步向导。

如果使用 Control Center 设置 HADR 环境，则会自动启用自动客户机重路由特性。

阅读(23796) | 评论(0) | 转发(0) |

上一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（4）

下一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（6）

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

16024965号-6

高可用性灾难恢复（HADR）

DB2 高可用性灾难恢复（HADR）是一种数据库复制特性，它提供了一种高可用性解决方案。目前，HADR 只用于单分区数据库环境。

为了设置 HADR 环境，要更新一些数据库配置参数。

首先，必须启用主数据库上的归档日志记录。请参阅备份和恢复教程，以了解如何启用归档日志记录。

表 1 列出了与 HADR 相关的数据库配置参数的描述。本教程后面将给出一个关于如何更新这些参数的例子。

与 HADR 相关的数据库配置参数	描述
HADR_LOCAL_HOST	指定 HADR TCPIP 通信的本地主机。主机名和 IP 地址都可以使用
HADR_LOCAL_SVC	指定 TCPIP 服务名和端口号，HADR 进程将在本地主机上接受该服务或端口的连接。这个端口不能与 HADR 实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_HOST	指定远程 HADR 节点的 TCPIP 主机名或 IP 地址
HADR_REMOTE_SVC	指定 TCPIP 服务名或端口号，HADR 进程将在远程节点上接受该服务或端口的连接。这个端口不能与远程实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_INST	指定远程服务器的实例名。DB2 Control Center 之类的管理工具将使用这个参数与远程服务器联系
HADR_TIMEOUT	HADR 进程在认为一次通信尝试失败之前所等待的时间（以秒为单位）。默认值为 120 秒
HADR_SYNCMODE	指定同步模式。它决定当系统处于对等状态时，主日志写与备用数据库如何同步。有效值有 SYNC、NEARSYNC 和 ASYNC。默认值为 NEARSYNC。（本节后面将讨论对等状态）。
HADR_DB_ROLE	指定一个数据库当前的角色。有效值有 STANDARD、PRIMARY 和 STANDBY。STANDARD 意味着数据库没有启用 HADR。

当备用数据库第一次启动时，它进入 local catch-up 状态。本地日志路径中的日志文件（如果有的话）将被读取，并应用到备用数据库。

当到达本地日志文件的最后时，备用数据库进入 remote catch-up 状态。它重演主数据库的归档日志和活动日志，直到备用数据库应用了最近的活动日志。

当主系统上的所有日志文件都已经被重演时，主数据库和备用数据库就进入对等（peer）状态。

在同步模式中，日志写只有在以下情况下才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库的日志文件中。

主数据库与备用数据库中的日志记录几乎（或近似）是同步的，因为只有在以下情况下，日志写才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库上的主存中。

在这种模式下，主数据库不等待收到备用数据库的通知。只有在以下情况下，日志写才被认为是成功的：

日志记录已经被写到主数据库上的日志文件中。
日志记录已经被传送到备用数据库；不需要通知。

HADR 是通过以下三个简单的命令来管理的：

START HADR
STOP HADR
TAKENOVER HADR

这些命令的语法如下：

START HADR ON DATABASE database-alias
[USER userid] [USING password] 
AS PRIMARY | STANDBY [BY FORCE]

STOP HADR ON DATABASE database-alias 
[USER userid] [USING password] 

TAKEOVER HADR ON DATABASE database-alias
[USER userid] [USING password] 
[BY FORCE]

您已经学习了 HADR 的概念，现在可以学习如何设置 HADR 环境。

使用另一个数据库服务器 server2.torolab.ibm.com 作为备用服务器。TEST1 当前不在备用服务器上。

服务名	实例名	SVCENAME 或端口号	数据库名
server1.torolab.ibm.com	DB2INST1	50000	TEST1
server2.torolab.ibm.com	DB2INST1	50000	--

第一次初始化 HADR 时，执行图 13 所示的五个步骤：

确定主服务器和备用服务器。决定主机名、主机 IP 地址和每个 HADR 数据库的服务名或端口号。
您已经确定了主服务器和备用服务器。主服务器是 server1。备用服务器是 server2。

确保这两个服务器是通过 TCPIP 相互通信的。尝试用主机名在这两个服务器上相互 ping 对方。应确保输出没有错误。如果主机名不能使用，那么尝试使用它们的 TCPIP 地址。选用两者中最好用的一种用于 HADR 配置。

通过克隆主数据库创建备用数据库。

有两种方案可用于克隆主数据库：

一种方案是为主数据库做一个备份，并在备用数据库上恢复这个数据库备份。这种方案使用标准备份和恢复方法。
克隆主数据库的另一种方案是使用分割镜像。为主数据库做一个分割镜像，然后在备用服务器上初始化该分割镜像。当初始化分割镜像时，必须在 db2inidb 命令中使用 standby 选项，以便使用 mirror 和 snapshot 选项。

在这个例子种，使用备份/恢复方法来创建备用数据库。

首先为 server1 上的主数据库 TEST1 做一个备份：

BACKUP DB test1

接着，通过 ftp 将备份镜像传送到备用服务器，并恢复该备份镜像。

将备份镜像恢复到与主服务器上相同的位置。在主服务器上，发出 LIST DB DIRECTORY 命令将显示：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            =
 Alternate server port number         =

数据库位于主服务器上的 C: 盘上。当在备用服务器上恢复备份镜像时，也将它恢复到 C: 盘。在备用服务器 server2 上，发出以下命令来恢复 TEST1 数据库：

RESTORE DB test1 ON C:

在主数据库和备用数据库上设置以下 HADR 配置参数：

HADR_LOCAL_HOST
HADR_LOCAL_SVC
HADR_REMOTE_HOST
HADR_REMOTE_SVC
HADR_REMOTE_INST
HADR_SYNCMODE
LOGINDEXBUILD

在主服务器上，为 HADR 使用端口号 70000。更新 Windows\System32\drivers\etc\services 文件，在其中添加以下一行：

Hadr_port 	70000/tcp

在备用服务器上的 services 文件中添加以下一行：

Hadr_port 	80000/tcp

为 HADR_SYNCMODE 使用默认值，即 NEARSYNC。

您已经有了配置 HADR 参数所需的所有信息。发出以下命令来配置备用服务器上的参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在主数据库服务器上，配置相同的一组参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在备用数据库上使用 START HADR 命令启动 HADR：
START HADR ON DB test1 AS STANDBY
在启动主数据库之前启动备用数据库。如果先启动主数据库，那么，如果没有在 HADR_TIMEOUT 数据库配置参数指定的期限内启动备用数据库，那么主数据库的启动过程就会失败。
在主数据库上启动 HADR，如下面的例子所示：
START HADR ON DB test1 AS PRIMARY
HADR 现在已经在主数据库和备用数据库上启动了。

当第一次启动主服务器时，它等待备用服务器与它联系。如果在指定期限内备用服务器没有与主服务器联系，那么 HADR 将不启动。这个期限可以用 HADR_TIMEOUT 配置参数（见表 1）来配置。这样做的目的是避免两个系统在偶然的情况下与主服务器同时启动。

在 HADR 启动过程中，数据库经历以下状态：local catch-up、remote catch-up pending、remote catch-up 和对等状态。日志被自动从主服务器传送到备用服务器，然后在备用服务器上重演。这是为了确保备用数据库跟上主数据库的变化。

强烈建议在主数据库和备用数据库所在的系统上使用相同的数据库配置参数和数据库管理器配置参数。否则，备用数据库就不会像主数据库一样执行。

一个例外是 LOGFILSIZ 数据库配置参数。这个参数的值被备用服务器所忽略。备用服务器自动创建与主数据库上的日志文件大小相匹配的日志文件。这保证了两个数据库上的日志文件是一致的。

在主数据库与备用数据库之间切换数据库角色，也就是说，备用数据库变成主数据库，主数据库变成备用数据库。
从主数据库故障转移到备用数据库。

   GET SNAPSHOT FOR DATABASE ON test1

下面的命令在备用数据库 TEST1 上开始 HADR 数据库切换角色操作：

   TAKEOVER HADR ON DB test1

故障转移方案不切换数据库角色。在故障转移操作期间，备用数据库接管主数据库角色，但是主数据库不会变成备用数据库。

下面的命令在数据库 TEST1 上开始一个 HADR 故障转移操作：

   TAKEOVER HADR ON DB test1 BY FORCE

表 3 和 4 总结了在备用数据库上发出的 TAKEOVER HADR 命令的行为，以及备用数据库所处的对应的 HADR 状态：

备用数据库的状态	接管行为
对等	主数据库和备用数据库都切换角色
Local catch-up or remote catch-up	错误
Remote catch-up pending	错误

备用数据库的状态	接管行为
对等	备用数据库通知主数据库关闭。备用数据库停止接收来自主数据库的日志，完成它已经收到的日志的重演，然后变成主数据库。备用数据库不用等到主数据库发来通知确认它受到接管通知或者它已经关闭
Local catch-up OR remote catch-up	错误
Remote catch-up pending	备用数据库变成主数据库

您已经看到了如何设置 HADR 环境，以及如何使用数据库角色切换和故障转移方案执行接管。

您学习了如何使用 HADR 使数据库具有高可用性。如果主数据库停机，那么它的备用数据库将接管，并成为新的主数据库。

为了启用自动客户机重路由特性，在主数据库上发出 UPDATE ALTERNATE SERVER 命令。该命令的语法如下：

UPDATE ALTERNATE SERVER FOR DATABASE database-alias
USING HOSTNAME alternate-server-hostname PORT port-number

为了在 server1 上的 TEST1 数据库上启用客户机重路由特性，以便在接管之后已有的和新的客户机连接被重新路由到 server2，在 server1 上发出以下命令：

UPDATE ALTERNATE SERVER FOR DATABASE test1 USING 
HOSTNAME server2.torolab.ibm.com PORT 50000

在这个例子中，50000 是 SVCENAME 端口，而不是 HADR 端口。

备用服务器信息存储在 server1 的数据库目录中。如果发出一个 LIST DB DIRECTORY 命令，那么可以注意到备用服务器信息（主机名和端口号）已经被添加：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

现在让我们来看一个关于如何在启用了自动客户机重路由特性的数据库上执行接管的例子。

在这个例子中，不带 BY FORCE 选项执行一个接管。

首先，建立到 server1 上的 TEST1 数据库的一个远程客户机连接。为此，只需在一个远程 DB2 客户机上发出一条 CONNECT TO DATABASE 命令：

CONNECT TO DB test1 USER user1

为了建立那样的连接，客户机必须已经被配置为连接到 server1。关于如何配置远程客户机连接的信息，请参考本系列中的第一篇教程。

在建立连接之后，主服务器上的备用服务器信息被获取并存储在客户机的数据库目录中：

 Database alias                       = TEST1
 Database name                        = TEST1
 Node name                            = server1
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Remote
 Catalog database partition number    = -1
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

确保该连接已成功建立，并且可以查询 TEST1 数据库。在 server1 上发出一条 LIST APPLICATION 命令，它应该显示数据库 TEST1 上的远程客户机连接：

D:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      8          9.26.94.149.24336.060601000305
                                                         TEST1    1

接着，在 TEST1 数据库上执行接管。在备用服务器 server2 上发出以下命令：

TAKEOVER HADR ON DB test1

让我们看看这次接管完成后远程客户机连接有什么变化。

再次尝试从客户机查询 TEST1 数据库。对 TEST1 数据库的任何查询应该都会返回一个错误消息。例如，从客户机连接发出一条 LIST TABLES 命令：

D:\Programs\IBM\SQLLIB\BIN>db2 list tables
SQL30108N A connection failed but has been re-established. 
The hostname or IP address is "server2" and the service name or port number is "50000". 
Special registers may or may not be re-attempted (Reason code = "1").  
SQLSTATE=08506

这证明客户机重路由特性在起作用。现在您已经连接到新的主服务器，即 server2。

在 server2 上发出一条 LIST APPLICATIONS 命令。您可以看到，远程客户机连接已经被重新路由到那里：

H:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      55         9.26.94.149.29200.060601001803
                                                         TEST1    1

如果再次查询数据库，那么可以从新的主服务器得到一个响应。而且，到原来主服务器的新连接也被重新路由到新的主服务器。

使用 GET SNAPSHOT 命令可以获得数据库的 HADR 状态。在 server2 上发出以下命令，应该可以看到 server2 已经接管了主数据库角色：

db2 "get snapshot for database on test1"

  HADR Status
  Role                   = Primary
  State                  = Peer
  Synchronization mode   = Nearsync
  Connection status      = Connected , 05/31/2006 20:17:24.989618
  Heartbeats missed      = 0
  Local host             = server2.torolab.ibm.com
  Local service          = 80000
  Remote host            = server1.torolab.ibm.com
  Remote service         = 70000
  Remote instance        = db2inst1
  timeout(seconds)       = 120
  Primary log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Standby log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Log gap running average(bytes) = 0

在执行接管操作之后，如果出故障的数据库又可以使用，它不会自动恢复主数据库的角色。

通过以下步骤可以使之重新成为主数据库：

修复原来的主数据库所在的系统。这包括修复有问题的硬件或者重新启动崩溃的操作系统。
重新启动出故障的主数据库，使之成为一个备用数据库。
执行一个接管操作，使之接管主数据库的角色。

当原来的主数据库重新以备用数据库的角色加入 HADR 对之后，执行一个接管操作来切换数据库的角色，使原来的主数据库再次成为主数据库。

为了停止 TEST1 数据库上的 HADR，发出：

STOP HADR ON DB test1

您可以看到，HADR 是实现高可用性解决方案的一个强大的特性。提供了一个名为 HADR 向导的图形化用户界面工具，以帮助您设置和配置 HADR。

如果选择 Set Up，那么就会打开一个如图 15 所示的逐步向导。

如果使用 Control Center 设置 HADR 环境，则会自动启用自动客户机重路由特性。

阅读(23795) | 评论(0) | 转发(0) |

上一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（4）

下一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（6）

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

16024965号-6

高可用性灾难恢复（HADR）

DB2 高可用性灾难恢复（HADR）是一种数据库复制特性，它提供了一种高可用性解决方案。目前，HADR 只用于单分区数据库环境。

为了设置 HADR 环境，要更新一些数据库配置参数。

首先，必须启用主数据库上的归档日志记录。请参阅备份和恢复教程，以了解如何启用归档日志记录。

表 1 列出了与 HADR 相关的数据库配置参数的描述。本教程后面将给出一个关于如何更新这些参数的例子。

与 HADR 相关的数据库配置参数	描述
HADR_LOCAL_HOST	指定 HADR TCPIP 通信的本地主机。主机名和 IP 地址都可以使用
HADR_LOCAL_SVC	指定 TCPIP 服务名和端口号，HADR 进程将在本地主机上接受该服务或端口的连接。这个端口不能与 HADR 实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_HOST	指定远程 HADR 节点的 TCPIP 主机名或 IP 地址
HADR_REMOTE_SVC	指定 TCPIP 服务名或端口号，HADR 进程将在远程节点上接受该服务或端口的连接。这个端口不能与远程实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_INST	指定远程服务器的实例名。DB2 Control Center 之类的管理工具将使用这个参数与远程服务器联系
HADR_TIMEOUT	HADR 进程在认为一次通信尝试失败之前所等待的时间（以秒为单位）。默认值为 120 秒
HADR_SYNCMODE	指定同步模式。它决定当系统处于对等状态时，主日志写与备用数据库如何同步。有效值有 SYNC、NEARSYNC 和 ASYNC。默认值为 NEARSYNC。（本节后面将讨论对等状态）。
HADR_DB_ROLE	指定一个数据库当前的角色。有效值有 STANDARD、PRIMARY 和 STANDBY。STANDARD 意味着数据库没有启用 HADR。

当备用数据库第一次启动时，它进入 local catch-up 状态。本地日志路径中的日志文件（如果有的话）将被读取，并应用到备用数据库。

当到达本地日志文件的最后时，备用数据库进入 remote catch-up 状态。它重演主数据库的归档日志和活动日志，直到备用数据库应用了最近的活动日志。

当主系统上的所有日志文件都已经被重演时，主数据库和备用数据库就进入对等（peer）状态。

在同步模式中，日志写只有在以下情况下才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库的日志文件中。

主数据库与备用数据库中的日志记录几乎（或近似）是同步的，因为只有在以下情况下，日志写才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库上的主存中。

在这种模式下，主数据库不等待收到备用数据库的通知。只有在以下情况下，日志写才被认为是成功的：

日志记录已经被写到主数据库上的日志文件中。
日志记录已经被传送到备用数据库；不需要通知。

HADR 是通过以下三个简单的命令来管理的：

START HADR
STOP HADR
TAKENOVER HADR

这些命令的语法如下：

START HADR ON DATABASE database-alias
[USER userid] [USING password] 
AS PRIMARY | STANDBY [BY FORCE]

STOP HADR ON DATABASE database-alias 
[USER userid] [USING password] 

TAKEOVER HADR ON DATABASE database-alias
[USER userid] [USING password] 
[BY FORCE]

您已经学习了 HADR 的概念，现在可以学习如何设置 HADR 环境。

使用另一个数据库服务器 server2.torolab.ibm.com 作为备用服务器。TEST1 当前不在备用服务器上。

服务名	实例名	SVCENAME 或端口号	数据库名
server1.torolab.ibm.com	DB2INST1	50000	TEST1
server2.torolab.ibm.com	DB2INST1	50000	--

第一次初始化 HADR 时，执行图 13 所示的五个步骤：

确定主服务器和备用服务器。决定主机名、主机 IP 地址和每个 HADR 数据库的服务名或端口号。
您已经确定了主服务器和备用服务器。主服务器是 server1。备用服务器是 server2。

确保这两个服务器是通过 TCPIP 相互通信的。尝试用主机名在这两个服务器上相互 ping 对方。应确保输出没有错误。如果主机名不能使用，那么尝试使用它们的 TCPIP 地址。选用两者中最好用的一种用于 HADR 配置。

通过克隆主数据库创建备用数据库。

有两种方案可用于克隆主数据库：

一种方案是为主数据库做一个备份，并在备用数据库上恢复这个数据库备份。这种方案使用标准备份和恢复方法。
克隆主数据库的另一种方案是使用分割镜像。为主数据库做一个分割镜像，然后在备用服务器上初始化该分割镜像。当初始化分割镜像时，必须在 db2inidb 命令中使用 standby 选项，以便使用 mirror 和 snapshot 选项。

在这个例子种，使用备份/恢复方法来创建备用数据库。

首先为 server1 上的主数据库 TEST1 做一个备份：

BACKUP DB test1

接着，通过 ftp 将备份镜像传送到备用服务器，并恢复该备份镜像。

将备份镜像恢复到与主服务器上相同的位置。在主服务器上，发出 LIST DB DIRECTORY 命令将显示：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            =
 Alternate server port number         =

数据库位于主服务器上的 C: 盘上。当在备用服务器上恢复备份镜像时，也将它恢复到 C: 盘。在备用服务器 server2 上，发出以下命令来恢复 TEST1 数据库：

RESTORE DB test1 ON C:

在主数据库和备用数据库上设置以下 HADR 配置参数：

HADR_LOCAL_HOST
HADR_LOCAL_SVC
HADR_REMOTE_HOST
HADR_REMOTE_SVC
HADR_REMOTE_INST
HADR_SYNCMODE
LOGINDEXBUILD

在主服务器上，为 HADR 使用端口号 70000。更新 Windows\System32\drivers\etc\services 文件，在其中添加以下一行：

Hadr_port 	70000/tcp

在备用服务器上的 services 文件中添加以下一行：

Hadr_port 	80000/tcp

为 HADR_SYNCMODE 使用默认值，即 NEARSYNC。

您已经有了配置 HADR 参数所需的所有信息。发出以下命令来配置备用服务器上的参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在主数据库服务器上，配置相同的一组参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在备用数据库上使用 START HADR 命令启动 HADR：
START HADR ON DB test1 AS STANDBY
在启动主数据库之前启动备用数据库。如果先启动主数据库，那么，如果没有在 HADR_TIMEOUT 数据库配置参数指定的期限内启动备用数据库，那么主数据库的启动过程就会失败。
在主数据库上启动 HADR，如下面的例子所示：
START HADR ON DB test1 AS PRIMARY
HADR 现在已经在主数据库和备用数据库上启动了。

当第一次启动主服务器时，它等待备用服务器与它联系。如果在指定期限内备用服务器没有与主服务器联系，那么 HADR 将不启动。这个期限可以用 HADR_TIMEOUT 配置参数（见表 1）来配置。这样做的目的是避免两个系统在偶然的情况下与主服务器同时启动。

在 HADR 启动过程中，数据库经历以下状态：local catch-up、remote catch-up pending、remote catch-up 和对等状态。日志被自动从主服务器传送到备用服务器，然后在备用服务器上重演。这是为了确保备用数据库跟上主数据库的变化。

强烈建议在主数据库和备用数据库所在的系统上使用相同的数据库配置参数和数据库管理器配置参数。否则，备用数据库就不会像主数据库一样执行。

一个例外是 LOGFILSIZ 数据库配置参数。这个参数的值被备用服务器所忽略。备用服务器自动创建与主数据库上的日志文件大小相匹配的日志文件。这保证了两个数据库上的日志文件是一致的。

在主数据库与备用数据库之间切换数据库角色，也就是说，备用数据库变成主数据库，主数据库变成备用数据库。
从主数据库故障转移到备用数据库。

   GET SNAPSHOT FOR DATABASE ON test1

下面的命令在备用数据库 TEST1 上开始 HADR 数据库切换角色操作：

   TAKEOVER HADR ON DB test1

故障转移方案不切换数据库角色。在故障转移操作期间，备用数据库接管主数据库角色，但是主数据库不会变成备用数据库。

下面的命令在数据库 TEST1 上开始一个 HADR 故障转移操作：

   TAKEOVER HADR ON DB test1 BY FORCE

表 3 和 4 总结了在备用数据库上发出的 TAKEOVER HADR 命令的行为，以及备用数据库所处的对应的 HADR 状态：

备用数据库的状态	接管行为
对等	主数据库和备用数据库都切换角色
Local catch-up or remote catch-up	错误
Remote catch-up pending	错误

备用数据库的状态	接管行为
对等	备用数据库通知主数据库关闭。备用数据库停止接收来自主数据库的日志，完成它已经收到的日志的重演，然后变成主数据库。备用数据库不用等到主数据库发来通知确认它受到接管通知或者它已经关闭
Local catch-up OR remote catch-up	错误
Remote catch-up pending	备用数据库变成主数据库

您已经看到了如何设置 HADR 环境，以及如何使用数据库角色切换和故障转移方案执行接管。

您学习了如何使用 HADR 使数据库具有高可用性。如果主数据库停机，那么它的备用数据库将接管，并成为新的主数据库。

为了启用自动客户机重路由特性，在主数据库上发出 UPDATE ALTERNATE SERVER 命令。该命令的语法如下：

UPDATE ALTERNATE SERVER FOR DATABASE database-alias
USING HOSTNAME alternate-server-hostname PORT port-number

为了在 server1 上的 TEST1 数据库上启用客户机重路由特性，以便在接管之后已有的和新的客户机连接被重新路由到 server2，在 server1 上发出以下命令：

UPDATE ALTERNATE SERVER FOR DATABASE test1 USING 
HOSTNAME server2.torolab.ibm.com PORT 50000

在这个例子中，50000 是 SVCENAME 端口，而不是 HADR 端口。

备用服务器信息存储在 server1 的数据库目录中。如果发出一个 LIST DB DIRECTORY 命令，那么可以注意到备用服务器信息（主机名和端口号）已经被添加：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

现在让我们来看一个关于如何在启用了自动客户机重路由特性的数据库上执行接管的例子。

在这个例子中，不带 BY FORCE 选项执行一个接管。

首先，建立到 server1 上的 TEST1 数据库的一个远程客户机连接。为此，只需在一个远程 DB2 客户机上发出一条 CONNECT TO DATABASE 命令：

CONNECT TO DB test1 USER user1

为了建立那样的连接，客户机必须已经被配置为连接到 server1。关于如何配置远程客户机连接的信息，请参考本系列中的第一篇教程。

在建立连接之后，主服务器上的备用服务器信息被获取并存储在客户机的数据库目录中：

 Database alias                       = TEST1
 Database name                        = TEST1
 Node name                            = server1
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Remote
 Catalog database partition number    = -1
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

确保该连接已成功建立，并且可以查询 TEST1 数据库。在 server1 上发出一条 LIST APPLICATION 命令，它应该显示数据库 TEST1 上的远程客户机连接：

D:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      8          9.26.94.149.24336.060601000305
                                                         TEST1    1

接着，在 TEST1 数据库上执行接管。在备用服务器 server2 上发出以下命令：

TAKEOVER HADR ON DB test1

让我们看看这次接管完成后远程客户机连接有什么变化。

再次尝试从客户机查询 TEST1 数据库。对 TEST1 数据库的任何查询应该都会返回一个错误消息。例如，从客户机连接发出一条 LIST TABLES 命令：

D:\Programs\IBM\SQLLIB\BIN>db2 list tables
SQL30108N A connection failed but has been re-established. 
The hostname or IP address is "server2" and the service name or port number is "50000". 
Special registers may or may not be re-attempted (Reason code = "1").  
SQLSTATE=08506

这证明客户机重路由特性在起作用。现在您已经连接到新的主服务器，即 server2。

在 server2 上发出一条 LIST APPLICATIONS 命令。您可以看到，远程客户机连接已经被重新路由到那里：

H:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      55         9.26.94.149.29200.060601001803
                                                         TEST1    1

如果再次查询数据库，那么可以从新的主服务器得到一个响应。而且，到原来主服务器的新连接也被重新路由到新的主服务器。

使用 GET SNAPSHOT 命令可以获得数据库的 HADR 状态。在 server2 上发出以下命令，应该可以看到 server2 已经接管了主数据库角色：

db2 "get snapshot for database on test1"

  HADR Status
  Role                   = Primary
  State                  = Peer
  Synchronization mode   = Nearsync
  Connection status      = Connected , 05/31/2006 20:17:24.989618
  Heartbeats missed      = 0
  Local host             = server2.torolab.ibm.com
  Local service          = 80000
  Remote host            = server1.torolab.ibm.com
  Remote service         = 70000
  Remote instance        = db2inst1
  timeout(seconds)       = 120
  Primary log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Standby log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Log gap running average(bytes) = 0

在执行接管操作之后，如果出故障的数据库又可以使用，它不会自动恢复主数据库的角色。

通过以下步骤可以使之重新成为主数据库：

修复原来的主数据库所在的系统。这包括修复有问题的硬件或者重新启动崩溃的操作系统。
重新启动出故障的主数据库，使之成为一个备用数据库。
执行一个接管操作，使之接管主数据库的角色。

当原来的主数据库重新以备用数据库的角色加入 HADR 对之后，执行一个接管操作来切换数据库的角色，使原来的主数据库再次成为主数据库。

为了停止 TEST1 数据库上的 HADR，发出：

STOP HADR ON DB test1

您可以看到，HADR 是实现高可用性解决方案的一个强大的特性。提供了一个名为 HADR 向导的图形化用户界面工具，以帮助您设置和配置 HADR。

如果选择 Set Up，那么就会打开一个如图 15 所示的逐步向导。

如果使用 Control Center 设置 HADR 环境，则会自动启用自动客户机重路由特性。

阅读(23794) | 评论(0) | 转发(0) |

上一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（4）

下一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（6）

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

16024965号-6

高可用性灾难恢复（HADR）

DB2 高可用性灾难恢复（HADR）是一种数据库复制特性，它提供了一种高可用性解决方案。目前，HADR 只用于单分区数据库环境。

为了设置 HADR 环境，要更新一些数据库配置参数。

首先，必须启用主数据库上的归档日志记录。请参阅备份和恢复教程，以了解如何启用归档日志记录。

表 1 列出了与 HADR 相关的数据库配置参数的描述。本教程后面将给出一个关于如何更新这些参数的例子。

与 HADR 相关的数据库配置参数	描述
HADR_LOCAL_HOST	指定 HADR TCPIP 通信的本地主机。主机名和 IP 地址都可以使用
HADR_LOCAL_SVC	指定 TCPIP 服务名和端口号，HADR 进程将在本地主机上接受该服务或端口的连接。这个端口不能与 HADR 实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_HOST	指定远程 HADR 节点的 TCPIP 主机名或 IP 地址
HADR_REMOTE_SVC	指定 TCPIP 服务名或端口号，HADR 进程将在远程节点上接受该服务或端口的连接。这个端口不能与远程实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_INST	指定远程服务器的实例名。DB2 Control Center 之类的管理工具将使用这个参数与远程服务器联系
HADR_TIMEOUT	HADR 进程在认为一次通信尝试失败之前所等待的时间（以秒为单位）。默认值为 120 秒
HADR_SYNCMODE	指定同步模式。它决定当系统处于对等状态时，主日志写与备用数据库如何同步。有效值有 SYNC、NEARSYNC 和 ASYNC。默认值为 NEARSYNC。（本节后面将讨论对等状态）。
HADR_DB_ROLE	指定一个数据库当前的角色。有效值有 STANDARD、PRIMARY 和 STANDBY。STANDARD 意味着数据库没有启用 HADR。

当备用数据库第一次启动时，它进入 local catch-up 状态。本地日志路径中的日志文件（如果有的话）将被读取，并应用到备用数据库。

当到达本地日志文件的最后时，备用数据库进入 remote catch-up 状态。它重演主数据库的归档日志和活动日志，直到备用数据库应用了最近的活动日志。

当主系统上的所有日志文件都已经被重演时，主数据库和备用数据库就进入对等（peer）状态。

在同步模式中，日志写只有在以下情况下才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库的日志文件中。

主数据库与备用数据库中的日志记录几乎（或近似）是同步的，因为只有在以下情况下，日志写才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库上的主存中。

在这种模式下，主数据库不等待收到备用数据库的通知。只有在以下情况下，日志写才被认为是成功的：

日志记录已经被写到主数据库上的日志文件中。
日志记录已经被传送到备用数据库；不需要通知。

HADR 是通过以下三个简单的命令来管理的：

START HADR
STOP HADR
TAKENOVER HADR

这些命令的语法如下：

START HADR ON DATABASE database-alias
[USER userid] [USING password] 
AS PRIMARY | STANDBY [BY FORCE]

STOP HADR ON DATABASE database-alias 
[USER userid] [USING password] 

TAKEOVER HADR ON DATABASE database-alias
[USER userid] [USING password] 
[BY FORCE]

您已经学习了 HADR 的概念，现在可以学习如何设置 HADR 环境。

使用另一个数据库服务器 server2.torolab.ibm.com 作为备用服务器。TEST1 当前不在备用服务器上。

服务名	实例名	SVCENAME 或端口号	数据库名
server1.torolab.ibm.com	DB2INST1	50000	TEST1
server2.torolab.ibm.com	DB2INST1	50000	--

第一次初始化 HADR 时，执行图 13 所示的五个步骤：

确定主服务器和备用服务器。决定主机名、主机 IP 地址和每个 HADR 数据库的服务名或端口号。
您已经确定了主服务器和备用服务器。主服务器是 server1。备用服务器是 server2。

确保这两个服务器是通过 TCPIP 相互通信的。尝试用主机名在这两个服务器上相互 ping 对方。应确保输出没有错误。如果主机名不能使用，那么尝试使用它们的 TCPIP 地址。选用两者中最好用的一种用于 HADR 配置。

通过克隆主数据库创建备用数据库。

有两种方案可用于克隆主数据库：

一种方案是为主数据库做一个备份，并在备用数据库上恢复这个数据库备份。这种方案使用标准备份和恢复方法。
克隆主数据库的另一种方案是使用分割镜像。为主数据库做一个分割镜像，然后在备用服务器上初始化该分割镜像。当初始化分割镜像时，必须在 db2inidb 命令中使用 standby 选项，以便使用 mirror 和 snapshot 选项。

在这个例子种，使用备份/恢复方法来创建备用数据库。

首先为 server1 上的主数据库 TEST1 做一个备份：

BACKUP DB test1

接着，通过 ftp 将备份镜像传送到备用服务器，并恢复该备份镜像。

将备份镜像恢复到与主服务器上相同的位置。在主服务器上，发出 LIST DB DIRECTORY 命令将显示：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            =
 Alternate server port number         =

数据库位于主服务器上的 C: 盘上。当在备用服务器上恢复备份镜像时，也将它恢复到 C: 盘。在备用服务器 server2 上，发出以下命令来恢复 TEST1 数据库：

RESTORE DB test1 ON C:

在主数据库和备用数据库上设置以下 HADR 配置参数：

HADR_LOCAL_HOST
HADR_LOCAL_SVC
HADR_REMOTE_HOST
HADR_REMOTE_SVC
HADR_REMOTE_INST
HADR_SYNCMODE
LOGINDEXBUILD

在主服务器上，为 HADR 使用端口号 70000。更新 Windows\System32\drivers\etc\services 文件，在其中添加以下一行：

Hadr_port 	70000/tcp

在备用服务器上的 services 文件中添加以下一行：

Hadr_port 	80000/tcp

为 HADR_SYNCMODE 使用默认值，即 NEARSYNC。

您已经有了配置 HADR 参数所需的所有信息。发出以下命令来配置备用服务器上的参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在主数据库服务器上，配置相同的一组参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在备用数据库上使用 START HADR 命令启动 HADR：
START HADR ON DB test1 AS STANDBY
在启动主数据库之前启动备用数据库。如果先启动主数据库，那么，如果没有在 HADR_TIMEOUT 数据库配置参数指定的期限内启动备用数据库，那么主数据库的启动过程就会失败。
在主数据库上启动 HADR，如下面的例子所示：
START HADR ON DB test1 AS PRIMARY
HADR 现在已经在主数据库和备用数据库上启动了。

当第一次启动主服务器时，它等待备用服务器与它联系。如果在指定期限内备用服务器没有与主服务器联系，那么 HADR 将不启动。这个期限可以用 HADR_TIMEOUT 配置参数（见表 1）来配置。这样做的目的是避免两个系统在偶然的情况下与主服务器同时启动。

在 HADR 启动过程中，数据库经历以下状态：local catch-up、remote catch-up pending、remote catch-up 和对等状态。日志被自动从主服务器传送到备用服务器，然后在备用服务器上重演。这是为了确保备用数据库跟上主数据库的变化。

强烈建议在主数据库和备用数据库所在的系统上使用相同的数据库配置参数和数据库管理器配置参数。否则，备用数据库就不会像主数据库一样执行。

一个例外是 LOGFILSIZ 数据库配置参数。这个参数的值被备用服务器所忽略。备用服务器自动创建与主数据库上的日志文件大小相匹配的日志文件。这保证了两个数据库上的日志文件是一致的。

在主数据库与备用数据库之间切换数据库角色，也就是说，备用数据库变成主数据库，主数据库变成备用数据库。
从主数据库故障转移到备用数据库。

   GET SNAPSHOT FOR DATABASE ON test1

下面的命令在备用数据库 TEST1 上开始 HADR 数据库切换角色操作：

   TAKEOVER HADR ON DB test1

故障转移方案不切换数据库角色。在故障转移操作期间，备用数据库接管主数据库角色，但是主数据库不会变成备用数据库。

下面的命令在数据库 TEST1 上开始一个 HADR 故障转移操作：

   TAKEOVER HADR ON DB test1 BY FORCE

表 3 和 4 总结了在备用数据库上发出的 TAKEOVER HADR 命令的行为，以及备用数据库所处的对应的 HADR 状态：

备用数据库的状态	接管行为
对等	主数据库和备用数据库都切换角色
Local catch-up or remote catch-up	错误
Remote catch-up pending	错误

备用数据库的状态	接管行为
对等	备用数据库通知主数据库关闭。备用数据库停止接收来自主数据库的日志，完成它已经收到的日志的重演，然后变成主数据库。备用数据库不用等到主数据库发来通知确认它受到接管通知或者它已经关闭
Local catch-up OR remote catch-up	错误
Remote catch-up pending	备用数据库变成主数据库

您已经看到了如何设置 HADR 环境，以及如何使用数据库角色切换和故障转移方案执行接管。

您学习了如何使用 HADR 使数据库具有高可用性。如果主数据库停机，那么它的备用数据库将接管，并成为新的主数据库。

为了启用自动客户机重路由特性，在主数据库上发出 UPDATE ALTERNATE SERVER 命令。该命令的语法如下：

UPDATE ALTERNATE SERVER FOR DATABASE database-alias
USING HOSTNAME alternate-server-hostname PORT port-number

为了在 server1 上的 TEST1 数据库上启用客户机重路由特性，以便在接管之后已有的和新的客户机连接被重新路由到 server2，在 server1 上发出以下命令：

UPDATE ALTERNATE SERVER FOR DATABASE test1 USING 
HOSTNAME server2.torolab.ibm.com PORT 50000

在这个例子中，50000 是 SVCENAME 端口，而不是 HADR 端口。

备用服务器信息存储在 server1 的数据库目录中。如果发出一个 LIST DB DIRECTORY 命令，那么可以注意到备用服务器信息（主机名和端口号）已经被添加：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

现在让我们来看一个关于如何在启用了自动客户机重路由特性的数据库上执行接管的例子。

在这个例子中，不带 BY FORCE 选项执行一个接管。

首先，建立到 server1 上的 TEST1 数据库的一个远程客户机连接。为此，只需在一个远程 DB2 客户机上发出一条 CONNECT TO DATABASE 命令：

CONNECT TO DB test1 USER user1

为了建立那样的连接，客户机必须已经被配置为连接到 server1。关于如何配置远程客户机连接的信息，请参考本系列中的第一篇教程。

在建立连接之后，主服务器上的备用服务器信息被获取并存储在客户机的数据库目录中：

 Database alias                       = TEST1
 Database name                        = TEST1
 Node name                            = server1
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Remote
 Catalog database partition number    = -1
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

确保该连接已成功建立，并且可以查询 TEST1 数据库。在 server1 上发出一条 LIST APPLICATION 命令，它应该显示数据库 TEST1 上的远程客户机连接：

D:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      8          9.26.94.149.24336.060601000305
                                                         TEST1    1

接着，在 TEST1 数据库上执行接管。在备用服务器 server2 上发出以下命令：

TAKEOVER HADR ON DB test1

让我们看看这次接管完成后远程客户机连接有什么变化。

再次尝试从客户机查询 TEST1 数据库。对 TEST1 数据库的任何查询应该都会返回一个错误消息。例如，从客户机连接发出一条 LIST TABLES 命令：

D:\Programs\IBM\SQLLIB\BIN>db2 list tables
SQL30108N A connection failed but has been re-established. 
The hostname or IP address is "server2" and the service name or port number is "50000". 
Special registers may or may not be re-attempted (Reason code = "1").  
SQLSTATE=08506

这证明客户机重路由特性在起作用。现在您已经连接到新的主服务器，即 server2。

在 server2 上发出一条 LIST APPLICATIONS 命令。您可以看到，远程客户机连接已经被重新路由到那里：

H:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      55         9.26.94.149.29200.060601001803
                                                         TEST1    1

如果再次查询数据库，那么可以从新的主服务器得到一个响应。而且，到原来主服务器的新连接也被重新路由到新的主服务器。

使用 GET SNAPSHOT 命令可以获得数据库的 HADR 状态。在 server2 上发出以下命令，应该可以看到 server2 已经接管了主数据库角色：

db2 "get snapshot for database on test1"

  HADR Status
  Role                   = Primary
  State                  = Peer
  Synchronization mode   = Nearsync
  Connection status      = Connected , 05/31/2006 20:17:24.989618
  Heartbeats missed      = 0
  Local host             = server2.torolab.ibm.com
  Local service          = 80000
  Remote host            = server1.torolab.ibm.com
  Remote service         = 70000
  Remote instance        = db2inst1
  timeout(seconds)       = 120
  Primary log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Standby log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Log gap running average(bytes) = 0

在执行接管操作之后，如果出故障的数据库又可以使用，它不会自动恢复主数据库的角色。

通过以下步骤可以使之重新成为主数据库：

修复原来的主数据库所在的系统。这包括修复有问题的硬件或者重新启动崩溃的操作系统。
重新启动出故障的主数据库，使之成为一个备用数据库。
执行一个接管操作，使之接管主数据库的角色。

当原来的主数据库重新以备用数据库的角色加入 HADR 对之后，执行一个接管操作来切换数据库的角色，使原来的主数据库再次成为主数据库。

为了停止 TEST1 数据库上的 HADR，发出：

STOP HADR ON DB test1

您可以看到，HADR 是实现高可用性解决方案的一个强大的特性。提供了一个名为 HADR 向导的图形化用户界面工具，以帮助您设置和配置 HADR。

如果选择 Set Up，那么就会打开一个如图 15 所示的逐步向导。

如果使用 Control Center 设置 HADR 环境，则会自动启用自动客户机重路由特性。

阅读(23793) | 评论(0) | 转发(0) |

上一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（4）

下一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（6）

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

16024965号-6

高可用性灾难恢复（HADR）

DB2 高可用性灾难恢复（HADR）是一种数据库复制特性，它提供了一种高可用性解决方案。目前，HADR 只用于单分区数据库环境。

为了设置 HADR 环境，要更新一些数据库配置参数。

首先，必须启用主数据库上的归档日志记录。请参阅备份和恢复教程，以了解如何启用归档日志记录。

表 1 列出了与 HADR 相关的数据库配置参数的描述。本教程后面将给出一个关于如何更新这些参数的例子。

与 HADR 相关的数据库配置参数	描述
HADR_LOCAL_HOST	指定 HADR TCPIP 通信的本地主机。主机名和 IP 地址都可以使用
HADR_LOCAL_SVC	指定 TCPIP 服务名和端口号，HADR 进程将在本地主机上接受该服务或端口的连接。这个端口不能与 HADR 实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_HOST	指定远程 HADR 节点的 TCPIP 主机名或 IP 地址
HADR_REMOTE_SVC	指定 TCPIP 服务名或端口号，HADR 进程将在远程节点上接受该服务或端口的连接。这个端口不能与远程实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_INST	指定远程服务器的实例名。DB2 Control Center 之类的管理工具将使用这个参数与远程服务器联系
HADR_TIMEOUT	HADR 进程在认为一次通信尝试失败之前所等待的时间（以秒为单位）。默认值为 120 秒
HADR_SYNCMODE	指定同步模式。它决定当系统处于对等状态时，主日志写与备用数据库如何同步。有效值有 SYNC、NEARSYNC 和 ASYNC。默认值为 NEARSYNC。（本节后面将讨论对等状态）。
HADR_DB_ROLE	指定一个数据库当前的角色。有效值有 STANDARD、PRIMARY 和 STANDBY。STANDARD 意味着数据库没有启用 HADR。

当备用数据库第一次启动时，它进入 local catch-up 状态。本地日志路径中的日志文件（如果有的话）将被读取，并应用到备用数据库。

当到达本地日志文件的最后时，备用数据库进入 remote catch-up 状态。它重演主数据库的归档日志和活动日志，直到备用数据库应用了最近的活动日志。

当主系统上的所有日志文件都已经被重演时，主数据库和备用数据库就进入对等（peer）状态。

在同步模式中，日志写只有在以下情况下才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库的日志文件中。

主数据库与备用数据库中的日志记录几乎（或近似）是同步的，因为只有在以下情况下，日志写才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库上的主存中。

在这种模式下，主数据库不等待收到备用数据库的通知。只有在以下情况下，日志写才被认为是成功的：

日志记录已经被写到主数据库上的日志文件中。
日志记录已经被传送到备用数据库；不需要通知。

HADR 是通过以下三个简单的命令来管理的：

START HADR
STOP HADR
TAKENOVER HADR

这些命令的语法如下：

START HADR ON DATABASE database-alias
[USER userid] [USING password] 
AS PRIMARY | STANDBY [BY FORCE]

STOP HADR ON DATABASE database-alias 
[USER userid] [USING password] 

TAKEOVER HADR ON DATABASE database-alias
[USER userid] [USING password] 
[BY FORCE]

您已经学习了 HADR 的概念，现在可以学习如何设置 HADR 环境。

使用另一个数据库服务器 server2.torolab.ibm.com 作为备用服务器。TEST1 当前不在备用服务器上。

服务名	实例名	SVCENAME 或端口号	数据库名
server1.torolab.ibm.com	DB2INST1	50000	TEST1
server2.torolab.ibm.com	DB2INST1	50000	--

第一次初始化 HADR 时，执行图 13 所示的五个步骤：

确定主服务器和备用服务器。决定主机名、主机 IP 地址和每个 HADR 数据库的服务名或端口号。
您已经确定了主服务器和备用服务器。主服务器是 server1。备用服务器是 server2。

确保这两个服务器是通过 TCPIP 相互通信的。尝试用主机名在这两个服务器上相互 ping 对方。应确保输出没有错误。如果主机名不能使用，那么尝试使用它们的 TCPIP 地址。选用两者中最好用的一种用于 HADR 配置。

通过克隆主数据库创建备用数据库。

有两种方案可用于克隆主数据库：

一种方案是为主数据库做一个备份，并在备用数据库上恢复这个数据库备份。这种方案使用标准备份和恢复方法。
克隆主数据库的另一种方案是使用分割镜像。为主数据库做一个分割镜像，然后在备用服务器上初始化该分割镜像。当初始化分割镜像时，必须在 db2inidb 命令中使用 standby 选项，以便使用 mirror 和 snapshot 选项。

在这个例子种，使用备份/恢复方法来创建备用数据库。

首先为 server1 上的主数据库 TEST1 做一个备份：

BACKUP DB test1

接着，通过 ftp 将备份镜像传送到备用服务器，并恢复该备份镜像。

将备份镜像恢复到与主服务器上相同的位置。在主服务器上，发出 LIST DB DIRECTORY 命令将显示：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            =
 Alternate server port number         =

数据库位于主服务器上的 C: 盘上。当在备用服务器上恢复备份镜像时，也将它恢复到 C: 盘。在备用服务器 server2 上，发出以下命令来恢复 TEST1 数据库：

RESTORE DB test1 ON C:

在主数据库和备用数据库上设置以下 HADR 配置参数：

HADR_LOCAL_HOST
HADR_LOCAL_SVC
HADR_REMOTE_HOST
HADR_REMOTE_SVC
HADR_REMOTE_INST
HADR_SYNCMODE
LOGINDEXBUILD

在主服务器上，为 HADR 使用端口号 70000。更新 Windows\System32\drivers\etc\services 文件，在其中添加以下一行：

Hadr_port 	70000/tcp

在备用服务器上的 services 文件中添加以下一行：

Hadr_port 	80000/tcp

为 HADR_SYNCMODE 使用默认值，即 NEARSYNC。

您已经有了配置 HADR 参数所需的所有信息。发出以下命令来配置备用服务器上的参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在主数据库服务器上，配置相同的一组参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在备用数据库上使用 START HADR 命令启动 HADR：
START HADR ON DB test1 AS STANDBY
在启动主数据库之前启动备用数据库。如果先启动主数据库，那么，如果没有在 HADR_TIMEOUT 数据库配置参数指定的期限内启动备用数据库，那么主数据库的启动过程就会失败。
在主数据库上启动 HADR，如下面的例子所示：
START HADR ON DB test1 AS PRIMARY
HADR 现在已经在主数据库和备用数据库上启动了。

当第一次启动主服务器时，它等待备用服务器与它联系。如果在指定期限内备用服务器没有与主服务器联系，那么 HADR 将不启动。这个期限可以用 HADR_TIMEOUT 配置参数（见表 1）来配置。这样做的目的是避免两个系统在偶然的情况下与主服务器同时启动。

在 HADR 启动过程中，数据库经历以下状态：local catch-up、remote catch-up pending、remote catch-up 和对等状态。日志被自动从主服务器传送到备用服务器，然后在备用服务器上重演。这是为了确保备用数据库跟上主数据库的变化。

强烈建议在主数据库和备用数据库所在的系统上使用相同的数据库配置参数和数据库管理器配置参数。否则，备用数据库就不会像主数据库一样执行。

一个例外是 LOGFILSIZ 数据库配置参数。这个参数的值被备用服务器所忽略。备用服务器自动创建与主数据库上的日志文件大小相匹配的日志文件。这保证了两个数据库上的日志文件是一致的。

在主数据库与备用数据库之间切换数据库角色，也就是说，备用数据库变成主数据库，主数据库变成备用数据库。
从主数据库故障转移到备用数据库。

   GET SNAPSHOT FOR DATABASE ON test1

下面的命令在备用数据库 TEST1 上开始 HADR 数据库切换角色操作：

   TAKEOVER HADR ON DB test1

故障转移方案不切换数据库角色。在故障转移操作期间，备用数据库接管主数据库角色，但是主数据库不会变成备用数据库。

下面的命令在数据库 TEST1 上开始一个 HADR 故障转移操作：

   TAKEOVER HADR ON DB test1 BY FORCE

表 3 和 4 总结了在备用数据库上发出的 TAKEOVER HADR 命令的行为，以及备用数据库所处的对应的 HADR 状态：

备用数据库的状态	接管行为
对等	主数据库和备用数据库都切换角色
Local catch-up or remote catch-up	错误
Remote catch-up pending	错误

备用数据库的状态	接管行为
对等	备用数据库通知主数据库关闭。备用数据库停止接收来自主数据库的日志，完成它已经收到的日志的重演，然后变成主数据库。备用数据库不用等到主数据库发来通知确认它受到接管通知或者它已经关闭
Local catch-up OR remote catch-up	错误
Remote catch-up pending	备用数据库变成主数据库

您已经看到了如何设置 HADR 环境，以及如何使用数据库角色切换和故障转移方案执行接管。

您学习了如何使用 HADR 使数据库具有高可用性。如果主数据库停机，那么它的备用数据库将接管，并成为新的主数据库。

为了启用自动客户机重路由特性，在主数据库上发出 UPDATE ALTERNATE SERVER 命令。该命令的语法如下：

UPDATE ALTERNATE SERVER FOR DATABASE database-alias
USING HOSTNAME alternate-server-hostname PORT port-number

为了在 server1 上的 TEST1 数据库上启用客户机重路由特性，以便在接管之后已有的和新的客户机连接被重新路由到 server2，在 server1 上发出以下命令：

UPDATE ALTERNATE SERVER FOR DATABASE test1 USING 
HOSTNAME server2.torolab.ibm.com PORT 50000

在这个例子中，50000 是 SVCENAME 端口，而不是 HADR 端口。

备用服务器信息存储在 server1 的数据库目录中。如果发出一个 LIST DB DIRECTORY 命令，那么可以注意到备用服务器信息（主机名和端口号）已经被添加：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

现在让我们来看一个关于如何在启用了自动客户机重路由特性的数据库上执行接管的例子。

在这个例子中，不带 BY FORCE 选项执行一个接管。

首先，建立到 server1 上的 TEST1 数据库的一个远程客户机连接。为此，只需在一个远程 DB2 客户机上发出一条 CONNECT TO DATABASE 命令：

CONNECT TO DB test1 USER user1

为了建立那样的连接，客户机必须已经被配置为连接到 server1。关于如何配置远程客户机连接的信息，请参考本系列中的第一篇教程。

在建立连接之后，主服务器上的备用服务器信息被获取并存储在客户机的数据库目录中：

 Database alias                       = TEST1
 Database name                        = TEST1
 Node name                            = server1
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Remote
 Catalog database partition number    = -1
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

确保该连接已成功建立，并且可以查询 TEST1 数据库。在 server1 上发出一条 LIST APPLICATION 命令，它应该显示数据库 TEST1 上的远程客户机连接：

D:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      8          9.26.94.149.24336.060601000305
                                                         TEST1    1

接着，在 TEST1 数据库上执行接管。在备用服务器 server2 上发出以下命令：

TAKEOVER HADR ON DB test1

让我们看看这次接管完成后远程客户机连接有什么变化。

再次尝试从客户机查询 TEST1 数据库。对 TEST1 数据库的任何查询应该都会返回一个错误消息。例如，从客户机连接发出一条 LIST TABLES 命令：

D:\Programs\IBM\SQLLIB\BIN>db2 list tables
SQL30108N A connection failed but has been re-established. 
The hostname or IP address is "server2" and the service name or port number is "50000". 
Special registers may or may not be re-attempted (Reason code = "1").  
SQLSTATE=08506

这证明客户机重路由特性在起作用。现在您已经连接到新的主服务器，即 server2。

在 server2 上发出一条 LIST APPLICATIONS 命令。您可以看到，远程客户机连接已经被重新路由到那里：

H:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      55         9.26.94.149.29200.060601001803
                                                         TEST1    1

如果再次查询数据库，那么可以从新的主服务器得到一个响应。而且，到原来主服务器的新连接也被重新路由到新的主服务器。

使用 GET SNAPSHOT 命令可以获得数据库的 HADR 状态。在 server2 上发出以下命令，应该可以看到 server2 已经接管了主数据库角色：

db2 "get snapshot for database on test1"

  HADR Status
  Role                   = Primary
  State                  = Peer
  Synchronization mode   = Nearsync
  Connection status      = Connected , 05/31/2006 20:17:24.989618
  Heartbeats missed      = 0
  Local host             = server2.torolab.ibm.com
  Local service          = 80000
  Remote host            = server1.torolab.ibm.com
  Remote service         = 70000
  Remote instance        = db2inst1
  timeout(seconds)       = 120
  Primary log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Standby log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Log gap running average(bytes) = 0

在执行接管操作之后，如果出故障的数据库又可以使用，它不会自动恢复主数据库的角色。

通过以下步骤可以使之重新成为主数据库：

修复原来的主数据库所在的系统。这包括修复有问题的硬件或者重新启动崩溃的操作系统。
重新启动出故障的主数据库，使之成为一个备用数据库。
执行一个接管操作，使之接管主数据库的角色。

当原来的主数据库重新以备用数据库的角色加入 HADR 对之后，执行一个接管操作来切换数据库的角色，使原来的主数据库再次成为主数据库。

为了停止 TEST1 数据库上的 HADR，发出：

STOP HADR ON DB test1

您可以看到，HADR 是实现高可用性解决方案的一个强大的特性。提供了一个名为 HADR 向导的图形化用户界面工具，以帮助您设置和配置 HADR。

如果选择 Set Up，那么就会打开一个如图 15 所示的逐步向导。

如果使用 Control Center 设置 HADR 环境，则会自动启用自动客户机重路由特性。

阅读(23792) | 评论(0) | 转发(0) |

上一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（4）

下一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（6）

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

16024965号-6

高可用性灾难恢复（HADR）

DB2 高可用性灾难恢复（HADR）是一种数据库复制特性，它提供了一种高可用性解决方案。目前，HADR 只用于单分区数据库环境。

为了设置 HADR 环境，要更新一些数据库配置参数。

首先，必须启用主数据库上的归档日志记录。请参阅备份和恢复教程，以了解如何启用归档日志记录。

表 1 列出了与 HADR 相关的数据库配置参数的描述。本教程后面将给出一个关于如何更新这些参数的例子。

与 HADR 相关的数据库配置参数	描述
HADR_LOCAL_HOST	指定 HADR TCPIP 通信的本地主机。主机名和 IP 地址都可以使用
HADR_LOCAL_SVC	指定 TCPIP 服务名和端口号，HADR 进程将在本地主机上接受该服务或端口的连接。这个端口不能与 HADR 实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_HOST	指定远程 HADR 节点的 TCPIP 主机名或 IP 地址
HADR_REMOTE_SVC	指定 TCPIP 服务名或端口号，HADR 进程将在远程节点上接受该服务或端口的连接。这个端口不能与远程实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_INST	指定远程服务器的实例名。DB2 Control Center 之类的管理工具将使用这个参数与远程服务器联系
HADR_TIMEOUT	HADR 进程在认为一次通信尝试失败之前所等待的时间（以秒为单位）。默认值为 120 秒
HADR_SYNCMODE	指定同步模式。它决定当系统处于对等状态时，主日志写与备用数据库如何同步。有效值有 SYNC、NEARSYNC 和 ASYNC。默认值为 NEARSYNC。（本节后面将讨论对等状态）。
HADR_DB_ROLE	指定一个数据库当前的角色。有效值有 STANDARD、PRIMARY 和 STANDBY。STANDARD 意味着数据库没有启用 HADR。

当备用数据库第一次启动时，它进入 local catch-up 状态。本地日志路径中的日志文件（如果有的话）将被读取，并应用到备用数据库。

当到达本地日志文件的最后时，备用数据库进入 remote catch-up 状态。它重演主数据库的归档日志和活动日志，直到备用数据库应用了最近的活动日志。

当主系统上的所有日志文件都已经被重演时，主数据库和备用数据库就进入对等（peer）状态。

在同步模式中，日志写只有在以下情况下才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库的日志文件中。

主数据库与备用数据库中的日志记录几乎（或近似）是同步的，因为只有在以下情况下，日志写才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库上的主存中。

在这种模式下，主数据库不等待收到备用数据库的通知。只有在以下情况下，日志写才被认为是成功的：

日志记录已经被写到主数据库上的日志文件中。
日志记录已经被传送到备用数据库；不需要通知。

HADR 是通过以下三个简单的命令来管理的：

START HADR
STOP HADR
TAKENOVER HADR

这些命令的语法如下：

START HADR ON DATABASE database-alias
[USER userid] [USING password] 
AS PRIMARY | STANDBY [BY FORCE]

STOP HADR ON DATABASE database-alias 
[USER userid] [USING password] 

TAKEOVER HADR ON DATABASE database-alias
[USER userid] [USING password] 
[BY FORCE]

您已经学习了 HADR 的概念，现在可以学习如何设置 HADR 环境。

使用另一个数据库服务器 server2.torolab.ibm.com 作为备用服务器。TEST1 当前不在备用服务器上。

服务名	实例名	SVCENAME 或端口号	数据库名
server1.torolab.ibm.com	DB2INST1	50000	TEST1
server2.torolab.ibm.com	DB2INST1	50000	--

第一次初始化 HADR 时，执行图 13 所示的五个步骤：

确定主服务器和备用服务器。决定主机名、主机 IP 地址和每个 HADR 数据库的服务名或端口号。
您已经确定了主服务器和备用服务器。主服务器是 server1。备用服务器是 server2。

确保这两个服务器是通过 TCPIP 相互通信的。尝试用主机名在这两个服务器上相互 ping 对方。应确保输出没有错误。如果主机名不能使用，那么尝试使用它们的 TCPIP 地址。选用两者中最好用的一种用于 HADR 配置。

通过克隆主数据库创建备用数据库。

有两种方案可用于克隆主数据库：

一种方案是为主数据库做一个备份，并在备用数据库上恢复这个数据库备份。这种方案使用标准备份和恢复方法。
克隆主数据库的另一种方案是使用分割镜像。为主数据库做一个分割镜像，然后在备用服务器上初始化该分割镜像。当初始化分割镜像时，必须在 db2inidb 命令中使用 standby 选项，以便使用 mirror 和 snapshot 选项。

在这个例子种，使用备份/恢复方法来创建备用数据库。

首先为 server1 上的主数据库 TEST1 做一个备份：

BACKUP DB test1

接着，通过 ftp 将备份镜像传送到备用服务器，并恢复该备份镜像。

将备份镜像恢复到与主服务器上相同的位置。在主服务器上，发出 LIST DB DIRECTORY 命令将显示：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            =
 Alternate server port number         =

数据库位于主服务器上的 C: 盘上。当在备用服务器上恢复备份镜像时，也将它恢复到 C: 盘。在备用服务器 server2 上，发出以下命令来恢复 TEST1 数据库：

RESTORE DB test1 ON C:

在主数据库和备用数据库上设置以下 HADR 配置参数：

HADR_LOCAL_HOST
HADR_LOCAL_SVC
HADR_REMOTE_HOST
HADR_REMOTE_SVC
HADR_REMOTE_INST
HADR_SYNCMODE
LOGINDEXBUILD

在主服务器上，为 HADR 使用端口号 70000。更新 Windows\System32\drivers\etc\services 文件，在其中添加以下一行：

Hadr_port 	70000/tcp

在备用服务器上的 services 文件中添加以下一行：

Hadr_port 	80000/tcp

为 HADR_SYNCMODE 使用默认值，即 NEARSYNC。

您已经有了配置 HADR 参数所需的所有信息。发出以下命令来配置备用服务器上的参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在主数据库服务器上，配置相同的一组参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在备用数据库上使用 START HADR 命令启动 HADR：
START HADR ON DB test1 AS STANDBY
在启动主数据库之前启动备用数据库。如果先启动主数据库，那么，如果没有在 HADR_TIMEOUT 数据库配置参数指定的期限内启动备用数据库，那么主数据库的启动过程就会失败。
在主数据库上启动 HADR，如下面的例子所示：
START HADR ON DB test1 AS PRIMARY
HADR 现在已经在主数据库和备用数据库上启动了。

当第一次启动主服务器时，它等待备用服务器与它联系。如果在指定期限内备用服务器没有与主服务器联系，那么 HADR 将不启动。这个期限可以用 HADR_TIMEOUT 配置参数（见表 1）来配置。这样做的目的是避免两个系统在偶然的情况下与主服务器同时启动。

在 HADR 启动过程中，数据库经历以下状态：local catch-up、remote catch-up pending、remote catch-up 和对等状态。日志被自动从主服务器传送到备用服务器，然后在备用服务器上重演。这是为了确保备用数据库跟上主数据库的变化。

强烈建议在主数据库和备用数据库所在的系统上使用相同的数据库配置参数和数据库管理器配置参数。否则，备用数据库就不会像主数据库一样执行。

一个例外是 LOGFILSIZ 数据库配置参数。这个参数的值被备用服务器所忽略。备用服务器自动创建与主数据库上的日志文件大小相匹配的日志文件。这保证了两个数据库上的日志文件是一致的。

在主数据库与备用数据库之间切换数据库角色，也就是说，备用数据库变成主数据库，主数据库变成备用数据库。
从主数据库故障转移到备用数据库。

   GET SNAPSHOT FOR DATABASE ON test1

下面的命令在备用数据库 TEST1 上开始 HADR 数据库切换角色操作：

   TAKEOVER HADR ON DB test1

故障转移方案不切换数据库角色。在故障转移操作期间，备用数据库接管主数据库角色，但是主数据库不会变成备用数据库。

下面的命令在数据库 TEST1 上开始一个 HADR 故障转移操作：

   TAKEOVER HADR ON DB test1 BY FORCE

表 3 和 4 总结了在备用数据库上发出的 TAKEOVER HADR 命令的行为，以及备用数据库所处的对应的 HADR 状态：

备用数据库的状态	接管行为
对等	主数据库和备用数据库都切换角色
Local catch-up or remote catch-up	错误
Remote catch-up pending	错误

备用数据库的状态	接管行为
对等	备用数据库通知主数据库关闭。备用数据库停止接收来自主数据库的日志，完成它已经收到的日志的重演，然后变成主数据库。备用数据库不用等到主数据库发来通知确认它受到接管通知或者它已经关闭
Local catch-up OR remote catch-up	错误
Remote catch-up pending	备用数据库变成主数据库

您已经看到了如何设置 HADR 环境，以及如何使用数据库角色切换和故障转移方案执行接管。

您学习了如何使用 HADR 使数据库具有高可用性。如果主数据库停机，那么它的备用数据库将接管，并成为新的主数据库。

为了启用自动客户机重路由特性，在主数据库上发出 UPDATE ALTERNATE SERVER 命令。该命令的语法如下：

UPDATE ALTERNATE SERVER FOR DATABASE database-alias
USING HOSTNAME alternate-server-hostname PORT port-number

为了在 server1 上的 TEST1 数据库上启用客户机重路由特性，以便在接管之后已有的和新的客户机连接被重新路由到 server2，在 server1 上发出以下命令：

UPDATE ALTERNATE SERVER FOR DATABASE test1 USING 
HOSTNAME server2.torolab.ibm.com PORT 50000

在这个例子中，50000 是 SVCENAME 端口，而不是 HADR 端口。

备用服务器信息存储在 server1 的数据库目录中。如果发出一个 LIST DB DIRECTORY 命令，那么可以注意到备用服务器信息（主机名和端口号）已经被添加：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

现在让我们来看一个关于如何在启用了自动客户机重路由特性的数据库上执行接管的例子。

在这个例子中，不带 BY FORCE 选项执行一个接管。

首先，建立到 server1 上的 TEST1 数据库的一个远程客户机连接。为此，只需在一个远程 DB2 客户机上发出一条 CONNECT TO DATABASE 命令：

CONNECT TO DB test1 USER user1

为了建立那样的连接，客户机必须已经被配置为连接到 server1。关于如何配置远程客户机连接的信息，请参考本系列中的第一篇教程。

在建立连接之后，主服务器上的备用服务器信息被获取并存储在客户机的数据库目录中：

 Database alias                       = TEST1
 Database name                        = TEST1
 Node name                            = server1
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Remote
 Catalog database partition number    = -1
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

确保该连接已成功建立，并且可以查询 TEST1 数据库。在 server1 上发出一条 LIST APPLICATION 命令，它应该显示数据库 TEST1 上的远程客户机连接：

D:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      8          9.26.94.149.24336.060601000305
                                                         TEST1    1

接着，在 TEST1 数据库上执行接管。在备用服务器 server2 上发出以下命令：

TAKEOVER HADR ON DB test1

让我们看看这次接管完成后远程客户机连接有什么变化。

再次尝试从客户机查询 TEST1 数据库。对 TEST1 数据库的任何查询应该都会返回一个错误消息。例如，从客户机连接发出一条 LIST TABLES 命令：

D:\Programs\IBM\SQLLIB\BIN>db2 list tables
SQL30108N A connection failed but has been re-established. 
The hostname or IP address is "server2" and the service name or port number is "50000". 
Special registers may or may not be re-attempted (Reason code = "1").  
SQLSTATE=08506

这证明客户机重路由特性在起作用。现在您已经连接到新的主服务器，即 server2。

在 server2 上发出一条 LIST APPLICATIONS 命令。您可以看到，远程客户机连接已经被重新路由到那里：

H:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      55         9.26.94.149.29200.060601001803
                                                         TEST1    1

如果再次查询数据库，那么可以从新的主服务器得到一个响应。而且，到原来主服务器的新连接也被重新路由到新的主服务器。

使用 GET SNAPSHOT 命令可以获得数据库的 HADR 状态。在 server2 上发出以下命令，应该可以看到 server2 已经接管了主数据库角色：

db2 "get snapshot for database on test1"

  HADR Status
  Role                   = Primary
  State                  = Peer
  Synchronization mode   = Nearsync
  Connection status      = Connected , 05/31/2006 20:17:24.989618
  Heartbeats missed      = 0
  Local host             = server2.torolab.ibm.com
  Local service          = 80000
  Remote host            = server1.torolab.ibm.com
  Remote service         = 70000
  Remote instance        = db2inst1
  timeout(seconds)       = 120
  Primary log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Standby log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Log gap running average(bytes) = 0

在执行接管操作之后，如果出故障的数据库又可以使用，它不会自动恢复主数据库的角色。

通过以下步骤可以使之重新成为主数据库：

修复原来的主数据库所在的系统。这包括修复有问题的硬件或者重新启动崩溃的操作系统。
重新启动出故障的主数据库，使之成为一个备用数据库。
执行一个接管操作，使之接管主数据库的角色。

当原来的主数据库重新以备用数据库的角色加入 HADR 对之后，执行一个接管操作来切换数据库的角色，使原来的主数据库再次成为主数据库。

为了停止 TEST1 数据库上的 HADR，发出：

STOP HADR ON DB test1

您可以看到，HADR 是实现高可用性解决方案的一个强大的特性。提供了一个名为 HADR 向导的图形化用户界面工具，以帮助您设置和配置 HADR。

如果选择 Set Up，那么就会打开一个如图 15 所示的逐步向导。

如果使用 Control Center 设置 HADR 环境，则会自动启用自动客户机重路由特性。

阅读(23791) | 评论(0) | 转发(0) |

上一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（4）

下一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（6）

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

16024965号-6

高可用性灾难恢复（HADR）

DB2 高可用性灾难恢复（HADR）是一种数据库复制特性，它提供了一种高可用性解决方案。目前，HADR 只用于单分区数据库环境。

为了设置 HADR 环境，要更新一些数据库配置参数。

首先，必须启用主数据库上的归档日志记录。请参阅备份和恢复教程，以了解如何启用归档日志记录。

表 1 列出了与 HADR 相关的数据库配置参数的描述。本教程后面将给出一个关于如何更新这些参数的例子。

与 HADR 相关的数据库配置参数	描述
HADR_LOCAL_HOST	指定 HADR TCPIP 通信的本地主机。主机名和 IP 地址都可以使用
HADR_LOCAL_SVC	指定 TCPIP 服务名和端口号，HADR 进程将在本地主机上接受该服务或端口的连接。这个端口不能与 HADR 实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_HOST	指定远程 HADR 节点的 TCPIP 主机名或 IP 地址
HADR_REMOTE_SVC	指定 TCPIP 服务名或端口号，HADR 进程将在远程节点上接受该服务或端口的连接。这个端口不能与远程实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_INST	指定远程服务器的实例名。DB2 Control Center 之类的管理工具将使用这个参数与远程服务器联系
HADR_TIMEOUT	HADR 进程在认为一次通信尝试失败之前所等待的时间（以秒为单位）。默认值为 120 秒
HADR_SYNCMODE	指定同步模式。它决定当系统处于对等状态时，主日志写与备用数据库如何同步。有效值有 SYNC、NEARSYNC 和 ASYNC。默认值为 NEARSYNC。（本节后面将讨论对等状态）。
HADR_DB_ROLE	指定一个数据库当前的角色。有效值有 STANDARD、PRIMARY 和 STANDBY。STANDARD 意味着数据库没有启用 HADR。

当备用数据库第一次启动时，它进入 local catch-up 状态。本地日志路径中的日志文件（如果有的话）将被读取，并应用到备用数据库。

当到达本地日志文件的最后时，备用数据库进入 remote catch-up 状态。它重演主数据库的归档日志和活动日志，直到备用数据库应用了最近的活动日志。

当主系统上的所有日志文件都已经被重演时，主数据库和备用数据库就进入对等（peer）状态。

在同步模式中，日志写只有在以下情况下才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库的日志文件中。

主数据库与备用数据库中的日志记录几乎（或近似）是同步的，因为只有在以下情况下，日志写才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库上的主存中。

在这种模式下，主数据库不等待收到备用数据库的通知。只有在以下情况下，日志写才被认为是成功的：

日志记录已经被写到主数据库上的日志文件中。
日志记录已经被传送到备用数据库；不需要通知。

HADR 是通过以下三个简单的命令来管理的：

START HADR
STOP HADR
TAKENOVER HADR

这些命令的语法如下：

START HADR ON DATABASE database-alias
[USER userid] [USING password] 
AS PRIMARY | STANDBY [BY FORCE]

STOP HADR ON DATABASE database-alias 
[USER userid] [USING password] 

TAKEOVER HADR ON DATABASE database-alias
[USER userid] [USING password] 
[BY FORCE]

您已经学习了 HADR 的概念，现在可以学习如何设置 HADR 环境。

使用另一个数据库服务器 server2.torolab.ibm.com 作为备用服务器。TEST1 当前不在备用服务器上。

服务名	实例名	SVCENAME 或端口号	数据库名
server1.torolab.ibm.com	DB2INST1	50000	TEST1
server2.torolab.ibm.com	DB2INST1	50000	--

第一次初始化 HADR 时，执行图 13 所示的五个步骤：

确定主服务器和备用服务器。决定主机名、主机 IP 地址和每个 HADR 数据库的服务名或端口号。
您已经确定了主服务器和备用服务器。主服务器是 server1。备用服务器是 server2。

确保这两个服务器是通过 TCPIP 相互通信的。尝试用主机名在这两个服务器上相互 ping 对方。应确保输出没有错误。如果主机名不能使用，那么尝试使用它们的 TCPIP 地址。选用两者中最好用的一种用于 HADR 配置。

通过克隆主数据库创建备用数据库。

有两种方案可用于克隆主数据库：

一种方案是为主数据库做一个备份，并在备用数据库上恢复这个数据库备份。这种方案使用标准备份和恢复方法。
克隆主数据库的另一种方案是使用分割镜像。为主数据库做一个分割镜像，然后在备用服务器上初始化该分割镜像。当初始化分割镜像时，必须在 db2inidb 命令中使用 standby 选项，以便使用 mirror 和 snapshot 选项。

在这个例子种，使用备份/恢复方法来创建备用数据库。

首先为 server1 上的主数据库 TEST1 做一个备份：

BACKUP DB test1

接着，通过 ftp 将备份镜像传送到备用服务器，并恢复该备份镜像。

将备份镜像恢复到与主服务器上相同的位置。在主服务器上，发出 LIST DB DIRECTORY 命令将显示：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            =
 Alternate server port number         =

数据库位于主服务器上的 C: 盘上。当在备用服务器上恢复备份镜像时，也将它恢复到 C: 盘。在备用服务器 server2 上，发出以下命令来恢复 TEST1 数据库：

RESTORE DB test1 ON C:

在主数据库和备用数据库上设置以下 HADR 配置参数：

HADR_LOCAL_HOST
HADR_LOCAL_SVC
HADR_REMOTE_HOST
HADR_REMOTE_SVC
HADR_REMOTE_INST
HADR_SYNCMODE
LOGINDEXBUILD

在主服务器上，为 HADR 使用端口号 70000。更新 Windows\System32\drivers\etc\services 文件，在其中添加以下一行：

Hadr_port 	70000/tcp

在备用服务器上的 services 文件中添加以下一行：

Hadr_port 	80000/tcp

为 HADR_SYNCMODE 使用默认值，即 NEARSYNC。

您已经有了配置 HADR 参数所需的所有信息。发出以下命令来配置备用服务器上的参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在主数据库服务器上，配置相同的一组参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在备用数据库上使用 START HADR 命令启动 HADR：
START HADR ON DB test1 AS STANDBY
在启动主数据库之前启动备用数据库。如果先启动主数据库，那么，如果没有在 HADR_TIMEOUT 数据库配置参数指定的期限内启动备用数据库，那么主数据库的启动过程就会失败。
在主数据库上启动 HADR，如下面的例子所示：
START HADR ON DB test1 AS PRIMARY
HADR 现在已经在主数据库和备用数据库上启动了。

当第一次启动主服务器时，它等待备用服务器与它联系。如果在指定期限内备用服务器没有与主服务器联系，那么 HADR 将不启动。这个期限可以用 HADR_TIMEOUT 配置参数（见表 1）来配置。这样做的目的是避免两个系统在偶然的情况下与主服务器同时启动。

在 HADR 启动过程中，数据库经历以下状态：local catch-up、remote catch-up pending、remote catch-up 和对等状态。日志被自动从主服务器传送到备用服务器，然后在备用服务器上重演。这是为了确保备用数据库跟上主数据库的变化。

强烈建议在主数据库和备用数据库所在的系统上使用相同的数据库配置参数和数据库管理器配置参数。否则，备用数据库就不会像主数据库一样执行。

一个例外是 LOGFILSIZ 数据库配置参数。这个参数的值被备用服务器所忽略。备用服务器自动创建与主数据库上的日志文件大小相匹配的日志文件。这保证了两个数据库上的日志文件是一致的。

在主数据库与备用数据库之间切换数据库角色，也就是说，备用数据库变成主数据库，主数据库变成备用数据库。
从主数据库故障转移到备用数据库。

   GET SNAPSHOT FOR DATABASE ON test1

下面的命令在备用数据库 TEST1 上开始 HADR 数据库切换角色操作：

   TAKEOVER HADR ON DB test1

故障转移方案不切换数据库角色。在故障转移操作期间，备用数据库接管主数据库角色，但是主数据库不会变成备用数据库。

下面的命令在数据库 TEST1 上开始一个 HADR 故障转移操作：

   TAKEOVER HADR ON DB test1 BY FORCE

表 3 和 4 总结了在备用数据库上发出的 TAKEOVER HADR 命令的行为，以及备用数据库所处的对应的 HADR 状态：

备用数据库的状态	接管行为
对等	主数据库和备用数据库都切换角色
Local catch-up or remote catch-up	错误
Remote catch-up pending	错误

备用数据库的状态	接管行为
对等	备用数据库通知主数据库关闭。备用数据库停止接收来自主数据库的日志，完成它已经收到的日志的重演，然后变成主数据库。备用数据库不用等到主数据库发来通知确认它受到接管通知或者它已经关闭
Local catch-up OR remote catch-up	错误
Remote catch-up pending	备用数据库变成主数据库

您已经看到了如何设置 HADR 环境，以及如何使用数据库角色切换和故障转移方案执行接管。

您学习了如何使用 HADR 使数据库具有高可用性。如果主数据库停机，那么它的备用数据库将接管，并成为新的主数据库。

为了启用自动客户机重路由特性，在主数据库上发出 UPDATE ALTERNATE SERVER 命令。该命令的语法如下：

UPDATE ALTERNATE SERVER FOR DATABASE database-alias
USING HOSTNAME alternate-server-hostname PORT port-number

为了在 server1 上的 TEST1 数据库上启用客户机重路由特性，以便在接管之后已有的和新的客户机连接被重新路由到 server2，在 server1 上发出以下命令：

UPDATE ALTERNATE SERVER FOR DATABASE test1 USING 
HOSTNAME server2.torolab.ibm.com PORT 50000

在这个例子中，50000 是 SVCENAME 端口，而不是 HADR 端口。

备用服务器信息存储在 server1 的数据库目录中。如果发出一个 LIST DB DIRECTORY 命令，那么可以注意到备用服务器信息（主机名和端口号）已经被添加：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

现在让我们来看一个关于如何在启用了自动客户机重路由特性的数据库上执行接管的例子。

在这个例子中，不带 BY FORCE 选项执行一个接管。

首先，建立到 server1 上的 TEST1 数据库的一个远程客户机连接。为此，只需在一个远程 DB2 客户机上发出一条 CONNECT TO DATABASE 命令：

CONNECT TO DB test1 USER user1

为了建立那样的连接，客户机必须已经被配置为连接到 server1。关于如何配置远程客户机连接的信息，请参考本系列中的第一篇教程。

在建立连接之后，主服务器上的备用服务器信息被获取并存储在客户机的数据库目录中：

 Database alias                       = TEST1
 Database name                        = TEST1
 Node name                            = server1
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Remote
 Catalog database partition number    = -1
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

确保该连接已成功建立，并且可以查询 TEST1 数据库。在 server1 上发出一条 LIST APPLICATION 命令，它应该显示数据库 TEST1 上的远程客户机连接：

D:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      8          9.26.94.149.24336.060601000305
                                                         TEST1    1

接着，在 TEST1 数据库上执行接管。在备用服务器 server2 上发出以下命令：

TAKEOVER HADR ON DB test1

让我们看看这次接管完成后远程客户机连接有什么变化。

再次尝试从客户机查询 TEST1 数据库。对 TEST1 数据库的任何查询应该都会返回一个错误消息。例如，从客户机连接发出一条 LIST TABLES 命令：

D:\Programs\IBM\SQLLIB\BIN>db2 list tables
SQL30108N A connection failed but has been re-established. 
The hostname or IP address is "server2" and the service name or port number is "50000". 
Special registers may or may not be re-attempted (Reason code = "1").  
SQLSTATE=08506

这证明客户机重路由特性在起作用。现在您已经连接到新的主服务器，即 server2。

在 server2 上发出一条 LIST APPLICATIONS 命令。您可以看到，远程客户机连接已经被重新路由到那里：

H:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      55         9.26.94.149.29200.060601001803
                                                         TEST1    1

如果再次查询数据库，那么可以从新的主服务器得到一个响应。而且，到原来主服务器的新连接也被重新路由到新的主服务器。

使用 GET SNAPSHOT 命令可以获得数据库的 HADR 状态。在 server2 上发出以下命令，应该可以看到 server2 已经接管了主数据库角色：

db2 "get snapshot for database on test1"

  HADR Status
  Role                   = Primary
  State                  = Peer
  Synchronization mode   = Nearsync
  Connection status      = Connected , 05/31/2006 20:17:24.989618
  Heartbeats missed      = 0
  Local host             = server2.torolab.ibm.com
  Local service          = 80000
  Remote host            = server1.torolab.ibm.com
  Remote service         = 70000
  Remote instance        = db2inst1
  timeout(seconds)       = 120
  Primary log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Standby log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Log gap running average(bytes) = 0

在执行接管操作之后，如果出故障的数据库又可以使用，它不会自动恢复主数据库的角色。

通过以下步骤可以使之重新成为主数据库：

修复原来的主数据库所在的系统。这包括修复有问题的硬件或者重新启动崩溃的操作系统。
重新启动出故障的主数据库，使之成为一个备用数据库。
执行一个接管操作，使之接管主数据库的角色。

当原来的主数据库重新以备用数据库的角色加入 HADR 对之后，执行一个接管操作来切换数据库的角色，使原来的主数据库再次成为主数据库。

为了停止 TEST1 数据库上的 HADR，发出：

STOP HADR ON DB test1

您可以看到，HADR 是实现高可用性解决方案的一个强大的特性。提供了一个名为 HADR 向导的图形化用户界面工具，以帮助您设置和配置 HADR。

如果选择 Set Up，那么就会打开一个如图 15 所示的逐步向导。

如果使用 Control Center 设置 HADR 环境，则会自动启用自动客户机重路由特性。

阅读(23790) | 评论(0) | 转发(0) |

上一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（4）

下一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（6）

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

16024965号-6

高可用性灾难恢复（HADR）

DB2 高可用性灾难恢复（HADR）是一种数据库复制特性，它提供了一种高可用性解决方案。目前，HADR 只用于单分区数据库环境。

为了设置 HADR 环境，要更新一些数据库配置参数。

首先，必须启用主数据库上的归档日志记录。请参阅备份和恢复教程，以了解如何启用归档日志记录。

表 1 列出了与 HADR 相关的数据库配置参数的描述。本教程后面将给出一个关于如何更新这些参数的例子。

与 HADR 相关的数据库配置参数	描述
HADR_LOCAL_HOST	指定 HADR TCPIP 通信的本地主机。主机名和 IP 地址都可以使用
HADR_LOCAL_SVC	指定 TCPIP 服务名和端口号，HADR 进程将在本地主机上接受该服务或端口的连接。这个端口不能与 HADR 实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_HOST	指定远程 HADR 节点的 TCPIP 主机名或 IP 地址
HADR_REMOTE_SVC	指定 TCPIP 服务名或端口号，HADR 进程将在远程节点上接受该服务或端口的连接。这个端口不能与远程实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_INST	指定远程服务器的实例名。DB2 Control Center 之类的管理工具将使用这个参数与远程服务器联系
HADR_TIMEOUT	HADR 进程在认为一次通信尝试失败之前所等待的时间（以秒为单位）。默认值为 120 秒
HADR_SYNCMODE	指定同步模式。它决定当系统处于对等状态时，主日志写与备用数据库如何同步。有效值有 SYNC、NEARSYNC 和 ASYNC。默认值为 NEARSYNC。（本节后面将讨论对等状态）。
HADR_DB_ROLE	指定一个数据库当前的角色。有效值有 STANDARD、PRIMARY 和 STANDBY。STANDARD 意味着数据库没有启用 HADR。

当备用数据库第一次启动时，它进入 local catch-up 状态。本地日志路径中的日志文件（如果有的话）将被读取，并应用到备用数据库。

当到达本地日志文件的最后时，备用数据库进入 remote catch-up 状态。它重演主数据库的归档日志和活动日志，直到备用数据库应用了最近的活动日志。

当主系统上的所有日志文件都已经被重演时，主数据库和备用数据库就进入对等（peer）状态。

在同步模式中，日志写只有在以下情况下才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库的日志文件中。

主数据库与备用数据库中的日志记录几乎（或近似）是同步的，因为只有在以下情况下，日志写才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库上的主存中。

在这种模式下，主数据库不等待收到备用数据库的通知。只有在以下情况下，日志写才被认为是成功的：

日志记录已经被写到主数据库上的日志文件中。
日志记录已经被传送到备用数据库；不需要通知。

HADR 是通过以下三个简单的命令来管理的：

START HADR
STOP HADR
TAKENOVER HADR

这些命令的语法如下：

START HADR ON DATABASE database-alias
[USER userid] [USING password] 
AS PRIMARY | STANDBY [BY FORCE]

STOP HADR ON DATABASE database-alias 
[USER userid] [USING password] 

TAKEOVER HADR ON DATABASE database-alias
[USER userid] [USING password] 
[BY FORCE]

您已经学习了 HADR 的概念，现在可以学习如何设置 HADR 环境。

使用另一个数据库服务器 server2.torolab.ibm.com 作为备用服务器。TEST1 当前不在备用服务器上。

服务名	实例名	SVCENAME 或端口号	数据库名
server1.torolab.ibm.com	DB2INST1	50000	TEST1
server2.torolab.ibm.com	DB2INST1	50000	--

第一次初始化 HADR 时，执行图 13 所示的五个步骤：

确定主服务器和备用服务器。决定主机名、主机 IP 地址和每个 HADR 数据库的服务名或端口号。
您已经确定了主服务器和备用服务器。主服务器是 server1。备用服务器是 server2。

确保这两个服务器是通过 TCPIP 相互通信的。尝试用主机名在这两个服务器上相互 ping 对方。应确保输出没有错误。如果主机名不能使用，那么尝试使用它们的 TCPIP 地址。选用两者中最好用的一种用于 HADR 配置。

通过克隆主数据库创建备用数据库。

有两种方案可用于克隆主数据库：

一种方案是为主数据库做一个备份，并在备用数据库上恢复这个数据库备份。这种方案使用标准备份和恢复方法。
克隆主数据库的另一种方案是使用分割镜像。为主数据库做一个分割镜像，然后在备用服务器上初始化该分割镜像。当初始化分割镜像时，必须在 db2inidb 命令中使用 standby 选项，以便使用 mirror 和 snapshot 选项。

在这个例子种，使用备份/恢复方法来创建备用数据库。

首先为 server1 上的主数据库 TEST1 做一个备份：

BACKUP DB test1

接着，通过 ftp 将备份镜像传送到备用服务器，并恢复该备份镜像。

将备份镜像恢复到与主服务器上相同的位置。在主服务器上，发出 LIST DB DIRECTORY 命令将显示：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            =
 Alternate server port number         =

数据库位于主服务器上的 C: 盘上。当在备用服务器上恢复备份镜像时，也将它恢复到 C: 盘。在备用服务器 server2 上，发出以下命令来恢复 TEST1 数据库：

RESTORE DB test1 ON C:

在主数据库和备用数据库上设置以下 HADR 配置参数：

HADR_LOCAL_HOST
HADR_LOCAL_SVC
HADR_REMOTE_HOST
HADR_REMOTE_SVC
HADR_REMOTE_INST
HADR_SYNCMODE
LOGINDEXBUILD

在主服务器上，为 HADR 使用端口号 70000。更新 Windows\System32\drivers\etc\services 文件，在其中添加以下一行：

Hadr_port 	70000/tcp

在备用服务器上的 services 文件中添加以下一行：

Hadr_port 	80000/tcp

为 HADR_SYNCMODE 使用默认值，即 NEARSYNC。

您已经有了配置 HADR 参数所需的所有信息。发出以下命令来配置备用服务器上的参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在主数据库服务器上，配置相同的一组参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在备用数据库上使用 START HADR 命令启动 HADR：
START HADR ON DB test1 AS STANDBY
在启动主数据库之前启动备用数据库。如果先启动主数据库，那么，如果没有在 HADR_TIMEOUT 数据库配置参数指定的期限内启动备用数据库，那么主数据库的启动过程就会失败。
在主数据库上启动 HADR，如下面的例子所示：
START HADR ON DB test1 AS PRIMARY
HADR 现在已经在主数据库和备用数据库上启动了。

当第一次启动主服务器时，它等待备用服务器与它联系。如果在指定期限内备用服务器没有与主服务器联系，那么 HADR 将不启动。这个期限可以用 HADR_TIMEOUT 配置参数（见表 1）来配置。这样做的目的是避免两个系统在偶然的情况下与主服务器同时启动。

在 HADR 启动过程中，数据库经历以下状态：local catch-up、remote catch-up pending、remote catch-up 和对等状态。日志被自动从主服务器传送到备用服务器，然后在备用服务器上重演。这是为了确保备用数据库跟上主数据库的变化。

强烈建议在主数据库和备用数据库所在的系统上使用相同的数据库配置参数和数据库管理器配置参数。否则，备用数据库就不会像主数据库一样执行。

一个例外是 LOGFILSIZ 数据库配置参数。这个参数的值被备用服务器所忽略。备用服务器自动创建与主数据库上的日志文件大小相匹配的日志文件。这保证了两个数据库上的日志文件是一致的。

在主数据库与备用数据库之间切换数据库角色，也就是说，备用数据库变成主数据库，主数据库变成备用数据库。
从主数据库故障转移到备用数据库。

   GET SNAPSHOT FOR DATABASE ON test1

下面的命令在备用数据库 TEST1 上开始 HADR 数据库切换角色操作：

   TAKEOVER HADR ON DB test1

故障转移方案不切换数据库角色。在故障转移操作期间，备用数据库接管主数据库角色，但是主数据库不会变成备用数据库。

下面的命令在数据库 TEST1 上开始一个 HADR 故障转移操作：

   TAKEOVER HADR ON DB test1 BY FORCE

表 3 和 4 总结了在备用数据库上发出的 TAKEOVER HADR 命令的行为，以及备用数据库所处的对应的 HADR 状态：

备用数据库的状态	接管行为
对等	主数据库和备用数据库都切换角色
Local catch-up or remote catch-up	错误
Remote catch-up pending	错误

备用数据库的状态	接管行为
对等	备用数据库通知主数据库关闭。备用数据库停止接收来自主数据库的日志，完成它已经收到的日志的重演，然后变成主数据库。备用数据库不用等到主数据库发来通知确认它受到接管通知或者它已经关闭
Local catch-up OR remote catch-up	错误
Remote catch-up pending	备用数据库变成主数据库

您已经看到了如何设置 HADR 环境，以及如何使用数据库角色切换和故障转移方案执行接管。

您学习了如何使用 HADR 使数据库具有高可用性。如果主数据库停机，那么它的备用数据库将接管，并成为新的主数据库。

为了启用自动客户机重路由特性，在主数据库上发出 UPDATE ALTERNATE SERVER 命令。该命令的语法如下：

UPDATE ALTERNATE SERVER FOR DATABASE database-alias
USING HOSTNAME alternate-server-hostname PORT port-number

为了在 server1 上的 TEST1 数据库上启用客户机重路由特性，以便在接管之后已有的和新的客户机连接被重新路由到 server2，在 server1 上发出以下命令：

UPDATE ALTERNATE SERVER FOR DATABASE test1 USING 
HOSTNAME server2.torolab.ibm.com PORT 50000

在这个例子中，50000 是 SVCENAME 端口，而不是 HADR 端口。

备用服务器信息存储在 server1 的数据库目录中。如果发出一个 LIST DB DIRECTORY 命令，那么可以注意到备用服务器信息（主机名和端口号）已经被添加：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

现在让我们来看一个关于如何在启用了自动客户机重路由特性的数据库上执行接管的例子。

在这个例子中，不带 BY FORCE 选项执行一个接管。

首先，建立到 server1 上的 TEST1 数据库的一个远程客户机连接。为此，只需在一个远程 DB2 客户机上发出一条 CONNECT TO DATABASE 命令：

CONNECT TO DB test1 USER user1

为了建立那样的连接，客户机必须已经被配置为连接到 server1。关于如何配置远程客户机连接的信息，请参考本系列中的第一篇教程。

在建立连接之后，主服务器上的备用服务器信息被获取并存储在客户机的数据库目录中：

 Database alias                       = TEST1
 Database name                        = TEST1
 Node name                            = server1
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Remote
 Catalog database partition number    = -1
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

确保该连接已成功建立，并且可以查询 TEST1 数据库。在 server1 上发出一条 LIST APPLICATION 命令，它应该显示数据库 TEST1 上的远程客户机连接：

D:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      8          9.26.94.149.24336.060601000305
                                                         TEST1    1

接着，在 TEST1 数据库上执行接管。在备用服务器 server2 上发出以下命令：

TAKEOVER HADR ON DB test1

让我们看看这次接管完成后远程客户机连接有什么变化。

再次尝试从客户机查询 TEST1 数据库。对 TEST1 数据库的任何查询应该都会返回一个错误消息。例如，从客户机连接发出一条 LIST TABLES 命令：

D:\Programs\IBM\SQLLIB\BIN>db2 list tables
SQL30108N A connection failed but has been re-established. 
The hostname or IP address is "server2" and the service name or port number is "50000". 
Special registers may or may not be re-attempted (Reason code = "1").  
SQLSTATE=08506

这证明客户机重路由特性在起作用。现在您已经连接到新的主服务器，即 server2。

在 server2 上发出一条 LIST APPLICATIONS 命令。您可以看到，远程客户机连接已经被重新路由到那里：

H:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      55         9.26.94.149.29200.060601001803
                                                         TEST1    1

如果再次查询数据库，那么可以从新的主服务器得到一个响应。而且，到原来主服务器的新连接也被重新路由到新的主服务器。

使用 GET SNAPSHOT 命令可以获得数据库的 HADR 状态。在 server2 上发出以下命令，应该可以看到 server2 已经接管了主数据库角色：

db2 "get snapshot for database on test1"

  HADR Status
  Role                   = Primary
  State                  = Peer
  Synchronization mode   = Nearsync
  Connection status      = Connected , 05/31/2006 20:17:24.989618
  Heartbeats missed      = 0
  Local host             = server2.torolab.ibm.com
  Local service          = 80000
  Remote host            = server1.torolab.ibm.com
  Remote service         = 70000
  Remote instance        = db2inst1
  timeout(seconds)       = 120
  Primary log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Standby log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Log gap running average(bytes) = 0

在执行接管操作之后，如果出故障的数据库又可以使用，它不会自动恢复主数据库的角色。

通过以下步骤可以使之重新成为主数据库：

修复原来的主数据库所在的系统。这包括修复有问题的硬件或者重新启动崩溃的操作系统。
重新启动出故障的主数据库，使之成为一个备用数据库。
执行一个接管操作，使之接管主数据库的角色。

当原来的主数据库重新以备用数据库的角色加入 HADR 对之后，执行一个接管操作来切换数据库的角色，使原来的主数据库再次成为主数据库。

为了停止 TEST1 数据库上的 HADR，发出：

STOP HADR ON DB test1

您可以看到，HADR 是实现高可用性解决方案的一个强大的特性。提供了一个名为 HADR 向导的图形化用户界面工具，以帮助您设置和配置 HADR。

如果选择 Set Up，那么就会打开一个如图 15 所示的逐步向导。

如果使用 Control Center 设置 HADR 环境，则会自动启用自动客户机重路由特性。

阅读(23789) | 评论(0) | 转发(0) |

上一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（4）

下一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（6）

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

16024965号-6

高可用性灾难恢复（HADR）

DB2 高可用性灾难恢复（HADR）是一种数据库复制特性，它提供了一种高可用性解决方案。目前，HADR 只用于单分区数据库环境。

为了设置 HADR 环境，要更新一些数据库配置参数。

首先，必须启用主数据库上的归档日志记录。请参阅备份和恢复教程，以了解如何启用归档日志记录。

表 1 列出了与 HADR 相关的数据库配置参数的描述。本教程后面将给出一个关于如何更新这些参数的例子。

与 HADR 相关的数据库配置参数	描述
HADR_LOCAL_HOST	指定 HADR TCPIP 通信的本地主机。主机名和 IP 地址都可以使用
HADR_LOCAL_SVC	指定 TCPIP 服务名和端口号，HADR 进程将在本地主机上接受该服务或端口的连接。这个端口不能与 HADR 实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_HOST	指定远程 HADR 节点的 TCPIP 主机名或 IP 地址
HADR_REMOTE_SVC	指定 TCPIP 服务名或端口号，HADR 进程将在远程节点上接受该服务或端口的连接。这个端口不能与远程实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_INST	指定远程服务器的实例名。DB2 Control Center 之类的管理工具将使用这个参数与远程服务器联系
HADR_TIMEOUT	HADR 进程在认为一次通信尝试失败之前所等待的时间（以秒为单位）。默认值为 120 秒
HADR_SYNCMODE	指定同步模式。它决定当系统处于对等状态时，主日志写与备用数据库如何同步。有效值有 SYNC、NEARSYNC 和 ASYNC。默认值为 NEARSYNC。（本节后面将讨论对等状态）。
HADR_DB_ROLE	指定一个数据库当前的角色。有效值有 STANDARD、PRIMARY 和 STANDBY。STANDARD 意味着数据库没有启用 HADR。

当备用数据库第一次启动时，它进入 local catch-up 状态。本地日志路径中的日志文件（如果有的话）将被读取，并应用到备用数据库。

当到达本地日志文件的最后时，备用数据库进入 remote catch-up 状态。它重演主数据库的归档日志和活动日志，直到备用数据库应用了最近的活动日志。

当主系统上的所有日志文件都已经被重演时，主数据库和备用数据库就进入对等（peer）状态。

在同步模式中，日志写只有在以下情况下才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库的日志文件中。

主数据库与备用数据库中的日志记录几乎（或近似）是同步的，因为只有在以下情况下，日志写才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库上的主存中。

在这种模式下，主数据库不等待收到备用数据库的通知。只有在以下情况下，日志写才被认为是成功的：

日志记录已经被写到主数据库上的日志文件中。
日志记录已经被传送到备用数据库；不需要通知。

HADR 是通过以下三个简单的命令来管理的：

START HADR
STOP HADR
TAKENOVER HADR

这些命令的语法如下：

START HADR ON DATABASE database-alias
[USER userid] [USING password] 
AS PRIMARY | STANDBY [BY FORCE]

STOP HADR ON DATABASE database-alias 
[USER userid] [USING password] 

TAKEOVER HADR ON DATABASE database-alias
[USER userid] [USING password] 
[BY FORCE]

您已经学习了 HADR 的概念，现在可以学习如何设置 HADR 环境。

使用另一个数据库服务器 server2.torolab.ibm.com 作为备用服务器。TEST1 当前不在备用服务器上。

服务名	实例名	SVCENAME 或端口号	数据库名
server1.torolab.ibm.com	DB2INST1	50000	TEST1
server2.torolab.ibm.com	DB2INST1	50000	--

第一次初始化 HADR 时，执行图 13 所示的五个步骤：

确定主服务器和备用服务器。决定主机名、主机 IP 地址和每个 HADR 数据库的服务名或端口号。
您已经确定了主服务器和备用服务器。主服务器是 server1。备用服务器是 server2。

确保这两个服务器是通过 TCPIP 相互通信的。尝试用主机名在这两个服务器上相互 ping 对方。应确保输出没有错误。如果主机名不能使用，那么尝试使用它们的 TCPIP 地址。选用两者中最好用的一种用于 HADR 配置。

通过克隆主数据库创建备用数据库。

有两种方案可用于克隆主数据库：

一种方案是为主数据库做一个备份，并在备用数据库上恢复这个数据库备份。这种方案使用标准备份和恢复方法。
克隆主数据库的另一种方案是使用分割镜像。为主数据库做一个分割镜像，然后在备用服务器上初始化该分割镜像。当初始化分割镜像时，必须在 db2inidb 命令中使用 standby 选项，以便使用 mirror 和 snapshot 选项。

在这个例子种，使用备份/恢复方法来创建备用数据库。

首先为 server1 上的主数据库 TEST1 做一个备份：

BACKUP DB test1

接着，通过 ftp 将备份镜像传送到备用服务器，并恢复该备份镜像。

将备份镜像恢复到与主服务器上相同的位置。在主服务器上，发出 LIST DB DIRECTORY 命令将显示：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            =
 Alternate server port number         =

数据库位于主服务器上的 C: 盘上。当在备用服务器上恢复备份镜像时，也将它恢复到 C: 盘。在备用服务器 server2 上，发出以下命令来恢复 TEST1 数据库：

RESTORE DB test1 ON C:

在主数据库和备用数据库上设置以下 HADR 配置参数：

HADR_LOCAL_HOST
HADR_LOCAL_SVC
HADR_REMOTE_HOST
HADR_REMOTE_SVC
HADR_REMOTE_INST
HADR_SYNCMODE
LOGINDEXBUILD

在主服务器上，为 HADR 使用端口号 70000。更新 Windows\System32\drivers\etc\services 文件，在其中添加以下一行：

Hadr_port 	70000/tcp

在备用服务器上的 services 文件中添加以下一行：

Hadr_port 	80000/tcp

为 HADR_SYNCMODE 使用默认值，即 NEARSYNC。

您已经有了配置 HADR 参数所需的所有信息。发出以下命令来配置备用服务器上的参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在主数据库服务器上，配置相同的一组参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在备用数据库上使用 START HADR 命令启动 HADR：
START HADR ON DB test1 AS STANDBY
在启动主数据库之前启动备用数据库。如果先启动主数据库，那么，如果没有在 HADR_TIMEOUT 数据库配置参数指定的期限内启动备用数据库，那么主数据库的启动过程就会失败。
在主数据库上启动 HADR，如下面的例子所示：
START HADR ON DB test1 AS PRIMARY
HADR 现在已经在主数据库和备用数据库上启动了。

当第一次启动主服务器时，它等待备用服务器与它联系。如果在指定期限内备用服务器没有与主服务器联系，那么 HADR 将不启动。这个期限可以用 HADR_TIMEOUT 配置参数（见表 1）来配置。这样做的目的是避免两个系统在偶然的情况下与主服务器同时启动。

在 HADR 启动过程中，数据库经历以下状态：local catch-up、remote catch-up pending、remote catch-up 和对等状态。日志被自动从主服务器传送到备用服务器，然后在备用服务器上重演。这是为了确保备用数据库跟上主数据库的变化。

强烈建议在主数据库和备用数据库所在的系统上使用相同的数据库配置参数和数据库管理器配置参数。否则，备用数据库就不会像主数据库一样执行。

一个例外是 LOGFILSIZ 数据库配置参数。这个参数的值被备用服务器所忽略。备用服务器自动创建与主数据库上的日志文件大小相匹配的日志文件。这保证了两个数据库上的日志文件是一致的。

在主数据库与备用数据库之间切换数据库角色，也就是说，备用数据库变成主数据库，主数据库变成备用数据库。
从主数据库故障转移到备用数据库。

   GET SNAPSHOT FOR DATABASE ON test1

下面的命令在备用数据库 TEST1 上开始 HADR 数据库切换角色操作：

   TAKEOVER HADR ON DB test1

故障转移方案不切换数据库角色。在故障转移操作期间，备用数据库接管主数据库角色，但是主数据库不会变成备用数据库。

下面的命令在数据库 TEST1 上开始一个 HADR 故障转移操作：

   TAKEOVER HADR ON DB test1 BY FORCE

表 3 和 4 总结了在备用数据库上发出的 TAKEOVER HADR 命令的行为，以及备用数据库所处的对应的 HADR 状态：

备用数据库的状态	接管行为
对等	主数据库和备用数据库都切换角色
Local catch-up or remote catch-up	错误
Remote catch-up pending	错误

备用数据库的状态	接管行为
对等	备用数据库通知主数据库关闭。备用数据库停止接收来自主数据库的日志，完成它已经收到的日志的重演，然后变成主数据库。备用数据库不用等到主数据库发来通知确认它受到接管通知或者它已经关闭
Local catch-up OR remote catch-up	错误
Remote catch-up pending	备用数据库变成主数据库

您已经看到了如何设置 HADR 环境，以及如何使用数据库角色切换和故障转移方案执行接管。

您学习了如何使用 HADR 使数据库具有高可用性。如果主数据库停机，那么它的备用数据库将接管，并成为新的主数据库。

为了启用自动客户机重路由特性，在主数据库上发出 UPDATE ALTERNATE SERVER 命令。该命令的语法如下：

UPDATE ALTERNATE SERVER FOR DATABASE database-alias
USING HOSTNAME alternate-server-hostname PORT port-number

为了在 server1 上的 TEST1 数据库上启用客户机重路由特性，以便在接管之后已有的和新的客户机连接被重新路由到 server2，在 server1 上发出以下命令：

UPDATE ALTERNATE SERVER FOR DATABASE test1 USING 
HOSTNAME server2.torolab.ibm.com PORT 50000

在这个例子中，50000 是 SVCENAME 端口，而不是 HADR 端口。

备用服务器信息存储在 server1 的数据库目录中。如果发出一个 LIST DB DIRECTORY 命令，那么可以注意到备用服务器信息（主机名和端口号）已经被添加：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

现在让我们来看一个关于如何在启用了自动客户机重路由特性的数据库上执行接管的例子。

在这个例子中，不带 BY FORCE 选项执行一个接管。

首先，建立到 server1 上的 TEST1 数据库的一个远程客户机连接。为此，只需在一个远程 DB2 客户机上发出一条 CONNECT TO DATABASE 命令：

CONNECT TO DB test1 USER user1

为了建立那样的连接，客户机必须已经被配置为连接到 server1。关于如何配置远程客户机连接的信息，请参考本系列中的第一篇教程。

在建立连接之后，主服务器上的备用服务器信息被获取并存储在客户机的数据库目录中：

 Database alias                       = TEST1
 Database name                        = TEST1
 Node name                            = server1
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Remote
 Catalog database partition number    = -1
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

确保该连接已成功建立，并且可以查询 TEST1 数据库。在 server1 上发出一条 LIST APPLICATION 命令，它应该显示数据库 TEST1 上的远程客户机连接：

D:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      8          9.26.94.149.24336.060601000305
                                                         TEST1    1

接着，在 TEST1 数据库上执行接管。在备用服务器 server2 上发出以下命令：

TAKEOVER HADR ON DB test1

让我们看看这次接管完成后远程客户机连接有什么变化。

再次尝试从客户机查询 TEST1 数据库。对 TEST1 数据库的任何查询应该都会返回一个错误消息。例如，从客户机连接发出一条 LIST TABLES 命令：

D:\Programs\IBM\SQLLIB\BIN>db2 list tables
SQL30108N A connection failed but has been re-established. 
The hostname or IP address is "server2" and the service name or port number is "50000". 
Special registers may or may not be re-attempted (Reason code = "1").  
SQLSTATE=08506

这证明客户机重路由特性在起作用。现在您已经连接到新的主服务器，即 server2。

在 server2 上发出一条 LIST APPLICATIONS 命令。您可以看到，远程客户机连接已经被重新路由到那里：

H:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      55         9.26.94.149.29200.060601001803
                                                         TEST1    1

如果再次查询数据库，那么可以从新的主服务器得到一个响应。而且，到原来主服务器的新连接也被重新路由到新的主服务器。

使用 GET SNAPSHOT 命令可以获得数据库的 HADR 状态。在 server2 上发出以下命令，应该可以看到 server2 已经接管了主数据库角色：

db2 "get snapshot for database on test1"

  HADR Status
  Role                   = Primary
  State                  = Peer
  Synchronization mode   = Nearsync
  Connection status      = Connected , 05/31/2006 20:17:24.989618
  Heartbeats missed      = 0
  Local host             = server2.torolab.ibm.com
  Local service          = 80000
  Remote host            = server1.torolab.ibm.com
  Remote service         = 70000
  Remote instance        = db2inst1
  timeout(seconds)       = 120
  Primary log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Standby log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Log gap running average(bytes) = 0

在执行接管操作之后，如果出故障的数据库又可以使用，它不会自动恢复主数据库的角色。

通过以下步骤可以使之重新成为主数据库：

修复原来的主数据库所在的系统。这包括修复有问题的硬件或者重新启动崩溃的操作系统。
重新启动出故障的主数据库，使之成为一个备用数据库。
执行一个接管操作，使之接管主数据库的角色。

当原来的主数据库重新以备用数据库的角色加入 HADR 对之后，执行一个接管操作来切换数据库的角色，使原来的主数据库再次成为主数据库。

为了停止 TEST1 数据库上的 HADR，发出：

STOP HADR ON DB test1

您可以看到，HADR 是实现高可用性解决方案的一个强大的特性。提供了一个名为 HADR 向导的图形化用户界面工具，以帮助您设置和配置 HADR。

如果选择 Set Up，那么就会打开一个如图 15 所示的逐步向导。

如果使用 Control Center 设置 HADR 环境，则会自动启用自动客户机重路由特性。

阅读(23788) | 评论(0) | 转发(0) |

上一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（4）

下一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（6）

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

16024965号-6

高可用性灾难恢复（HADR）

DB2 高可用性灾难恢复（HADR）是一种数据库复制特性，它提供了一种高可用性解决方案。目前，HADR 只用于单分区数据库环境。

为了设置 HADR 环境，要更新一些数据库配置参数。

首先，必须启用主数据库上的归档日志记录。请参阅备份和恢复教程，以了解如何启用归档日志记录。

表 1 列出了与 HADR 相关的数据库配置参数的描述。本教程后面将给出一个关于如何更新这些参数的例子。

与 HADR 相关的数据库配置参数	描述
HADR_LOCAL_HOST	指定 HADR TCPIP 通信的本地主机。主机名和 IP 地址都可以使用
HADR_LOCAL_SVC	指定 TCPIP 服务名和端口号，HADR 进程将在本地主机上接受该服务或端口的连接。这个端口不能与 HADR 实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_HOST	指定远程 HADR 节点的 TCPIP 主机名或 IP 地址
HADR_REMOTE_SVC	指定 TCPIP 服务名或端口号，HADR 进程将在远程节点上接受该服务或端口的连接。这个端口不能与远程实例的 SVCENAME 或 SVCENAME +1 相同
HADR_REMOTE_INST	指定远程服务器的实例名。DB2 Control Center 之类的管理工具将使用这个参数与远程服务器联系
HADR_TIMEOUT	HADR 进程在认为一次通信尝试失败之前所等待的时间（以秒为单位）。默认值为 120 秒
HADR_SYNCMODE	指定同步模式。它决定当系统处于对等状态时，主日志写与备用数据库如何同步。有效值有 SYNC、NEARSYNC 和 ASYNC。默认值为 NEARSYNC。（本节后面将讨论对等状态）。
HADR_DB_ROLE	指定一个数据库当前的角色。有效值有 STANDARD、PRIMARY 和 STANDBY。STANDARD 意味着数据库没有启用 HADR。

当备用数据库第一次启动时，它进入 local catch-up 状态。本地日志路径中的日志文件（如果有的话）将被读取，并应用到备用数据库。

当到达本地日志文件的最后时，备用数据库进入 remote catch-up 状态。它重演主数据库的归档日志和活动日志，直到备用数据库应用了最近的活动日志。

当主系统上的所有日志文件都已经被重演时，主数据库和备用数据库就进入对等（peer）状态。

在同步模式中，日志写只有在以下情况下才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库的日志文件中。

主数据库与备用数据库中的日志记录几乎（或近似）是同步的，因为只有在以下情况下，日志写才被认为是成功的：

日志已经被写到主数据库上的日志文件中。
主数据库收到备用数据库的通知，被告知日志已经被成功地写到备用数据库上的主存中。

在这种模式下，主数据库不等待收到备用数据库的通知。只有在以下情况下，日志写才被认为是成功的：

日志记录已经被写到主数据库上的日志文件中。
日志记录已经被传送到备用数据库；不需要通知。

HADR 是通过以下三个简单的命令来管理的：

START HADR
STOP HADR
TAKENOVER HADR

这些命令的语法如下：

START HADR ON DATABASE database-alias
[USER userid] [USING password] 
AS PRIMARY | STANDBY [BY FORCE]

STOP HADR ON DATABASE database-alias 
[USER userid] [USING password] 

TAKEOVER HADR ON DATABASE database-alias
[USER userid] [USING password] 
[BY FORCE]

您已经学习了 HADR 的概念，现在可以学习如何设置 HADR 环境。

使用另一个数据库服务器 server2.torolab.ibm.com 作为备用服务器。TEST1 当前不在备用服务器上。

服务名	实例名	SVCENAME 或端口号	数据库名
server1.torolab.ibm.com	DB2INST1	50000	TEST1
server2.torolab.ibm.com	DB2INST1	50000	--

第一次初始化 HADR 时，执行图 13 所示的五个步骤：

确定主服务器和备用服务器。决定主机名、主机 IP 地址和每个 HADR 数据库的服务名或端口号。
您已经确定了主服务器和备用服务器。主服务器是 server1。备用服务器是 server2。

确保这两个服务器是通过 TCPIP 相互通信的。尝试用主机名在这两个服务器上相互 ping 对方。应确保输出没有错误。如果主机名不能使用，那么尝试使用它们的 TCPIP 地址。选用两者中最好用的一种用于 HADR 配置。

通过克隆主数据库创建备用数据库。

有两种方案可用于克隆主数据库：

一种方案是为主数据库做一个备份，并在备用数据库上恢复这个数据库备份。这种方案使用标准备份和恢复方法。
克隆主数据库的另一种方案是使用分割镜像。为主数据库做一个分割镜像，然后在备用服务器上初始化该分割镜像。当初始化分割镜像时，必须在 db2inidb 命令中使用 standby 选项，以便使用 mirror 和 snapshot 选项。

在这个例子种，使用备份/恢复方法来创建备用数据库。

首先为 server1 上的主数据库 TEST1 做一个备份：

BACKUP DB test1

接着，通过 ftp 将备份镜像传送到备用服务器，并恢复该备份镜像。

将备份镜像恢复到与主服务器上相同的位置。在主服务器上，发出 LIST DB DIRECTORY 命令将显示：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            =
 Alternate server port number         =

数据库位于主服务器上的 C: 盘上。当在备用服务器上恢复备份镜像时，也将它恢复到 C: 盘。在备用服务器 server2 上，发出以下命令来恢复 TEST1 数据库：

RESTORE DB test1 ON C:

在主数据库和备用数据库上设置以下 HADR 配置参数：

HADR_LOCAL_HOST
HADR_LOCAL_SVC
HADR_REMOTE_HOST
HADR_REMOTE_SVC
HADR_REMOTE_INST
HADR_SYNCMODE
LOGINDEXBUILD

在主服务器上，为 HADR 使用端口号 70000。更新 Windows\System32\drivers\etc\services 文件，在其中添加以下一行：

Hadr_port 	70000/tcp

在备用服务器上的 services 文件中添加以下一行：

Hadr_port 	80000/tcp

为 HADR_SYNCMODE 使用默认值，即 NEARSYNC。

您已经有了配置 HADR 参数所需的所有信息。发出以下命令来配置备用服务器上的参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在主数据库服务器上，配置相同的一组参数：

UPDATE DB CFG FOR test1 USING HADR_LOCAL_HOST server1.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_LOCAL_SVC 70000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_HOST server2.torolab.ibm.com
UPDATE DB CFG FOR test1 USING HADR_REMOTE_SVC 80000
UPDATE DB CFG FOR test1 USING HADR_REMOTE_INST db2inst1
UPDATE DB CFG FOR test1 USING LOGINDEXBUILD on

在备用数据库上使用 START HADR 命令启动 HADR：
START HADR ON DB test1 AS STANDBY
在启动主数据库之前启动备用数据库。如果先启动主数据库，那么，如果没有在 HADR_TIMEOUT 数据库配置参数指定的期限内启动备用数据库，那么主数据库的启动过程就会失败。
在主数据库上启动 HADR，如下面的例子所示：
START HADR ON DB test1 AS PRIMARY
HADR 现在已经在主数据库和备用数据库上启动了。

当第一次启动主服务器时，它等待备用服务器与它联系。如果在指定期限内备用服务器没有与主服务器联系，那么 HADR 将不启动。这个期限可以用 HADR_TIMEOUT 配置参数（见表 1）来配置。这样做的目的是避免两个系统在偶然的情况下与主服务器同时启动。

在 HADR 启动过程中，数据库经历以下状态：local catch-up、remote catch-up pending、remote catch-up 和对等状态。日志被自动从主服务器传送到备用服务器，然后在备用服务器上重演。这是为了确保备用数据库跟上主数据库的变化。

强烈建议在主数据库和备用数据库所在的系统上使用相同的数据库配置参数和数据库管理器配置参数。否则，备用数据库就不会像主数据库一样执行。

一个例外是 LOGFILSIZ 数据库配置参数。这个参数的值被备用服务器所忽略。备用服务器自动创建与主数据库上的日志文件大小相匹配的日志文件。这保证了两个数据库上的日志文件是一致的。

在主数据库与备用数据库之间切换数据库角色，也就是说，备用数据库变成主数据库，主数据库变成备用数据库。
从主数据库故障转移到备用数据库。

   GET SNAPSHOT FOR DATABASE ON test1

下面的命令在备用数据库 TEST1 上开始 HADR 数据库切换角色操作：

   TAKEOVER HADR ON DB test1

故障转移方案不切换数据库角色。在故障转移操作期间，备用数据库接管主数据库角色，但是主数据库不会变成备用数据库。

下面的命令在数据库 TEST1 上开始一个 HADR 故障转移操作：

   TAKEOVER HADR ON DB test1 BY FORCE

表 3 和 4 总结了在备用数据库上发出的 TAKEOVER HADR 命令的行为，以及备用数据库所处的对应的 HADR 状态：

备用数据库的状态	接管行为
对等	主数据库和备用数据库都切换角色
Local catch-up or remote catch-up	错误
Remote catch-up pending	错误

备用数据库的状态	接管行为
对等	备用数据库通知主数据库关闭。备用数据库停止接收来自主数据库的日志，完成它已经收到的日志的重演，然后变成主数据库。备用数据库不用等到主数据库发来通知确认它受到接管通知或者它已经关闭
Local catch-up OR remote catch-up	错误
Remote catch-up pending	备用数据库变成主数据库

您已经看到了如何设置 HADR 环境，以及如何使用数据库角色切换和故障转移方案执行接管。

您学习了如何使用 HADR 使数据库具有高可用性。如果主数据库停机，那么它的备用数据库将接管，并成为新的主数据库。

为了启用自动客户机重路由特性，在主数据库上发出 UPDATE ALTERNATE SERVER 命令。该命令的语法如下：

UPDATE ALTERNATE SERVER FOR DATABASE database-alias
USING HOSTNAME alternate-server-hostname PORT port-number

为了在 server1 上的 TEST1 数据库上启用客户机重路由特性，以便在接管之后已有的和新的客户机连接被重新路由到 server2，在 server1 上发出以下命令：

UPDATE ALTERNATE SERVER FOR DATABASE test1 USING 
HOSTNAME server2.torolab.ibm.com PORT 50000

在这个例子中，50000 是 SVCENAME 端口，而不是 HADR 端口。

备用服务器信息存储在 server1 的数据库目录中。如果发出一个 LIST DB DIRECTORY 命令，那么可以注意到备用服务器信息（主机名和端口号）已经被添加：

 Database alias                       = TEST1
 Database name                        = TEST1
 Local database directory             = C:
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

现在让我们来看一个关于如何在启用了自动客户机重路由特性的数据库上执行接管的例子。

在这个例子中，不带 BY FORCE 选项执行一个接管。

首先，建立到 server1 上的 TEST1 数据库的一个远程客户机连接。为此，只需在一个远程 DB2 客户机上发出一条 CONNECT TO DATABASE 命令：

CONNECT TO DB test1 USER user1

为了建立那样的连接，客户机必须已经被配置为连接到 server1。关于如何配置远程客户机连接的信息，请参考本系列中的第一篇教程。

在建立连接之后，主服务器上的备用服务器信息被获取并存储在客户机的数据库目录中：

 Database alias                       = TEST1
 Database name                        = TEST1
 Node name                            = server1
 Database release level               = b.00
 Comment                              =
 Directory entry type                 = Remote
 Catalog database partition number    = -1
 Alternate server hostname            = server2.torolab.ibm.com
 Alternate server port number         = 50000

确保该连接已成功建立，并且可以查询 TEST1 数据库。在 server1 上发出一条 LIST APPLICATION 命令，它应该显示数据库 TEST1 上的远程客户机连接：

D:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      8          9.26.94.149.24336.060601000305
                                                         TEST1    1

接着，在 TEST1 数据库上执行接管。在备用服务器 server2 上发出以下命令：

TAKEOVER HADR ON DB test1

让我们看看这次接管完成后远程客户机连接有什么变化。

再次尝试从客户机查询 TEST1 数据库。对 TEST1 数据库的任何查询应该都会返回一个错误消息。例如，从客户机连接发出一条 LIST TABLES 命令：

D:\Programs\IBM\SQLLIB\BIN>db2 list tables
SQL30108N A connection failed but has been re-established. 
The hostname or IP address is "server2" and the service name or port number is "50000". 
Special registers may or may not be re-attempted (Reason code = "1").  
SQLSTATE=08506

这证明客户机重路由特性在起作用。现在您已经连接到新的主服务器，即 server2。

在 server2 上发出一条 LIST APPLICATIONS 命令。您可以看到，远程客户机连接已经被重新路由到那里：

H:\Programs\IBM\SQLLIB\BIN>db2 list applications

Auth Id  Application    Appl.      Application Id        DB       # of
         Name           Handle                           Name     Agents
-------- -------------- ---------- ---------------       -----    ------
USER1    db2bp.exe      55         9.26.94.149.29200.060601001803
                                                         TEST1    1

如果再次查询数据库，那么可以从新的主服务器得到一个响应。而且，到原来主服务器的新连接也被重新路由到新的主服务器。

使用 GET SNAPSHOT 命令可以获得数据库的 HADR 状态。在 server2 上发出以下命令，应该可以看到 server2 已经接管了主数据库角色：

db2 "get snapshot for database on test1"

  HADR Status
  Role                   = Primary
  State                  = Peer
  Synchronization mode   = Nearsync
  Connection status      = Connected , 05/31/2006 20:17:24.989618
  Heartbeats missed      = 0
  Local host             = server2.torolab.ibm.com
  Local service          = 80000
  Remote host            = server1.torolab.ibm.com
  Remote service         = 70000
  Remote instance        = db2inst1
  timeout(seconds)       = 120
  Primary log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Standby log position(file, page, LSN) = S0000007.LOG, 66, 0000000002FE2D9B
  Log gap running average(bytes) = 0

在执行接管操作之后，如果出故障的数据库又可以使用，它不会自动恢复主数据库的角色。

通过以下步骤可以使之重新成为主数据库：

修复原来的主数据库所在的系统。这包括修复有问题的硬件或者重新启动崩溃的操作系统。
重新启动出故障的主数据库，使之成为一个备用数据库。
执行一个接管操作，使之接管主数据库的角色。

当原来的主数据库重新以备用数据库的角色加入 HADR 对之后，执行一个接管操作来切换数据库的角色，使原来的主数据库再次成为主数据库。

为了停止 TEST1 数据库上的 HADR，发出：

STOP HADR ON DB test1

您可以看到，HADR 是实现高可用性解决方案的一个强大的特性。提供了一个名为 HADR 向导的图形化用户界面工具，以帮助您设置和配置 HADR。

如果选择 Set Up，那么就会打开一个如图 15 所示的逐步向导。

如果使用 Control Center 设置 HADR 环境，则会自动启用自动客户机重路由特性。

阅读(23787) | 评论(0) | 转发(0) |

上一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（4）

下一篇：DB2 9数据库管理（731考试）认证指南，第7部分: 高可用性：镜像分割与高可用性灾难恢复（6）

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

16024965号-6