在剛剛發布的 DB2 LUW 10.1 中，高可用性災難恢復 HADR 增加了一些新的特性，即對于多個備機數據庫的支持、日志假脫機、延時重做。通過配置多個備機，用戶可以同時實現高可用性和災難恢復的目標，即在同城配置擁有較強同步模式的主要備機實現高可用性，又在距
使用日志假脫機，在主機交易高峰期，減少因為備機重做較慢而對主機業務產生的影響。延遲重做則使用戶通過 hadr 可以撤回一些誤操作。
HADR 基礎
HADR（High Availability Disaster and Recovery）是 DB2 Linux Unix and Windows 中高可用性和災難恢復的解決方案。通過該解決方案，用戶可以為實際生產系統的設置一個備用，前者稱為主數據庫（Primary Database），后者稱為備機數據庫（Standby Database）。主數據庫上的數據更改通過數據庫日志（Log）傳送到備機數據庫上，備機數據庫通過重做（Replay）這些日志完成與主數據庫上相同的數據更改，從而使二者的數據保持一致。在主數據庫發生故障時，用戶可以在備機數據庫上通過接管 HADR（TAKEOVER HADR）命令使備機數據庫成為新主數據庫，業務應用可以運行在新主數據庫之上，從而使數據庫服務恢復。
HADR 接管
備機數據庫接管主數據庫有兩種方式，一種是強制接管（TAKEOVER HADR BY FORCE），另一種是非強制接管（non-force TAKEOVER，即不帶 BY FORCE 的 TAKEOVER HADR 命令）。強制接管用于原主數據庫不可用的情況下，備機數據庫接管數據庫服務；非強制接管用于系統在線升級（rolling upgrade）。
HADR 同步模式
主數據庫和備機數據庫之間的日志傳輸通過 HADR 同步模式（HADR_SYNCMODE）這一數據庫配置參數控制。目前，有四種同步模式可供選擇，按照同步程度從強到弱依次是：
同步模式（SYNC）
在同步模式下，當用戶在主數據庫上提交一個事務時，首先該事務的相關數據庫日志會被寫到主數據庫的本地磁盤上，然后主數據庫會將日志發送給備機數據庫，并且等待備機數據庫的回復；備機數據庫在接收到日志，并將其寫到自己的磁盤上后，才回復給主數據庫。主數據庫在接到備機數據庫的回復之后，才返回給用戶該事務提交成功。由此可見，在該同步模式下，凡是提交成功的事務，日志不僅在主數據庫的磁盤上，也在備機數據庫的磁盤上，此時如果主數據庫發生故障，已提交的數據不會丟失。因此，在同步模式下，HADR 能夠提供無數據丟失保證（No data loss guarantee）。但是，在該同步模式下，HADR 對主數據庫業務的影響也是顯而易見的。
近同步模式（NEARSYNC）
與同步模式相比，近同步模式下的備機數據庫接收到主數據庫發來的日志時，并不等待將其寫到本地磁盤之后才回復給主數據庫，而是立即回復給主數據庫。主數據庫在接收到備機數據庫的回復之后就返回給用戶事務提交成功，而此時，該事務的日志可能還在備機數據庫的內存中，并未寫到本地盤上。如果此時主機發生故障，并不能保證在原主數據庫上已提交的數據在備機上必然能找回。雖然該同步模式不能保證零數據丟失，但是相比同步模式，近同步模式下的 HADR 對于主數據庫業務的影響較小。
異步模式（ASYNC）
在異步模式下，主數據庫發送日志成功后就返回給用戶，事務提交成功，而此時，備機數據庫有可能還沒有收到這些日志。如果此時主數據庫發生故障，該已提交事務的數據更改就會丟失。同樣的，由于異步模式下的主數據庫在返回給用戶事務提交成功之前不等待備機數據庫的回復，HADR 對主數據庫上業務的影響比近同步模式更小。
超級異步模式（SUPERASYNC）
從 DB2 LUW V9.7.5 和 V9.5.8 開始，HADR 引入了一種新的同步模式，即超同步模式。在該同步模式下，主數據庫上數據庫日志的產生與發送完全分離，二者沒有任何依賴，這樣 HADR 對于主數據庫業務的影響降到了最低；同時，由于日志的產生與發送分離，可能導致主數據庫和備機數據庫之間的差距較大，此時如果主機發生故障，會有較多的數據丟失；并且非強制接管（non-force TAKEOVER）可能需要更多時間。
以上四種同步模式，同步強度從強到弱，無數據丟失保證從高到低。有關同步模式的更詳細描述，請參考本文末尾參考資源中的“DB2 HADR 監控詳解”一文。
HADR 的備機可讀
備機數據庫通過重做（Replay）主數據庫發送的數據庫日志（Transaction Log）來完與主數據庫上完全一致的數據更改，這一重做過程是通過數據庫前滾（Database Rollforward）來實現的。在 V9.7 Fix Pack 1 之前，備機數據庫只進行日志的重做，用戶不能進行任何讀寫數據的操作，因此備機數據庫對于用戶來說是不可用的。從 V9.7 Fix Pack 1，DB2 引入了備機數據庫可讀的特性，用戶可以將只讀應用運行在備機數據庫上，從而提高系統的利用率以及降低主數據庫的負載。關于 HADR 的備機可讀特性，請參考本文參考資源中的“DB2 V9.7 高可用性災難恢復中的備機可讀”一文。
DB2 HADR 近幾個版本穩定性不斷提高，功能上雖然有一些改進，例如 V9.5 增加了 peer window 和集成的 HA 方案；V9.7 增加了備機可讀（RoS），但是一直沒有大幅度的改動。DB2 V9.8 增加了 DB2 purescale 特性，但是該版本不支持 HADR。
DB2 LUW V10.1 中，HADR 是幾個版本以來改動最大的一次，在這個版本中，主要有以下幾方面新的功能。
多點災備（HADR Multiple Standby）
一個主機可以支持多臺備機（最多 3 臺）。在該版本以前，HADR 的一臺主機只能有一臺備機。如果客戶有多點災備的需求，只能通過 Q 復制和 SQL 復制等方式實現。這些方式雖然在某種方面上有其優勢，但是實時性和易用性都不如 HADR，而且，多種災備方式要求 DBA 掌握更多的知識進行維護，也就增加了維護的成本。有了這個特性，客戶就可以使用 HADR 進行統一的高可用性和災備部署。一種典型的部署是：本地使用 HADR 做實時熱備，一個遠程使用異步方式（以免對本地事務造成壓力）進行數據庫同步，另一個遠程同樣使用異步方式同步，但是可以使用重演延遲防止錯誤操作。
日志假脫機（Log Spooling）
可以想象，任何一種同步方式都是將數據從一端發往另一端。HADR 也不例外，主機會根據不同的配置以不同的方式將日志發送給備機進行同步。這樣就必不可少的增加了網絡上的開銷。很多客戶為了節省開銷，會使用性能稍差的備機。正常的交易下，備機還沒有什么壓力，但是交易高峰期間，備機可能跟不上主機的壓力，使得接收日志的內存緩沖區變滿，從而在某些同步模式下影響了主機的性能。為了解決這個問題，V10.1 中增加了該功能。當內存中沒有空間接收日志時，就將日志寫到磁盤上。當主機壓力降下來以后，再將這些事務進行重做。這樣，即使交易高峰期間，也不會對主機性能造成影響。而且日志保存在了備機上，即使主機出現故障停機，也不會在備機上丟失數據。
重演延遲（Delay Replay）
顧名思義，這個功能是讓備機延時重做主機上的事務。為什么要這樣做呢？試想一下，DBA 不小心錯誤的刪除了數據庫中的一張表。在沒有這個功能之前怎么辦呢？我們只使用某個時間的備份文件，將主機上的數據恢復到刪除表以前，然后再前滾到剛好刪除刪除表的那個時間點。然后還要重新初始化 HADR 的備機。而這個時間段上，服務是停掉的。對于大型的數據庫來說，無疑是一種很大的挑戰。如果是使能了這個功能，事情就變得簡單多了。因為雖然主機上錯誤的刪除了這個表，但是備機并沒有執行這個操作。客戶只要停掉備機上的 HADR，然后前滾到刪除表的那個時間點以前就可以了。當然，初始化 HADR 還是需要的。
更詳細的監控
DB2 LUW v10 中對 HADR 的監控內容更加詳細。例如可以看到主機和備機上的事務的時間，可以看出來接收的日志的位置和重做的日志的位置，可以分析出來 HADR 在網絡上的開銷等等。
