IBM WebSphere 开发者技术期刊: 使用 WebSphere 中间件构建高可用性数据库环境,第 1 部分

结合使用 DB2 高可用性灾难恢复功能和 WebSphere Application Server

利用 IBM® DB2® 高可用性灾难恢复 (HADR) 和自动客户端重新路由功能,可以将其客户端应用程序从发生故障的数据库服务器中恢复过来,并且可以最大限度地减少中断时间。本文向您介绍使用 IBM WebSphere® Application Server Network Deployment V6.1 作为客户端应用程序并利用 DB2 HADR 和自动客户端重新路由功能构建高可用性数据库环境的步骤。

Li-Fang Lee (lifang@us.ibm.com), 顾问软件工程师, EMC

Li-Fang Lee 是一名测试策略专家,供职于明尼苏达州罗彻斯特市的 WebSphere Test & Quality Organization。她目前关注的领域是高可用性,了解客户的业务需求,设计整个组织范围内类似于客户的测试场景,并领导团队实施测试场景,以确保 WebSphere Application Server 的高可用性。



Wayne Rosario (rwayne@us.ibm.com), 软件工程师, EMC

Wayne Rosario 是 IBM 在明尼苏达州罗彻斯特市的软件工程师。Wayne 目前正在致力于 WebSphere Application Server 的系统验证测试,而且已有三年多的测试经验。



Soloman Barghouthi (soloman@us.ibm.com), 顾问软件工程师, EMC

Soloman Barghouthi 是 IBM Rochester Lab 的软件工程师。Soloman 是作为 San Francisco 项目的开发人员开始他在 IBM 的工作生涯的,目前他是 WebSphere Application Server Relational Resource Adapter (RRA) 架构师,并且是 Scheduler、AsynchBean 和 ObjectPool 组件的团队负责人。Soloman 是一位数据库专家和 WebSphere Application Server/Oracle 驻外人员。Soloman 负责研究传统数据库如何与 WebSphere Application Server 进行交互。



2007 年 6 月 18 日

摘自 IBM WebSphere 开发者技术期刊

引言

IBM DB2 Universal Database (UDB) Enterprise Server Edition V8.2 引入了一种新的称为高可用性灾难恢复 (HADR) 的高可用性功能,它通过将数据从主要数据库复制到备用数据库为其客户端应用程序提供了一种故障转移功能。这使得客户端应用程序可以方便地从部分或完全灾难中恢复过来。另外,DB2 HADR 还与自动客户端路由 (ACR) 功能相关联,使灾难恢复行为对其客户端应用程序实际上是透明的。

例如,IBM WebSphere Application Server Network Deployment (ND) V6.1 使用 DB2 来存储其应用程序的持久性数据。WebSphere Application Server 应用程序只需要与主要数据库进行连接即可。为了在备用服务器上保持数据库的一个同步副本,系统会一致地将 DB2 HADR 日志文件从主要服务器发送到备用服务器来保持二者的同步。当主要服务器脱机时(计划内或计划外停机),备用服务器将联机代替其工作。在启用自动客户端重新路由功能时,DB2 重新路由逻辑将检查是否可以找到备用服务器。如果可以找到,重新路由功能将首先重新尝试连接失败的主要服务器,如果该操作失败,重新路由将尝试连接替代的备用服务器。这时,WebSphere Application Server 就会与备用服务器重新建立连接,并将回滚事务,然后在备用服务器上重新发布。整个 DB2 HADR 故障转移过程对 WebSphere Application Server ND 应用程序是透明的。

DB2 HADR 和自动客户端重新路由功能使得其客户端应用程序可以从发生故障的数据库服务器中恢复过来,最大限度地减少了中断时间。本文介绍使用 WebSphere Application Server ND V6.1 作为客户端应用程序并利用 DB2 HADR 和自动客户端重新路由功能构建高可用性数据库环境的步骤。

本文假定您熟悉 IBM WebSphere Application Server Network Deployment V6.x 和 DB2 Universal Database (UDB) Enterprise Server 的基本概念和设置。


DB2 HADR 准备工作

DB2 HADR 要求

