商讯信箱
用户名: @
密  码:   注册|忘记密码
登录
个人用户经销商
您的位置:首页 > 技术频道 > 正文

使用WebSphere中间件构建数据库环境

    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 在主动服务于客户端时发生接管,仍存在一个较短的时段,即在清除池和完成接管之前打开一些连接。
1 2 3 4 5
【内容导航】
第1页: 引言 第2页: DB2 HADR 设置
第3页: JDBC Driver 的行为 第4页: HADR 接管
第5页: 结束语
©版权所有。未经许可,不得转载。
[责任编辑:振宇]
[an error occurred while processing this directive]