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. 相关日志只要写到主机的磁盘，就算成功。
参考资料：
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也超时。这样做的好处是不至于主备机连接一断开主机就立刻写日志，有助于保持主备机的数据一致性
参考资料：
3.) 3个超时参数
hadr_timeout 如果这么长的时间里，主备机还建立不了联系，那么主机就认为和备机的连接丢失
hadr_peer_window 在主、备机的连接丢失之后，如果设置了这个参数，HADR会进入Disconnected peer 状态。具体请参考上面的描述。
DB2_HADR_PEER_WAIT_LIMIT 这个是db2set设置的参数，意思是如果主机的日志因为复制到备机而被阻塞这么久，那主机就认为和备机的连接丢失，这个和达到hadr_timeout效果一样，只是触发原因不同。
参考资料：