在将 DB2 和 HADR 用作 WebSphere Application Server 应用程序数据存储库之前,您需要了解对主要 DB2 服务器和备用 DB2 服务器的下列基本要求:

  • 需要完全相同的操作系统和 DB2 版本。
  • 必须使用相同的容器文件系统和安装路径,例如 /home/db2inst1/sqllib。
  • 如果通过引用方式使用 HADR 功能,则需要指定 HADR 的通信端口:
    • 对于 UNIX® 或 Linux®:/etc/services
    • 对于 Windows®:c:\windows\system32\drivers\etc\services
  • 主要服务器和客户端应用程序应能够通过 TCP/IP 连接到备用服务器计算机。

DB2 HADR 设置

现在我们将了解,在设置 DB2 HADR 主要服务器和备用服务器时都涉及哪些内容:

  1. 在主要计算机和备用计算机上安装 DB2 UDB Enterprise Server Edition。在两台计算机上都启动 DB2 服务器,如果尚未运行,则在主要计算机上创建数据库和所需的表。为了便于说明,我们将使用“Sample”作为数据库名称。(有关详细的安装信息,请参见 DB2 信息中心。)

  2. 接下来,为主要计算机和备用计算机上的每个数据库确定 TCP/IP 连接通信端口(按照常规的客户端/服务器数据库连接)。端口名是用户定义的,端口号可以是任意数字,只要没有冲突就行。不要求主要服务器和备用服务器上的端口相同;不过,如果保持这两台计算机上的端口相同,则配置起来将会非常方便。对于 Sample 数据库,我们在主要服务器和备用服务器上使用了两个端口(51012 和 51013):

    清单 1. 用于“Sample”数据库的两个 HADR 端口
    >more /etc/services 
    
    # HADR ports assigned by user
    ha_sample      51012/tcp
    ha_sample_int  51013/tcp

    您需要编辑 /etc/services 文件 (UNIX/Linux) 或 c:\windows\system32\drivers\etc\services (Windows) 来指定端口。(注意,只有管理员帐户才能够编辑这些文件。)

  3. 为主要计算机上的每个数据库配置 HADR 变量。(此处显示的步骤仅适用于主要计算机。)必须对每个数据库重复此过程。在设置这些变量时,请验证 hard_local_host 和 hard_remote_host 变量是否引用了正确的计算机。而且,hadr_local_svc 和 hadr_remote_svc 变量必须与上述 /etc/services 文件中定义的名称相匹配。下面我们以“Sample”数据库为例进行说明:

    清单 2. Sample 数据库的 HADR 变量
    >db2 update db cfg for Sample using hadr_local_host    
      <primary machine IP address>
    >db2 update db cfg for Sample using hadr_remote_host   
      <standby machine IP address>
    >db2 update db cfg for Sample using hadr_local_svc     ha_sample
    >db2 update db cfg for Sample using hadr_remote_svc    ha_sample_int
    >db2 update db cfg for Sample using hadr_remote_inst   
      <DB2 instance name on the standby>
    >db2 update db cfg for Sample using hadr_timeout       120
    >db2 update db cfg for Sample using hadr_syncmode      nearsync
    >db2 update db cfg for Sample using logretain 	  on
    >db2 update db cfg for Sample using LOGINDEXBUILD 	  on
    >db2 update alternate server for database Sample using hostname 
      <Standby IP address>
    port 60000

    上例中,NEARSYNC 被选为同步模式。此模式虽然比 SYNC 模式提供较少的事务丢失保护,但比 SYNC 模式的事务响应时间要短一些。注意,清单 2 中的最后命令可以为 DB2 HADR 启用自动客户端重新路由功能,并且端口 60000 是备用计算机上的 DB2 实例端口号。

  4. 请通过输入此命令来验证您的配置值,如清单 3 所示:

    db2 get db cfg for <database_name> | grep HADR

    清单 3. 主要计算机上 Sample 数据库的 HADR 配置
    >db2 get db cfg for  sample  | grep HADR
    
    HADR database role                                 = STANDARD
    HADR local host name             (HADR_LOCAL_HOST) = svtlewis.rchland.ibm.com
    HADR local service name           (HADR_LOCAL_SVC) = ha_sample
    HADR remote host name           (HADR_REMOTE_HOST) = svtclark.rchland.ibm.com
    HADR remote service name         (HADR_REMOTE_SVC) = ha_sample_int
    HADR instance name of remote server  (HADR_REMOTE_INST) = db2inst1
    HADR timeout value                       (HADR_TIMEOUT) = 120
    HADR log write synchronization mode     (HADR_SYNCMODE) = NEARSYNC
  5. 现在,我们可以从主要计算机上备份数据库,并将其还原到备用计算机上。下面的命令将备份主要计算机上的数据库(如清单 4 中所示。)您需要对每个数据库重复此命令。请注意,您无法对正在连接其客户端应用程序的数据库执行备份。

    cd <temp_backup_directory>
    db2 backup db <database_name>

    每个数据库的备份副本将存储在 <temp_backup_directory> 中。

    清单 4. 主要计算机上的备份数据库
    >cd tmpdir
    >db2 backup db sample
    
    Backup successful. The timestamp for this backup image is :20061101161943

    将主要机计算机上生成的备份文件传输到备用计算机。要将数据库还原到备用计算机,请使用您的 DB2 用户 ID 登录到备用计算机。下面的命令将把数据库还原到备用计算机上(清单 5)。您需要对每个数据库重复此命令:

    db2 restore db <database_name> from <temp_restore_directory> replace history file

    清单 5. 将数据库还原到备用计算机上
    >cd tmpdir
    >db2 restore db sample replace history file
              
    DB20000I  The RESTORE DATABASE command completed successfully.
  6. 在将所有数据库还原到备用计算机上之后,必须将清单 6 中所示的用于各个数据库的所有 DB2 HADR 变量从主要 DB2 服务器复制到备用服务器。从备用 DB2 服务器的角度看,主要 DB2 服务器就是远程主机。因此,您需要修改备用计算机上的 hadr_local_host、hadr_remote_host、hadr_local_svc 和 hadr_remote_svc 值。另外,必须更新自动客户端重新路由,以指向主要计算机。

    请注意,端口 60000 是主要计算机上的 DB2 实例端口号。

    清单 6. 备用计算机上 Sample 数据库的 HADR 变量
    >db2 update db cfg for Sample using hadr_local_host     <standby machine IP address>
    >db2 update db cfg for Sample using hadr_remote_host    <primary machine IP address>
    >db2 update db cfg for Sample using hadr_local_svc      ha_sample_int
    >db2 update db cfg for Sample using hadr_remote_svc     ha_sample
    
    >db2 update alternate server for database Sample using hostname <Primary machine IP 
    address> port 60000
  7. 在主要计算机或备用计算机上启动 DB2 HADR 之前,正确设置所有 HADR 参数的值非常重要。如果这些参数中任何一个参数为空或者配置不正确,DB2 HADR 服务器都不会正常启动。另外,还需要先在备用计算机上启动 DB2 HADR,然后才可以在主要计算机上启动它。

    在备用计算机上,首先禁用数据库,然后发出 start hadr 命令,将其作为备用数据库启动(清单 7)。

    db2 deactivate db <database_name>
    db2 start hadr on db <database_name> as standby

    清单 7. 禁用 Sample 并将其作为备用数据库启动
    >db2 deactivate db sample
    >db2 start hadr on db sample as standby
         
         DB20000I  The START HADR  ON DATABASE command completed successfully
    
    >db2 get snapshot for db on sample  | grep Role
    
         Role                   = Standby

    在主要计算机上,首先激活数据库,然后发出 start hadr 命令将其作为主要数据库启动(清单 8)。

    db2 activate db <database_name>
    db2 start hadr on db <database_name> as primary
    清单 8. 激活 Sample 并将其作为主要数据库启动
    > db2 activate db sample
    > db2 start hadr on db sample as primary    
     
        DB20000I  The START HADR  ON DATABASE command completed successfully 
    
    > db2 get snapshot for db on sample | grep Role
    
        Role                   = Primary
  8. 在启动 DB2 HADR 服务器时,您会收到一条指示“START HADR ON DATABASE command completed successfully”的消息。为确保 HADR 服务器在主要计算机和备用计算机上使用了正确的角色运行,您可以向主要计算机和备用计算机发出以下命令进行验证:

    db2 get snapshot for db on <database_name> | grep Role

    在 HADR 状态角色下,您将看到用于备用计算机的“Standby”状态和用于主要计算机的“Primary”状态。如果得不到每个数据库的正确标识符,则需要检查前面的所有步骤。

  9. 在备用计算机和主要计算机上的数据库成功启动后,您需要确保两个数据库处于同步状态。否则,故障转移将无法成功进行,从而会导致发生不希望的结果,如数据丢失。发出以下命令,以检查主要和备用数据库计算机上两个数据库的状态:

    db2 get snapshot for database on <database_name> | grep State

    您需要等待备用数据库连接到主要数据库之后,才能使两个数据库处于对等模式。在数据库处于对等模式之后,主要计算机和备用计算机上的 DB2 HADR 服务器就准备就绪可供使用了。


