使用HADR BY FORCE切换之后的注意事项
DB2® 高可用性灾难恢复（HADR）是一种数据复制功能，它提供针对部分和整个站点故障的高可用性解决方案。HADR 通过将数据更改从源数据库（称为主数据库）复制到目标数据库（称为备用数据库）来防止数据丢失。很多客户在使用HADR期间需要强制触发HADR切换以达到测试或者实际的需求，这个时候有一些日志和使用中的事项时需要特别注意的，这也正是本文关注的重点！
注意事项:
注意TAKEOVER BY FORCE 的效果：
我们一般并不建议客户自己查看db2diag.log里面的错误信息，因为里面的信息由于技术性较强，可读性较差，所以这个诊断日志是专门给IBM技术支持人员看的。但是，好奇的朋友会在Takeover by force的过程中会在原Primary 数据库的诊断日志中发现db2loggr和db2hadrp进程分别报“ZRC=0x8610000D=-2045771763=SQLP_BADLOG”即日志损坏的错误信息：
2008-09-28-23.40.03.973763+480 I2845E358 LEVEL: Error
PID : 21458 TID : 47049341306720PROC : db2hadrp (THADR) 0
INSTANCE: e81q17b NODE : 000 DB : THADR
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrTcpIpRecv, probe:11810
MESSAGE : Zero bytes received. Remote end may have closed connection
2008-09-28-23.40.03.974060+480 I3204E419 LEVEL: Error
PID : 21458 TID : 47049341306720PROC : db2hadrp (THADR) 0
INSTANCE: e81q17b NODE : 000 DB : THADR
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrRecvMsgP, probe:30048
MESSAGE : HADR primary recv error:
DATA #1 : Hexdump, 4 bytes
0x00007FFF27DA6B8C : 0100 0000 ....
2008-09-28-23.40.03.974294+480 I3624E405 LEVEL: Severe
PID : 21458 TID : 47049341306720PROC : db2hadrp (THADR) 0
INSTANCE: e81q17b NODE : 000 DB : THADR
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrEduAcceptEvent, probe:20215
RETCODE : ZRC=0x8280001B=-2105540581=HDR_ZRC_COMM_CLOSED
"Communication with HADR partner was lost"
2008-09-28-23.40.03.974446+480 E4030E355 LEVEL: Event
PID : 21458 TID : 47049341306720PROC : db2hadrp (THADR) 0
INSTANCE: e81q17b NODE : 000 DB : THADR
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrSetHdrState, probe:10000
CHANGE : HADR state set to P-RemoteCatchupPending (was P-Peer)
2008-09-28-23.40.03.974747+480 I4386E399 LEVEL: Error
PID : 21450 TID : 47049341306720PROC : db2loggr (THADR) 0
INSTANCE: e81q17b NODE : 000 DB : THADR
FUNCTION: DB2 UDB, data protection, sqlpgsck, probe:430
RETCODE : ZRC=0x8610000D=-2045771763=SQLP_BADLOG "Log File cannot be used"
DIA8414C Logging can not continue due to an error.
2008-09-28-23.40.04.012228+480 I4786E336 LEVEL: Error
PID : 21458 TID : 47049341306720PROC : db2hadrp (THADR) 0
INSTANCE: e81q17b NODE : 000 DB : THADR
FUNCTION: DB2 UDB, data protection, sqlpgPostLoggrWithoutLatching, probe:930
MESSAGE : db2logger: rc=-2045771763 sem rc=0 type=5
2008-09-28-23.40.04.012409+480 I5123E186 LEVEL: Error
PID:21458 TID:47049341306720 NODE:000 Title: SQLP_DBCB
Dump File:/home/db2users/e81q17b/sqllib/db2dump/214582269546336.000
2008-09-28-23.40.04.012764+480 I5310E428 LEVEL: Error
PID : 21458 TID : 47049341306720PROC : db2hadrp (THADR) 0
INSTANCE: e81q17b NODE : 000 DB : THADR
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrWritePersist, probe:10440
RETCODE : ZRC=0x8610000D=-2045771763=SQLP_BADLOG "Log File cannot be used"
DIA8414C Logging can not continue due to an error.
2008-09-28-23.40.04.013322+480 I5739E427 LEVEL: Error
PID : 21458 TID : 47049341306720PROC : db2hadrp (THADR) 0
INSTANCE: e81q17b NODE : 000 DB : THADR
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrSetHdrState, probe:10010
RETCODE : ZRC=0x8610000D=-2045771763=SQLP_BADLOG "Log File cannot be used"
DIA8414C Logging can not continue due to an error.
2008-09-28-23.40.04.013432+480 I6167E426 LEVEL: Severe
PID : 21458 TID : 47049341306720PROC : db2hadrp (THADR) 0
INSTANCE: e81q17b NODE : 000 DB : THADR
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrCloseConn, probe:30570
RETCODE : ZRC=0x8610000D=-2045771763=SQLP_BADLOG "Log File cannot be used"
DIA8414C Logging can not continue due to an error.
2008-09-28-23.40.04.013547+480 I6594E358 LEVEL: Error
PID : 21458 TID : 47049341306720PROC : db2hadrp (THADR) 0
INSTANCE: e81q17b NODE : 000 DB : THADR
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrTcpIpRecv, probe:11810
MESSAGE : Zero bytes received. Remote end may have closed connection
2008-09-28-23.40.04.013624+480 I6953E419 LEVEL: Error
PID : 21458 TID : 47049341306720PROC : db2hadrp (THADR) 0
INSTANCE: e81q17b NODE : 000 DB : THADR
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrRecvMsgP, probe:30048
MESSAGE : HADR primary recv error:
DATA #1 : Hexdump, 4 bytes
0x00007FFF27DA6B8C : 0100 0000 ....
以上这些报错信息，在takeover by force过程中总是会被记录。实际上此时虽然两个数据库都可以连接，但是两个库的HADR角色均为Primary。这时实际上HADR配对已经被中止。同时，如果此时尝试停止原Primary数据库的HADR或者尝试连接原Primary数据库之后做一些需要记录日志的操作，均可能会失败：
db2 stop hadr on db thadr
SQL0980C A disk error occurred. Subsequent SQL statements cannot be
processed.
此时，任何需要记录日志的操作会导致数据库deactivate状态：
db2 "create table t1(a1 int not null)"
DB21034E The command was processed as an SQL statement because it was not a
valid Command Line Processor command. During SQL processing it returned:
SQL1034C The database is damaged. All applications processing the database
have been stopped. SQLSTATE=58031
如果再次尝试激活数据库的话，会有什么情况发生呢？没错，实际上，由于该数据库的HADR角色依然为Primary，所以在数据被激活的同时，会尝试重启HADR Primary。但是由于原先的HADR环境已经被破坏，不会再有standby加入到HADR环境，所以在停顿一段时间之后，激活数据的动作会返回：
SQL1768N Unable to start HADR. Reason code = "7".
接下来该这么办呢？如果还想使用原Primary数据库，办法就是通过 BY FORCE的方式启动原PRIMARY： db2 start hard on db as primary BY FORCE!
BY FORCE：
通知HADR Primary数据库不需要继续等待Standby数据库的加入。但是此时，当Primary接收到Standby加入的请求时，依然会做出正确的响应。
此时，如果在成功连接数据库之后，创建表就可以成功完成了！也可以停止HADR了！综上所述，请在生产环境中谨慎使用HADR TAKEOVER BY FORCE命令！
注意事项:
注意TAKEOVER BY FORCE 的效果：
| 发出切换命令时standby状态 | 是否使用By Force | 发出切换命令后的结果 |
| local catchup或remote catchup | 不使用 | 切换不成功 |
| local catchup或remote catchup | 使用 | 切换不成功 |
| peer | 不使用 | Primary与Standby数据库的角色发生改变。 如果切换过程中没有错误发生，则不会有数据丢失；如果有错误发生，有可能会有数据丢失，然而Primary和Standby数据库的角色有可能会改变，也有可能没有发生改变。当切换发生错误的时候，请采取以下步骤： 如果可能的话，请保证主备数据库均在线。通过snapshot, db2pd –hadr或者检查数据库配置参数中的“HADR database role” 如果原standby数据库的角色还是standby的话，请重新发出takeover命令 如果发现两个数据库均为standby的角色，那么只能通过takeover by force命令完成切换 |
| peer | 使用 | Standby会通知Primary令其Shutdown，同时Standby将不再从Primary处接收交易日志。根据已有的日志进行前滚并启动为Primary。发出takeover by force命令的standby不会等待primary通知它primary是否已经收到standby要takeover by force的请求或者primary是否已经shutdown |
| remote catchup pending | 使用 | 切换不成功 |
| remote catchup pending | 使用 | 切换不成功 |
2008-09-28-23.40.03.973763+480 I2845E358 LEVEL: Error
PID : 21458 TID : 47049341306720PROC : db2hadrp (THADR) 0
INSTANCE: e81q17b NODE : 000 DB : THADR
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrTcpIpRecv, probe:11810
MESSAGE : Zero bytes received. Remote end may have closed connection
2008-09-28-23.40.03.974060+480 I3204E419 LEVEL: Error
PID : 21458 TID : 47049341306720PROC : db2hadrp (THADR) 0
INSTANCE: e81q17b NODE : 000 DB : THADR
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrRecvMsgP, probe:30048
MESSAGE : HADR primary recv error:
DATA #1 : Hexdump, 4 bytes
0x00007FFF27DA6B8C : 0100 0000 ....
2008-09-28-23.40.03.974294+480 I3624E405 LEVEL: Severe
PID : 21458 TID : 47049341306720PROC : db2hadrp (THADR) 0
INSTANCE: e81q17b NODE : 000 DB : THADR
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrEduAcceptEvent, probe:20215
RETCODE : ZRC=0x8280001B=-2105540581=HDR_ZRC_COMM_CLOSED
"Communication with HADR partner was lost"
2008-09-28-23.40.03.974446+480 E4030E355 LEVEL: Event
PID : 21458 TID : 47049341306720PROC : db2hadrp (THADR) 0
INSTANCE: e81q17b NODE : 000 DB : THADR
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrSetHdrState, probe:10000
CHANGE : HADR state set to P-RemoteCatchupPending (was P-Peer)
2008-09-28-23.40.03.974747+480 I4386E399 LEVEL: Error
PID : 21450 TID : 47049341306720PROC : db2loggr (THADR) 0
INSTANCE: e81q17b NODE : 000 DB : THADR
FUNCTION: DB2 UDB, data protection, sqlpgsck, probe:430
RETCODE : ZRC=0x8610000D=-2045771763=SQLP_BADLOG "Log File cannot be used"
DIA8414C Logging can not continue due to an error.
2008-09-28-23.40.04.012228+480 I4786E336 LEVEL: Error
PID : 21458 TID : 47049341306720PROC : db2hadrp (THADR) 0
INSTANCE: e81q17b NODE : 000 DB : THADR
FUNCTION: DB2 UDB, data protection, sqlpgPostLoggrWithoutLatching, probe:930
MESSAGE : db2logger: rc=-2045771763 sem rc=0 type=5
2008-09-28-23.40.04.012409+480 I5123E186 LEVEL: Error
PID:21458 TID:47049341306720 NODE:000 Title: SQLP_DBCB
Dump File:/home/db2users/e81q17b/sqllib/db2dump/214582269546336.000
2008-09-28-23.40.04.012764+480 I5310E428 LEVEL: Error
PID : 21458 TID : 47049341306720PROC : db2hadrp (THADR) 0
INSTANCE: e81q17b NODE : 000 DB : THADR
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrWritePersist, probe:10440
RETCODE : ZRC=0x8610000D=-2045771763=SQLP_BADLOG "Log File cannot be used"
DIA8414C Logging can not continue due to an error.
2008-09-28-23.40.04.013322+480 I5739E427 LEVEL: Error
PID : 21458 TID : 47049341306720PROC : db2hadrp (THADR) 0
INSTANCE: e81q17b NODE : 000 DB : THADR
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrSetHdrState, probe:10010
RETCODE : ZRC=0x8610000D=-2045771763=SQLP_BADLOG "Log File cannot be used"
DIA8414C Logging can not continue due to an error.
2008-09-28-23.40.04.013432+480 I6167E426 LEVEL: Severe
PID : 21458 TID : 47049341306720PROC : db2hadrp (THADR) 0
INSTANCE: e81q17b NODE : 000 DB : THADR
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrCloseConn, probe:30570
RETCODE : ZRC=0x8610000D=-2045771763=SQLP_BADLOG "Log File cannot be used"
DIA8414C Logging can not continue due to an error.
2008-09-28-23.40.04.013547+480 I6594E358 LEVEL: Error
PID : 21458 TID : 47049341306720PROC : db2hadrp (THADR) 0
INSTANCE: e81q17b NODE : 000 DB : THADR
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrTcpIpRecv, probe:11810
MESSAGE : Zero bytes received. Remote end may have closed connection
2008-09-28-23.40.04.013624+480 I6953E419 LEVEL: Error
PID : 21458 TID : 47049341306720PROC : db2hadrp (THADR) 0
INSTANCE: e81q17b NODE : 000 DB : THADR
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrRecvMsgP, probe:30048
MESSAGE : HADR primary recv error:
DATA #1 : Hexdump, 4 bytes
0x00007FFF27DA6B8C : 0100 0000 ....
以上这些报错信息，在takeover by force过程中总是会被记录。实际上此时虽然两个数据库都可以连接，但是两个库的HADR角色均为Primary。这时实际上HADR配对已经被中止。同时，如果此时尝试停止原Primary数据库的HADR或者尝试连接原Primary数据库之后做一些需要记录日志的操作，均可能会失败：
db2 stop hadr on db thadr
SQL0980C A disk error occurred. Subsequent SQL statements cannot be
processed.
此时，任何需要记录日志的操作会导致数据库deactivate状态：
db2 "create table t1(a1 int not null)"
DB21034E The command was processed as an SQL statement because it was not a
valid Command Line Processor command. During SQL processing it returned:
SQL1034C The database is damaged. All applications processing the database
have been stopped. SQLSTATE=58031
如果再次尝试激活数据库的话，会有什么情况发生呢？没错，实际上，由于该数据库的HADR角色依然为Primary，所以在数据被激活的同时，会尝试重启HADR Primary。但是由于原先的HADR环境已经被破坏，不会再有standby加入到HADR环境，所以在停顿一段时间之后，激活数据的动作会返回：
SQL1768N Unable to start HADR. Reason code = "7".
接下来该这么办呢？如果还想使用原Primary数据库，办法就是通过 BY FORCE的方式启动原PRIMARY： db2 start hard on db
BY FORCE：
通知HADR Primary数据库不需要继续等待Standby数据库的加入。但是此时，当Primary接收到Standby加入的请求时，依然会做出正确的响应。
此时，如果在成功连接数据库之后，创建表就可以成功完成了！也可以停止HADR了！综上所述，请在生产环境中谨慎使用HADR TAKEOVER BY FORCE命令！