DB2 HADR的4种同步模式、5种备机状态、3个超时参数

DB2 HADR的4种同步模式、5种备机状态、3个超时参数

1.) 4种同步模式

图1 显示了这4种同步模式

SYNC - Transactions on primary will commit only after relevant logs have been written to disk on both primary and standby. 应用的commit请求只有相关的日志在主、备机上都写到磁盘里，才算成功。
NEARSYNC - Transactions on primary will commit only after relevant logs have been written to disk on primary and received into memory on standby. 相关日志只要写到主机磁盘和备机的receive buffer里，就算成功。
ASYNC - Transactions on primary will commit only after relevant logs have been written to local disk and sent to standby. 相关日志只要写到主机磁盘和发送到主机的 TCP 层，就认为成功，主机不会等待备机的确认
SUPERASYNC - Transactions on primary does not wait for replication of logs to the standby. 相关日志只要写到主机的磁盘，就算成功。

参考资料：
https://www.ibm.com/support/knowledgecenter/zh/SSEPGG_10.5.0/com.ibm.db2.luw.admin.config.doc/doc/r0011445.html
https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/DB2HADR/page/HADR%20sync%20mode

2.) 5种备机状态

图2 显示了5种状态及变化

Local catchup state 备机激活后，会从它本地的日志目录读取日志。
Remote catchup pending state 读完本机的日志之后，备机就会进入Remote catchup pending state状态。
Remote catchup state 一旦和主机建立了连接，主机会读取自己的日志，发送到备机，备机这时候追主机的日志，这种状态为Remote catchup state。
Peer state 这个状态下，日志条目不是从文件中读取了，而是直接从主机的log buffer发送到备机，这个状态叫做Peer state。
Disconnected peer state 在peer状态下，如果连接已经丢失，但配置了hadr_peer_window参数，这时候会进入Disconnected peer状态。这个状态的意思是，虽然主备机的连接已经丢失，但主机会”假装“仍然是peer状态，直到hadr_peer_window也超时。这样做的好处是不至于主备机连接一断开主机就立刻写日志，有助于保持主备机的数据一致性

参考资料：
https://www.ibm.com/support/knowledgecenter/en/SSEPGG_11.1.0/com.ibm.db2.luw.admin.ha.doc/doc/c0011748.html

3.) 3个超时参数
hadr_timeout 如果这么长的时间里，主备机还建立不了联系，那么主机就认为和备机的连接丢失
hadr_peer_window 在主、备机的连接丢失之后，如果设置了这个参数，HADR会进入Disconnected peer 状态。具体请参考上面的描述。
DB2_HADR_PEER_WAIT_LIMIT 这个是db2set设置的参数，意思是如果主机的日志因为复制到备机而被阻塞这么久，那主机就认为和备机的连接丢失，这个和达到hadr_timeout效果一样，只是触发原因不同。

参考资料：
https://www.ibm.com/support/knowledgecenter/en/SSEPGG_10.5.0/com.ibm.db2.luw.admin.ha.doc/doc/c0056394.html
https://www.ibm.com/support/knowledgecenter/SSEPGG_10.5.0/com.ibm.db2.luw.admin.regvars.doc/doc/r0005669.html