在运行 DB2 HADR 时 DB2 Universal JDBC Driver 的行为

尽管 DB2 JDBC Universal Driver 将透明地连接到适当的数据库服务器(即主要服务器对应于备用服务器),但是,如果比较 DB2 Universal JDBC Driver Type2 和 Driver Type4,仍存在一些差异和限制:

  • DB2 Universal Driver Type2

    在首次成功连接到 DB2 数据库之后,DB2 将使用备用服务器信息更新 JDBC 驱动程序。备用服务器信息然后存储在 JDBC 驱动程序一端的内存和 DB2 数据库目录中(持久存储在磁盘上)。如果到主要 DB2 服务器的连接失败,DB2 将从内存中(如果在内存中找不到备用服务器信息,则从 DB2 持久性副本中)检索备用服务器信息。然后,DB2 驱动程序将使用该备用服务器信息连接到正确的 DB2 服务器。整个过程对用户而言是透明的。

  • DB2 Universal Driver Type4

    在首次成功连接到 DB2 数据库之后,DB2 还将使用备用服务器信息更新 JDBC 驱动程序。不过,备用服务器信息将仅存储在 JDBC 驱动程序端的内存中。如果到主要 DB2 服务器的连接失败,DB2 将从内存中检索备用服务器信息,并将使用该备用服务器信息连接到正确的 DB2 服务器。整个过程对用户而言是透明的。

