互联网服务数据库
HADR 在主备切换中的一些错误操作
HADR作为DB2的一个廉价高效的多选择、高可用性方案已经被众多客户所选择使用，由于其基本原理与数据库底层的日志技术结合紧密，如果对HADR的原理不太理解，错误地使用HADR不仅不能起到保护数据的作用，反而会导致客户自己亲手破坏了数据结果。
首先介绍一下HADR的工作原理:HADR 是通过把主机（Primary）的已经提交的事务通过日志的形式传送给备机（standby），通过DB2自带的前滚功能在备机上重新执行主机已经提交的数据而达到与主机同步的状态，并在主机发生故障时，能够迅速的在保障数据一致的情况下接管主机的工作。
(上面提到的提交并不仅是事务级别的提交，还包括一切产生日志的行为)
在这里介绍几种比较集中的错误操作.
错误一：认为 HADR 的主机和备机可以随时任意切换。
在正常情况下HADR的主机和备机只有在对等状态（peer state）时才可以随时任意切换的，在其他任何情况下的切换可能会引起报错。如果加BY FORCE进行强制切换将造成对HADR环境的不可修复性破坏，而导致只能通过重建HADR环境进行修复。
HADR 和备机在建立HADR的时候都要经过几个状态
备机:
# S-Boot
# S-LocalCatchup
# S-RemoteCatchupPending
# S-RemoteCatchup
# S-NearlyPeer
# S-Peer
主机:
# P-Boot (was None)
# P-RemoteCatchupPending (was P-Boot)
# P-RemoteCatchup (was P-RemoteCatchupPending)
# P-NearlyPeer (was P-RemoteCatchup)
# P-Peer (was P-NearlyPeer)
可以看到备机比主机多了一个LocalCatchup状态，这个状态下备机是在前滚已经传送到本地的日志，其他的状态的是主机和备机成对同时出现的。可以从db2diag.log 中看到关于这些状态的记录，也可以通过“db2pd –hadr”来动态的查看HADR主机和备机的状态。
RemoteCatchupPending: 备机完成了对本地日志的前滚，尝试与主机建立通讯以获得后续的日志文件。
RemoteCatchup: 备机已经与主机成功建立了连接并正在接受新的日志用于前滚。
NearlyPeer: 备机已经完成了所有日志文件的前滚操作，处于等待主机完成暂挂日志写入和读取磁盘上日志进行处理的操作。
Peer: 根据HADR的同步模式选择，备机和主机处于对等状态.
通过从上面的状态解释可以看出，在任何非对等状态下，主备发生角色互换都是HADR不允许的。因为仍有一部分在主机已经提交的数据操作未能在备机重放，这将造成数据的丢失。同时可以看到HADR在提供数据保护之前是需要一定的时间完成准备的，而这个准备过程是异步的，不随命令启动成功而完成，需要用户通过对db2diag.log或者db2pd来查证确认，直到日志或db2pd中显示出对等（peer）状态时，数据才真正处于HADR的保护之下。因此如果进行强制切换的瞬间HADR处于对等之外的其他状态，这个切换将不可逆，并可能导致只有通过重建HADR来修复HADR环境后果。
错误二：原主机在强制切换后可以直接再加入HADR。
从HADR的操作规范来看，HADR的主机在发生故障或者由于用户发出takeover by force命令进行强制切换后应该做的是修复原主机问题，并以备机身份重新加入HADR。这一操作过程是正确的，但是成功完成是有条件的，原主机并非可以无条件直接加入HADR，要成功以备机身份加入HADR取决于下面几个因素：
·发生故障时主机和备机处于对等状态，也就是说主备之间不存在数据落差，这样主机切换到备机后再加入HADR就不会发生备机(原主机)的日志前滚点比主机(原备机)更新的情况。(下面的列子中可以看到这种情况的影响)
·发生故障并切换后,应用对主机的所有访问请求都被路由到备机,在出现故障并发生切换后,原主机的数据未发生任何更改.
大多数HADR强制切换或者由于通讯错误发生切换后,原主机以备机身份重新加入HADR失败，是由于在切换成功后在splite brain的状态下，两个库都发生了数据更改,它们之间的数据一致性遭到了破坏.
(split brain: HADR在正常状态下能保证两个数据库之间的数据一致,任何数据更改都将发生在主机,备机只是通过重放主机的日志来同步数据的.但是由于HADR为了达到其HA的功能,通讯故障和用户强制切换都将迫使HADR把备机切换成主机.故障修复后，将会有两个机器都以主机"primary"的模式在运行,或者其中一个HADR状态被切换成为正常状态.这种情况我们称之为split brain状态.在这种状态下两个库都可访问，HADR无法保证两个库的数据一致性.)
----------------------------------------------
由于HADR是基于日志建立的系统，所以对DB2日志的理解将有助于理解HADR的行为和状态划分。
下面是一个错误切换造成HADR环境被人为破坏的例子:
在这个例子中，客户在测试时多次启动备机失败后,未能分析日志中的通讯原因,而是直接选择的强制切换，最终使得发生了切换后的主机(原备机)比切换后备机(原主机)的数据更旧，在日志前滚的时候发生了下面的LSN错误，对HADR环境造成了不可修复的破坏，因此HADR需要重建.
2007-12-20-22.20.14.892094+000 E476523G345 LEVEL: Event
PID : 12430 TID : 332707200 PROC : db2hadrs (SAMPLE) 0
INSTANCE: hssinst NODE : 000 DB : SAMPLE
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrSetHdrState, probe:10000
CHANGE : HADR state set to S-LocalCatchup (was S-Boot)
2007-12-20-22.20.14.992185+000 E479411G361 LEVEL: Event
PID : 12430 TID : 332707200 PROC : db2hadrs (SAMPLE) 0
INSTANCE: hssinst NODE : 000 DB : SAMPLE
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrSetHdrState, probe:10000
CHANGE : HADR state set to S-RemoteCatchupPending (was S-LocalCatchup)
2007-12-20-22.20.21.224215+000 I482332G369 LEVEL: Severe
PID : 12430 TID : 332707200 PROC : db2hadrs (SAMPLE) 0
INSTANCE: hssinst NODE : 000 DB : SAMPLE
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrEduAcceptEvent, probe:20280
RETCODE : ZRC=0x810F0019=-2129723367=SQLO_CONN_REFUSED "Connection refused"
2007-12-20-22.21.39.661327+000 I486474G350 LEVEL: Warning
PID : 12430 TID : 332707200 PROC : db2hadrs (SAMPLE) 0
INSTANCE: hssinst NODE : 000 DB : SAMPLE
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrSDoTakeover, probe:47005
MESSAGE : Info: Standby has initiated a takeover by force.(此时尚有原主机的数据更改未能在备机重放,主备之间存在数据落差)
2007-12-20-22.21.39.761995+000 I486825G343 LEVEL: Warning
PID : 12430 TID : 332707200 PROC : db2hadrs (SAMPLE) 0
INSTANCE: hssinst NODE : 000 DB : SAMPLE
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrSDoTakeover, probe:47006
MESSAGE : Info: Standby switching roles to Primary.
2007-12-20-22.21.42.946364+000 E488952G369 LEVEL: Event
PID : 12430 TID : 332707200 PROC : db2hadrp (SAMPLE) 0
INSTANCE: hssinst NODE : 000 DB : SAMPLE
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrSetHdrState, probe:10000
CHANGE : HADR state set to P-RemoteCatchupPending (was S-RemoteCatchupPending)
2007-12-20-22.21.47.263341+000 I490664G424 LEVEL: Warning
PID : 12430 TID : 332707200 PROC : db2hadrp (SAMPLE) 0
INSTANCE: hssinst NODE : 000 DB : SAMPLE
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrEduP, probe:20485
MESSAGE : HADR Pair validation failed. Standby is ahead of Primary. Standby
LSN: 000000000D80F390 Primary LSN: 000000000D79FFFF
首先介绍一下HADR的工作原理:HADR 是通过把主机（Primary）的已经提交的事务通过日志的形式传送给备机（standby），通过DB2自带的前滚功能在备机上重新执行主机已经提交的数据而达到与主机同步的状态，并在主机发生故障时，能够迅速的在保障数据一致的情况下接管主机的工作。
(上面提到的提交并不仅是事务级别的提交，还包括一切产生日志的行为)
在这里介绍几种比较集中的错误操作.
错误一：认为 HADR 的主机和备机可以随时任意切换。
在正常情况下HADR的主机和备机只有在对等状态（peer state）时才可以随时任意切换的，在其他任何情况下的切换可能会引起报错。如果加BY FORCE进行强制切换将造成对HADR环境的不可修复性破坏，而导致只能通过重建HADR环境进行修复。
HADR 和备机在建立HADR的时候都要经过几个状态
备机:
# S-Boot
# S-LocalCatchup
# S-RemoteCatchupPending
# S-RemoteCatchup
# S-NearlyPeer
# S-Peer
主机:
# P-Boot (was None)
# P-RemoteCatchupPending (was P-Boot)
# P-RemoteCatchup (was P-RemoteCatchupPending)
# P-NearlyPeer (was P-RemoteCatchup)
# P-Peer (was P-NearlyPeer)
可以看到备机比主机多了一个LocalCatchup状态，这个状态下备机是在前滚已经传送到本地的日志，其他的状态的是主机和备机成对同时出现的。可以从db2diag.log 中看到关于这些状态的记录，也可以通过“db2pd –hadr”来动态的查看HADR主机和备机的状态。
RemoteCatchupPending: 备机完成了对本地日志的前滚，尝试与主机建立通讯以获得后续的日志文件。
RemoteCatchup: 备机已经与主机成功建立了连接并正在接受新的日志用于前滚。
NearlyPeer: 备机已经完成了所有日志文件的前滚操作，处于等待主机完成暂挂日志写入和读取磁盘上日志进行处理的操作。
Peer: 根据HADR的同步模式选择，备机和主机处于对等状态.
通过从上面的状态解释可以看出，在任何非对等状态下，主备发生角色互换都是HADR不允许的。因为仍有一部分在主机已经提交的数据操作未能在备机重放，这将造成数据的丢失。同时可以看到HADR在提供数据保护之前是需要一定的时间完成准备的，而这个准备过程是异步的，不随命令启动成功而完成，需要用户通过对db2diag.log或者db2pd来查证确认，直到日志或db2pd中显示出对等（peer）状态时，数据才真正处于HADR的保护之下。因此如果进行强制切换的瞬间HADR处于对等之外的其他状态，这个切换将不可逆，并可能导致只有通过重建HADR来修复HADR环境后果。
错误二：原主机在强制切换后可以直接再加入HADR。
从HADR的操作规范来看，HADR的主机在发生故障或者由于用户发出takeover by force命令进行强制切换后应该做的是修复原主机问题，并以备机身份重新加入HADR。这一操作过程是正确的，但是成功完成是有条件的，原主机并非可以无条件直接加入HADR，要成功以备机身份加入HADR取决于下面几个因素：
·发生故障时主机和备机处于对等状态，也就是说主备之间不存在数据落差，这样主机切换到备机后再加入HADR就不会发生备机(原主机)的日志前滚点比主机(原备机)更新的情况。(下面的列子中可以看到这种情况的影响)
·发生故障并切换后,应用对主机的所有访问请求都被路由到备机,在出现故障并发生切换后,原主机的数据未发生任何更改.
大多数HADR强制切换或者由于通讯错误发生切换后,原主机以备机身份重新加入HADR失败，是由于在切换成功后在splite brain的状态下，两个库都发生了数据更改,它们之间的数据一致性遭到了破坏.
(split brain: HADR在正常状态下能保证两个数据库之间的数据一致,任何数据更改都将发生在主机,备机只是通过重放主机的日志来同步数据的.但是由于HADR为了达到其HA的功能,通讯故障和用户强制切换都将迫使HADR把备机切换成主机.故障修复后，将会有两个机器都以主机"primary"的模式在运行,或者其中一个HADR状态被切换成为正常状态.这种情况我们称之为split brain状态.在这种状态下两个库都可访问，HADR无法保证两个库的数据一致性.)
----------------------------------------------
由于HADR是基于日志建立的系统，所以对DB2日志的理解将有助于理解HADR的行为和状态划分。
下面是一个错误切换造成HADR环境被人为破坏的例子:
在这个例子中，客户在测试时多次启动备机失败后,未能分析日志中的通讯原因,而是直接选择的强制切换，最终使得发生了切换后的主机(原备机)比切换后备机(原主机)的数据更旧，在日志前滚的时候发生了下面的LSN错误，对HADR环境造成了不可修复的破坏，因此HADR需要重建.
2007-12-20-22.20.14.892094+000 E476523G345 LEVEL: Event
PID : 12430 TID : 332707200 PROC : db2hadrs (SAMPLE) 0
INSTANCE: hssinst NODE : 000 DB : SAMPLE
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrSetHdrState, probe:10000
CHANGE : HADR state set to S-LocalCatchup (was S-Boot)
2007-12-20-22.20.14.992185+000 E479411G361 LEVEL: Event
PID : 12430 TID : 332707200 PROC : db2hadrs (SAMPLE) 0
INSTANCE: hssinst NODE : 000 DB : SAMPLE
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrSetHdrState, probe:10000
CHANGE : HADR state set to S-RemoteCatchupPending (was S-LocalCatchup)
2007-12-20-22.20.21.224215+000 I482332G369 LEVEL: Severe
PID : 12430 TID : 332707200 PROC : db2hadrs (SAMPLE) 0
INSTANCE: hssinst NODE : 000 DB : SAMPLE
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrEduAcceptEvent, probe:20280
RETCODE : ZRC=0x810F0019=-2129723367=SQLO_CONN_REFUSED "Connection refused"
2007-12-20-22.21.39.661327+000 I486474G350 LEVEL: Warning
PID : 12430 TID : 332707200 PROC : db2hadrs (SAMPLE) 0
INSTANCE: hssinst NODE : 000 DB : SAMPLE
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrSDoTakeover, probe:47005
MESSAGE : Info: Standby has initiated a takeover by force.(此时尚有原主机的数据更改未能在备机重放,主备之间存在数据落差)
2007-12-20-22.21.39.761995+000 I486825G343 LEVEL: Warning
PID : 12430 TID : 332707200 PROC : db2hadrs (SAMPLE) 0
INSTANCE: hssinst NODE : 000 DB : SAMPLE
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrSDoTakeover, probe:47006
MESSAGE : Info: Standby switching roles to Primary.
2007-12-20-22.21.42.946364+000 E488952G369 LEVEL: Event
PID : 12430 TID : 332707200 PROC : db2hadrp (SAMPLE) 0
INSTANCE: hssinst NODE : 000 DB : SAMPLE
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrSetHdrState, probe:10000
CHANGE : HADR state set to P-RemoteCatchupPending (was S-RemoteCatchupPending)
2007-12-20-22.21.47.263341+000 I490664G424 LEVEL: Warning
PID : 12430 TID : 332707200 PROC : db2hadrp (SAMPLE) 0
INSTANCE: hssinst NODE : 000 DB : SAMPLE
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrEduP, probe:20485
MESSAGE : HADR Pair validation failed. Standby is ahead of Primary. Standby
LSN: 000000000D80F390 Primary LSN: 000000000D79FFFF