事实上,Type4 仅更新内存中的信息,并不将其保留在 DB2 持久性副本中(而在 Type2 中则保留),这样,在客户端 JVM(例如,WebSphere Application Server)停机(正常停机或者非正常停机)时,会导致备用服务器信息丢失。有关在使用 DB2 Universal JDBC Driver Type4 时如何保留 HADR 备用服务器信息的更详细信息,请参阅附录


配置 WebSphere Application Server

在 WebSphere Application Server ND 中定义数据源应该非常简单,因为设置与启用 HADR 的 DB2 服务器的连接没有特殊要求。可以将 DB2 数据源配置为 Type2 或 Type4,以连接到 DB2。对于 DB2 服务器名称,只需要输入主要 DB2 服务器计算机。WebSphere Application Server 不需要知道有关备用计算机的任何信息,因为在 DB2 服务器端支持高可用性和客户端重新路由功能。所以,定义 DB2 数据源的方式与没有使用 HADR 时毫无二致。

下面是在 WebSphere Application Server ND 上配置 DB2 HADR 连接的一个示例:

  1. 创建 DB2 Universal JDBC Driver 提供程序。
  2. 通过选择 JDBC providers => DB2 Universal JDBC Driver Provider => Data sources => <DataSource_Name> 新建一个 data_source。仅使用主要 DB2 计算机的所有信息创建数据源(图 1)。

在测试 DB2 HADR 接管行为之前,您需要验证 WebSphere Application Server 和 DB2 HADR 主要计算机之间的连接是否正常。

图 1. WebSphere Application Server 控制台上的数据源配置
图 1. WebSphere Application Server 控制台上的数据源配置

在缺省情况下,DB2 自动客户端重新路由功能每 10 分钟重新尝试建立到数据库的连接。不过,可以配置精确的重试行为。利用 DB2 Universal JDBC Driver 的 Type4 连接的用户可以使用以下 JDBC 自定义属性执行此操作:

  • maxRetriesForClientReroute:使用此属性可以限制到服务器的主要连接失败的重试次数。此属性仅在同时设置了 retryIntervalClientReroute 属性时才能使用。
  • retryIntervalForClientReroute:使用此属性可以指定两次重试之间的时间间隔(以秒为单位)。此属性仅在同时设置了 maxRetriesForClientReroute 属性时才能使用。

通过限制自动重新路由之间的尝试间隔,这些属性可以提供更快的响应时间,并在无法重新路由的情况下,更快地返回应用程序的错误。

从 WebSphere Application Server 管理控制台执行以下操作:

  1. 要配置资源,请导航到 JDBC providers => DB2 Universal JDBC Driver Provider => Data sources => <DataSource_Name> => Custom properties
  2. 选择 New 并添加下列自定义属性:
    • maxRetriesForClientReroute: 2
    • retryIntervalForClientReroute: 15
  3. 单击 Apply 并保存您的配置。

在上面的示例中,将重新路由之间的尝试间隔限制为每 15 秒进行 2 次。图 2 显示了如何设置这些属性:设置的实际值取决于您环境中的硬件和拓扑。

图 2. 添加数据源配置的自定义属性
图 2. 添加数据源配置的自定义属性

请参阅 DB2 文档中有关自动客户端重新路由配置的说明,了解等效的 DB2 注册表变量和其他详细信息。


HADR 接管

在将 WebSphere Application Server 应用程序连接到 DB2 HADR 主要计算机后,就可以着手验证 HADR 故障转移行为了。向备用服务器发出以下命令,以便发生 DB2 HADR 接管(清单 9)。

db2 takeover hadr on db <database_name>

较好的做法是,在接管之后检查备用计算机上的数据库是否具有“主要角色”。

db2 get snapshot for db on <database name> | grep Role

清单 9. 备用计算机上的数据库接管
> db2 takeover hadr on db sample

    DB20000I The TAKEOVER HADR ON DATABASE command completed successfully.

在接管之后,WebSphere Application Server 需要建立新连接才能访问备用计算机上的数据库。您将在 SystemOut.log 文件中看到以下日志消息(清单 10),指示应用程序首先尝试连接主要计算机,然后重新尝试连接备用计算机。在应用程序重新尝试连接之后,它应获得一个到备用数据库的新连接。

清单 10. WebSphere Application Server SystemOut.log
[11/1/06 17:15:39:298 CST] 00000039 ServletWrappe E   SRVE0068E: Uncaught exception 
thrown in one of the service methods of the servlet: /dbview.jsp. Exceptionthrown : 
javax.servlet.ServletException: A connection failed but has been re-established. The 
hostname or IP address is "svtlewis.rchland.ibm.com" and the service name 
or port number is 60000 . Special registers may or may not be re-attempted (Reason 
code = 1  DB2ConnectionCorrelator: G9056D89.O37F.061101231714

还可能出现其他类型的失败情形,这时必须强制执行数据库接管才能使 WebSphere Application Server 和 DB2 HADR 之间的连接正常工作。下面是一些示例情形,您可以检查它们之间的不同之处。

情形 1

主要计算机在网络中不可用。备用计算机上的状态变为“Remote catchup pending”(清单 11),这意味着备用计算机失去了到主要计算机的连接。

清单 11. 备用计算机上的“Remote catchup pending”状态
> db2 get snapshot for database on sample | grep State

 State                  = Remote catchup pending

在此情况下,WebSphere Application Server 与 DB2 UDB 的连接将超时。故障转移不会自动发生,原因是 WebSphere Application Server 仍然存在与主要数据库的连接。因此,必须在备用计算机上执行如下所示的“takeover by force”命令。在接管发生之后,WebSphere Application Server 将建立到备用数据库的新连接。

db2 takeover hard on db <database name> by force

备用计算机的状态将暂时变为“Disconnected”,因为发生接管时在网络中找不到主要计算机(清单 12)。

清单 12. 在备用计算机上强制执行数据库接管
> db2 takeover hadr on db Sample by force
     
     DB20000I  The TAKEOVER HADR ON DATABASE command completed successfully.

> db2 get snapshot for database on sample | grep Role

     Role    = Primary

> db2 get snapshot for database on sample | grep State

     State   = Disconnected

情形 2

常规 DB2 数据库用作 WebSphere Application Server 应用程序数据存储库。您将 JDBC 提供程序配置为从应用程序连接到数据库。后来,决定将数据库切换到启用 HADR 的 DB2。在设置 HADR 并启动数据库服务器之后,应用程序首次尝试连接到主要 HADR 数据库时,它将在 SystemOut.log 中记录以下消息:

清单 13. WebSphere Application Sever SystemOut.log
[10/27/06 0:26:27:796 CDT] 0000002b WebApp  E   [Servlet Error]-[/dbview.j
sp]: com.ibm.websphere.ce.cm.StaleConnectionException: A connection failed but has been 
re-established. The hostname or IP address is "svtlewis.rchland.ibm.com" and 
the service name or port number is 60000. Special registers may or may not be re-attempted
(Reason code = 1 DB2ConnectionCorrelator: G9056D89.A7AD.061027052803...)

在应用程序重新尝试连接数据库时,它将会成功连接。

情形 3

在主要计算机脱机时,不断通过 WebSphere Application Server 发出访问备用数据库的请求。备用数据库上的数据可能根据客户端请求进行了修改。因此,当主要计算机重新联机之后,主要计算机和备用计算机上的数据库可能会失去同步。在此情况下,您需要将主要计算机上的数据库作为备用数据库启动,以便这两个数据库重新保持同步。

由于两个数据库失去同步,HADR 将自动通过更改状态(从 S-RemoteCatchup 更改为 S-NearlyPeer,最后更改为 S-Peer)保持这两个数据库同步。db2diag.log 文件中记录的以下消息显示了在数据库同步操作过程中状态的更改。

清单 14. db2diag.log 文件中记录的状态更改
2006-11-01-17.06.15.113214-360 I383930C400        LEVEL: Warning
PID     : 4021                 TID  : 4160127008  PROC : db2agent (SAMPLE) 0
INSTANCE: db2inst1             NODE : 000         DB   : SAMPLE
APPHDL  : 0-8                  APPID: *LOCAL.db2inst1.061101230614
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrEduStartup, probe:211
52
MESSAGE : Info: HADR Startup has completed.

2006-11-01-17.06.15.669454-360 E384331C363        LEVEL: Event
PID     : 4032                 TID  : 4160127008  PROC : db2hadrs (SAMPLE) 0
INSTANCE: db2inst1             NODE : 000         DB   : SAMPLE
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrSetHdrState, probe:10
000
CHANGE  : HADR state set to S-RemoteCatchup (was S-RemoteCatchupPending)

2006-11-01-17.06.16.145289-360 E385032C353        LEVEL: Event
PID     : 4032                 TID  : 4160127008  PROC : db2hadrs (SAMPLE) 0
INSTANCE: db2inst1             NODE : 000         DB   : SAMPLE
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrSetHdrState, probe:10
000
CHANGE  : HADR state set to S-NearlyPeer (was S-RemoteCatchup)

2006-11-01-17.06.16.240636-360 E385386C344        LEVEL: Event
PID     : 4032                 TID  : 4160127008  PROC : db2hadrs (SAMPLE) 0
INSTANCE: db2inst1             NODE : 000         DB   : SAMPLE
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrSetHdrState, probe:10
000
CHANGE  : HADR state set to S-Peer (was S-NearlyPeer)

情形 4

在 WebSphere Application Server 不主动服务于客户端时,为避免计划的接管事务失败,或者在 WebSphere Application Server 主动服务于客户端时,为减少计划的接管事务失败,您可以首先清除连接池,然后发出接管命令并再次清除连接池(在应用服务器主动服务于客户端时)。例如,假设计划在晚上关闭主要计算机。第二天,即使在数据库端已经完成从主要计算机到备用计算机的接管,如果不先清除连接池就开始客户端请求,也会导致客户端请求使用 WebSphere Application Server 连接池的无效连接(假设这些连接没有超时)。因此,在连接池清除本身的无效连接之前,请求将会失败。所以,最好手动清除连接池,以避免发生这种情况。

要清除 WebSphere Application Server 的连接池,请转到部署管理器 bin 目录,并对每个应用服务器发出以下命令(有关详细信息,请参阅 WebSphere connection pool can be purged using MBeans 技术说明):

./wsadmin.sh
set ds [$AdminControl queryNames type=DataSource, name=<ds_name>]
$AdminControl invoke $ds purgePoolContents

清单 15. 清除 server2 的数据库连接池
>./wsadmin.sh

>set ds [$AdminControl queryNames type=DataSource,name=myDS,process=server2,*]

>$AdminControl invoke $ds purgePoolContents

还可以使用一个命令清除 WebSphere Application Server 中的所有池:

清单 16. 清除所有池
>./wsadmin.sh

>set mbeans [$AdminControl queryNames type=DataSource,*]  
foreach mbean $mbeans {  
>$AdminControl invoke $mbean purgePoolContents
}

然后可以向备用计算机发出接管命令。由于已经清除主要计算机上的连接池,并发出了接管命令,因此,所有客户端请求将自动定向到备用计算机,而不会在 SystemOut.log 中记录许多失败消息(清单 13)。注意,如果 WebSphere Application Server 在主动服务于客户端时发生接管,仍存在一个较短的时段,即在清除池和完成接管之前打开一些连接。


退回主要计算机

在退回主要计算机之前,需要确保已在主要计算机上成功启动了 DB2 UDB 服务器,然后在主要计算机上发出以下命令,以便从备用计算机接管数据库。

db2 takeover hadr on db <database name>

仔细检查主要计算机上的数据库是否具有正确的角色:

db2 get snapshot for database on <database name> | grep Role

它会返回“Primary”状态。而且,备用计算机和主要计算机上数据库的状态现在都应该处于“Peer”状态。


故障排除

作为参考,下面列出了在使用 DB2 HADR 时可能遇到的问题的原因和解决办法:

  • SQL1768N 无法启动 HADR。原因代码 =“7”(在启动主要数据库或备用数据库时)。

    此问题的可能原因是,在 HADR 超时间隔内主要数据库无法建立与其备用数据库的连接。您可以通过调整时间间隔来适应您的环境。

  • SQL1768N 无法启动 HADR。原因代码 =“8”(在启动主要数据库或备用数据库时)。

    检查下面所需的 HADR 变量(参见清单 3)这些变量必须正确而且不能为空:

    • HADR 数据库角色
    • HADR 本地主机名称
    • HADR 远程主机名称
    • HADR 远程服务名称
    • 远程服务器的 HADR 实例名称
    • HADR 超时值
    • HADR 日志写入同步模式
  • SQL1768N 无法启动 HADR。原因代码 =“99”(在启动主要数据库或备用数据库时)。

    在 /etc/services 文件中检查用于每个数据库的 HADR 端口和名称。它们应具有相同的 hadr_remote_svc 和 hard_local_svc 设置(如上文所述)。

  • SQL1769N 停止 HADR 无法完成。原因代码 =“2”(在停止主要数据库或备用数据库时)。

    在此情况下,您可以先禁用数据库,然后再停止 HADR:

    db2 deactivate db <database_name>
    db2 stop hadr on db <database_name>

  • SQL30081N 在主要计算机或备用计算机上启动 HADR 时检测到通信错误。

    检查关键参数,确保这些参数在所有 DB2 UDB 服务器计算机上的配置都正确。使用 DB2 UDB 用户帐户登录到数据库计算机(例如:db2inst1),然后在用户提示符处键入下列命令:

    db2start (if DB2 is not running)
    db2set DB2COMM=TCPIP
    db2set DB2AUTOSTART=YES
    db2 update dbm cfg using SVCENAME DB2_db2inst1
    db2stop
    db2start

    (SVCENAME 是您的配置中 TCP/IP 服务的名称,位于 /etc/services 文件中。)

  • SQL2406N 由于数据库需要前滚,无法执行备份。SQLSTATE=57019(在备份数据库时)。

    您需要使用此命令前滚数据库(请参阅清单 17)。

    db2 rollforward db <database_name> to end of logs and stop

    清单 17. 数据库前滚
    >db2 rollforward db sample to end of logs and stop
    
      Rollforward Status
    
     Input database alias                   = sample
     Number of nodes have returned status   = 1
    
     Node number                            = 0
     Rollforward status                     = not pending
     Next log file to be read               =
     Log files processed                    = S0000000.LOG - S0000006.LOG
     Last committed transaction             = 2006-10-06-16.22.35.000000
    
           DB20000I  The ROLLFORWARD command completed successfully
  • 接管在主要计算机或备用计算机上不能正常运行。您可以强制发出接管命令:

    db2 takeover hard on db <database_name> by force


结束语

DB2 Universal Database (UDB) 高可用性灾难恢复 (HADR) 为其客户端应用程序提供了一种高可用性解决方案。作为客户端应用程序,WebSphere Application Server 能够区分数据库失败和接管情况。当 DB2 HADR 接管发生时,WebSphere Application Server 将利用 DB2 自动客户端重新路由功能自动重新建立与备用 HADR 服务器的连接。

本文使用 WebSphere Application Server Network Deployment V6.1 和 DB2 UDB HADR 演示了在这两种产品之间是如何发生接管的。您已经了解到启用 DB2 和 HADR 以及配置 WebSphere Application Server ND 以便连接到 DB2 HADR 的步骤。还学习了有关接管的行为以及接管过程中在 WebSphere Application Server 日志文件中记录的预期消息。另外,还向您介绍了有关若干常见错误情况的一些疑难解答提示和技巧。

在 WebSphere Application Server 上不需要任何额外配置步骤即可成功进行 HADR 故障转移。WebSphere Application Server 利用了 DB2 UDB HADR 提供的技术和自动客户端重新路由功能为您的应用程序提供了高可用性环境。

本系列文章的第 2 部分将重点介绍如何使用 Oracle® Real Application Cluster 和 WebSphere Process Server 获得高可用性数据库。


附录

在使用 DB2 Universal JDBC Driver Type4 时保留 HADR 备用服务器信息:

  1. 在 WebSphere Application Server 管理控制台中使用下列值添加新的 DataSource 自定义属性:

    • 名称: clientRerouteServerListJNDIName
    • 类型: java.lang.String
    • 值: cell/persistent/alSrvlist

    clientRerouteServerListJNDIName 的值前面必须有 cell/persistent/。否则,JNDI 对象将不会保留在 WebSphere Application Server 中。此处的值应与传递到 T4CRBind.java 文件中的 JNDI 名称匹配(参见清单 18)。保存并同步您的整个计算单元。

  2. 复制清单 17 中的程序,并使用 db2jcc.jar 文件进行编译。从 WAS_HOME/bin 目录执行以下编译命令,然后将 T4CRBind 类放入 WAS_HOME/bin 目录:

    javac -classpath /home/db2inst1/sqllib/java/db2jcc.jar:$CLASSPATH T4CRBind.java

  3. 创建一个可以启动 T4CRBind 类的启动程序,如清单 19 所示。

  4. 重新启动运行您的应用程序的 WebSphere Application Server,并从 WAS_HOME/bin 目录启动启动程序。可以通过执行以下命令启动该程序:

    launchT4CRBind.sh T4CRBind

    在运行此命令之前,请确保您的整个计算单元正在运行。这包括部署管理器、节点代理和应用服务器。

    请注意,当启用 WebSphere Application Server 全局安全时,下面的程序可能无法运行。如果全局安全是必需的,请打开一个支持 WebSphere Application Server 的票证获取一个修补程序,以便该程序在启用全局安全的情况下能够正常运行。

    清单 18. T4CRBind.java
    import javax.naming.InitialContext;
    import com.ibm.db2.jcc.DB2ClientRerouteServerList;
    
    public class T4CRBind
    {
    
        public static void main(String[] args)
        {
    	try
    	{
    		InitialContext registry = new InitialContext();
    
    		DB2ClientRerouteServerList address = new DB2ClientRerouteServerList();
    
    		int[] alternateServerPorts =
    		{ 60000 };
    		String[] alternateServerHosts =
    		{ "svtclark.rchland.ibm.com" };
    
    		address.setPrimaryPortNumber(60000);
    		address.setPrimaryServerName("svtlewis.rchland.ibm.com");
    
    		address.setAlternatePortNumber(alternateServerPorts);
    		address.setAlternateServerName(alternateServerHosts);
    
    		registry.unbind("cell/persistent/alSrvlist");
    		registry.rebind("cell/persistent/alSrvlist", address);
    
    		System.out.println("JNDI Registration done....");
    	}
    	catch (Exception e)
    	{
    		e.printStackTrace();
    	}
        }
    }
    清单 19. launchT4CRBind.sh
    #!/bin/sh
    
    binDir=`dirname $0`
    . "$binDir/setupCmdLine.sh"
    
    CMD_NAME=`basename $0`
    
    if [ -f ${JAVA_HOME}/bin/java ]; then
        JAVA_EXE="${JAVA_HOME}/bin/java"
    else
        JAVA_EXE="${JAVA_HOME}/jre/bin/java"
    fi
    
    DB2JCC_HOME="/home/db2inst1/sqllib/java/db2jcc.jar"
    export DB2JCC_HOME
    
    
    CLASSPATH=".:$DB2JCC_HOME:$WAS_CLASSPATH"
    export CLASSPATH
    
    # In the case where more than one application server is installed, you will 
    # need to run the synch to make sure that the name space of the entire cell 
    # is updated.  Also, if the port for the naming space is not the default, then
    # you will need to specify the –Djava.naming.provider.url= <specify the url
    # here>
    
    
    "$JAVA_HOME/bin/java" \
      "-Dwas.install.root=$WAS_HOME" \
       -classpath "$CLASSPATH" com.ibm.ws.bootstrap.WSLauncher "$@"
    exit 0

参考资料

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere, Information Management
ArticleID=231489
ArticleTitle=IBM WebSphere 开发者技术期刊: 使用 WebSphere 中间件构建高可用性数据库环境,第 1 部分
publish-date=06182007