實戰 Db2 purescale 集群 HADR 容災解決方案

DB2 pureScale集群HADR特性介紹

DB2 pureScale是典型的資料庫集群架構，多個成員同時為一個資料庫服務。每個成員會記載各自的日誌。HADR是基於日誌傳輸的同步手段，在存在多個成員日誌的情況下，備集群的成員需要合併日誌流，然後重放，從而達到同步的功能。

在DB2 pureScale集群HADR容災架構的體系中，備端也需要是DB2 pureScale集群。並且備集群的成員數量要大於或等於主集群的成員數量。這是因為在現有的體系架構下，對於所有在主集群的成員ID，備集群需要有同樣的ID的成員結構才能做日誌回放。

圖1. DB2 pureScale HADR架構

Replay Member概念

從圖中可以看出DB2 pureScale環境下HADR的實現機制。在備集群中，只有一個成員會執行重做的工作。所有的日誌流都是通過TCP/IP網路傳輸至此成員。所以選取合適的Replay Member非常重要。備集群的Replay Member可以安排資源比較充分的節點。例如可以選擇分配更多的CPU和內存的資源給這個LPAR。

Replay Member是一個邏輯的概念，僅僅是指在做回放的成員。用戶可以指定偏好的成員來成為Replay Member。這種又稱之為Prefer Member，意思是儘可能選擇這個prefer的member做Replay Member。

在DB2 pureScale集群HADR的容災架構中，備集群的Replay Member上資料庫是激活並工作的。其他的成員上該資料庫是非激活狀態。Replay Member這個角色在pureScale集群裡面同樣具有高可用性。一旦當前的Replay Member出現故障，DB2會在集群裡面其他的成員上選擇一個激活資料庫，成為新的Replay Member。在選擇的過程中，如果有prefer member，就會選擇prefer member。如果故障的是prefer member，則隨機選擇一個。所以prefer member並不是強制的概念。Replay Member也可以是任何一個成員。

HADR 同步方式確定高可用性災難恢復 (HADR) 資料庫解決方案對事務損失的保護程度。同步方式決定主資料庫伺服器根據備用資料庫上記錄的狀態，何時認為事務已完成。同步方式配置參數值越嚴格，資料庫解決方案就越能防止事務數據丟失，但事務處理速度也越慢。所以必須在防止事務丟失的需求與對性能需求之間取得平衡。

普通HADR同步模式主要有四種：SYNC（同步），NEARSYNC（接近同步），SUPERASYNC（超級非同步）和 ASYNC（非同步）。在DB2 pureScale環境下早期版本只支持其中的兩種同步模式：SUPERASYNC（超級非同步）和 ASYNC（非同步）。現在的最新10.5和11版本對這四種模式全部支持。

DB2 pureScale集群建設HADR環境需要考慮數據丟失的可能性。非同步模式下主資料庫上的事務落實操作不會受到相對較慢的 HADR 網路或備用 HADR 伺服器的影響，所以主資料庫與備用資料庫之間的日誌間隔可能會繼續增大。監視日誌間隔很重要，這是因為在主系統上發生真正的災難時，日誌間隔是可能丟失的事務數的間接度量。在災難恢復方案中，日誌間隔期間落實的任何事務都對備用資料庫不可用。因此，請使用 hadr_log_gap 監視元素來監視日誌間隔；如果出現日誌間隔不可接受的情況，請調查網路中斷次數或備用資料庫節點的相對速度，並採取糾正措施以減小日誌間隔。

為了數據的安全性考慮，異地推薦使用SUPERASYNC模式。本地推薦NEARSYNC模式。

與普通單機版DB2資料庫的HADR功能一樣，DB2 pureScale集群下的HADR功能延續了簡單易用的切換方式。僅僅是一條takeover命令，就可以完成整個資料庫的主備切換。切換的效率非常高，同時切換過程中也會對數據進行保護，杜絕各種腦裂等情況的發生。DB2 pureScale集群下的HADR的切換也分為正常切換和強制切換這兩種。

在主備集群相連通的情況下，正常切換會先關閉原主端的資料庫，備端接受完全部日誌並回放完成後變為新的主端，原主端會激活資料庫變為新的備端，整個切換過程就完成了，資料庫也可以提供服務了。HADR也正常工作。

在主備集群相連通的情況下，強制切換會強行關閉原主端的資料庫並阻止它激活，也沒有改變它的HADR角色屬性。然後備端接受完全部日誌並回放完成後變為新的主端，整個切換過程就完成了，資料庫也可以提供服務了。HADR處於非啟動狀態。

在主備集群不連通的情況下，備端感受不到主端的狀態。這種情況只能進行強制切換。強制切換會將備端的日誌回放完成後變為新的主端，資料庫提供服務，HADR處於非啟動狀態。一旦與原主端的網路恢復，就會出現腦裂的場景。DB2會選擇殺掉原主端，從而保證不出現腦裂的問題。

對於單機的資料庫HADR或者ha集群，虛擬服務IP自動切換是常用的一種方式。客戶端通過服務IP連接到資料庫主機。一旦主機切換，服務IP會飄移到新的主機上。這種服務IP 飄移需要集群軟體支持，例如TSA，HACMP等。然而這種方式對於DB2 pureScale集群是不可行的。

DB2 pureScale集群的實現機制裡面使用的是TSA集群軟體，基礎軟體是RSCT。一台機器只能屬於一個RSCT集群。所以先前HACMP等集群軟體加虛擬IP的方式來配置應用連資料庫已經不可行了。如果是虛擬IP，對於pureScale集群來說也很難做到負載均衡等各種連接方式。所以在DB2 pureScale集群HADR架構下，對現有的pureScale集群的連接方式做了增強，加上了備集群的信息後，能夠達到自動切換路由（ACR）的功能。在DB2 10.5裡面，客戶端主要有三種連接方式：

WLB：工作負載均衡是現有的應用方式之一，能夠根據成員上資源的消耗來合理安排，使空閑成員處理新的工作的概率更大，從而達到資源的有效利用。在引入了HADR功能之後，WLB依然適用。只要配置好了Alternate Server的信息指向備集群，在HADR切換之後，客戶端會自動連接到新的主集群，WLB也能正常生效。

Client Affinity：在這種方式下，DB2的客戶端不需要獲取所連接集群的信息，只需要按照自己的偏好列表裡面定義的策略去訪問節點。所以在偏好列表裡面加上備集群的成員節點信息，就能夠做到應用的自動切換。

Member Subsetting：這是在DB2 10.5開始加入的一種新的連接方式。在這種方式下，用戶可以控制應用只連接指定的成員節點。在這些成員節點上，應用還可以採用WLB，Affinity或者Round Robin的負載方式。對於HADR來說，這些定義都是存儲在資料庫內部的，所以切換之後，配置信息不會丟，應用還會延續先前的連接方式。

DB2 pureScale集群最大的特點就是具有高可用性，高擴展性和應用透明性。加入的HADR的容災機制之後，這些特性並沒有受到影響。應用連接資料庫所使用的原有機制並沒有改變。一旦集群里的節點出現故障，原有的集群保護機制依舊生效。那麼對於HADR的工作機制來說，這種高可用性也是延續的。

主集群一旦成員節點發生故障，那麼該節點的資料庫服務會被其他節點所接管。HADR服務也是一樣，其他健康的成員節點會幫助傳輸日誌到備集群（日誌在共享存儲上），從而達到高可用性。這種行為也稱為輔助日誌傳輸。

備集群如果發生節點故障，一方面備集群的節點自我恢復能力和普通pureScale集群是一樣的。另一方面，如果發生的故障會影響到HADR功能，例如Replay Member被關機，那麼HADR的功能也是會自我恢復的。這種情況下集群會挑選一個健康的成員來成為新的Replay Member。

所以pureScale集群里的HADR功能也同樣是高可用的，包括主集群輔助日誌傳輸和備集群replay member切換。

DB2 pureScale集群通過HADR功能，傳輸日誌到備端。這種方式既高效又安全，也是延續了普通單機版DB2久經驗證的HADR機制。只有生成日誌的事務才需要被同步到備集群。HADR的spooling功能能夠在Replay Member來不及回放的情況下將日誌先緩衝在磁碟上，避免了高峰期對性能的影響和保證了數據的安全。

DB2 pureScale集群HADR的配置與普通單機版DB2的HADR配置相似，只是配置的參數有些許變化。

主備集群的成員ID需要是同一的。也就是如果主集群的成員節點編號是1、2、3。那麼備集群成員節點編號也得是1、2、3，而不能是2、3、4。一般主備集群會是同樣的配置。HADR的配置是資料庫級別的配置，和實例沒有關係。主備集群的實例創建和普通pureScale實例創建一樣。在我們的實戰環境裡面，主要有A，B兩個集群。A集群有兩個成員節點，分別是purescaleam1和purescaleam2，B集群和A集群的架構一樣，兩個成員節點分別是purescalebm1和purescalebm2。下面討論下在集群中與HADR相關的參數配置。

首先是與HADR相關的Db2註冊表變數：

DB2_HADR_BUF_SIZE：這個參數用來配置HADR接受日誌的緩衝池的大小。默認為日誌寫緩存的兩倍。因為從DB2 V10版本開始，HADR引入了Log Spooling的功能，如果接受日誌的緩衝池滿了，HADR會先將日誌保存到磁碟。所以即便接受日誌的緩衝池滿了，也不會影響日誌的傳送。建議默認就可以。繁忙的生產環境建議設置為100M。

DB2_HADR_NO_IP_CHECK：這個參數主要用於NAT環境。主要用於主備端DB2是否交叉檢查local host和remote host的正確性。因為DB2 pureScale不支持NAT，所以這個參數不需要設置。

DB2_HADR_PEER_WAIT_LIMIT：這個參數用來設置當日誌寫入被堵住多少秒之後，主端資料庫會跳出peer狀態。這個參數主要用於設置HADR對應用性能的影響。在HADR功能堵住的情況下，應用是需要一直等還是跳出peer狀態繼續工作。網路質量差的環境建議設置較小的值，減少對應用事務的影響。

DB2_HADR_ROS：這個參數用來設置是否開啟備機讀功能。在DB2 V10.5裡面， DB2 pureScale集群的HADR功能不支持備機讀。所以不需要設置此參數。

DB2_HADR_SORCVBUF：用來設置操作系統TCP socket接受緩存大小。如果不設置，這個緩存將採用操作系統的tcp接受緩存設置。

DB2_HADR_SOSNDBUF：用來設置操作系統TCP socket發送緩存大小。如果不設置，這個緩存將採用操作系統的tcp發送緩存設置

設置註冊表變數的方式如下：

清單 1. 設置DB2註冊表參數（案例）# db2set DB2_HADR_PEER_WAIT_LIMIT=5

配置資料庫

在DB2 pureScale創建的資料庫只能使用Automatic Storage。資料庫路徑必須在GPFS共享存儲上。

清單 2.創建資料庫# db2 create database TESTDB AUTOMATIC STORAGE YES ON /db2fs/db2data USING CODESET GBK TERRITORY CN

使用HADR的資料庫必須啟用歸檔日誌模式。

清單 3.啟用歸檔日誌# db2 update db cfg for TESTDB using LOGARCHMETH1 DISK:/db2fs/db2data/archive_log/

資料庫運行過程中，最好記錄索引創建、重新創建或重組操作，以便可以在DB2前滾操作或HADR日誌重放過程中重構索引。

清單 4.啟用索引日誌記錄# db2 update db cfg for TESTDB using logindexbuild on# db2 update db cfg for TESTDB using indexrec restart

上面的配置完成後，資料庫已經滿足了使用HADR功能的條件。在主集群備份資料庫，然後在備集群恢復。

清單 5.主集群備份資料庫# db2 backup db TESTDB to /mnt/dbbackup清單 6.被集群恢復資料庫# db2 RESTORE DATABASE TESTDB from /mnt/dbbackup taken at 20170604152223 to /db2fs/db2data

這樣兩邊就有了同一的資料庫，可以開始HADR的配置。配置資料庫HADR功能之前，先了解一下HADR相關的資料庫配置參數：

hadr_local_host：本地HADR網路名或IP地址

hadr_local_svc：本地HADR埠

hadr_peer_window：此參數是在HADR出現故障的情況下，主備機還保持peer狀態的時間。超過這個時間就會變為非peer狀態。

hadr_remote_host：不設置。PureScale HADR環境不使用此參數來配置，會被動態更新

hadr_remote_inst：遠程主機的實例名

hadr_remote_svc：不設置。PureScale HADR環境不使用此參數來配置，會被動態更新

hadr_replay_delay：這個參數用來設置日誌延遲重放的時間。除非特殊需求，一般不設置。

hadr_spool_limit：這個參數用來設置在備機HADR回放跟不上的情況下，日誌先寫入磁碟的空間大小限制。默認設置為開啟，總大小為在線日誌定義的大小。

hadr_syncmode：HADR的同步模式。

hadr_target_list：　用來定義對應集群的所有成員信息。這個參數是DB2 pureScale集群下HADR配置的主要方式，替代了hadr_remote_host 和hadr_remote_svc 參數。配置格式如下：

hadr_timeout：設置HADR通信超時的時間。

清單 7.配置主資料庫

db2 "update db cfg for TESTDB using HADR_TARGET_LIST "

db2_all "db2 update db cfg for TESTDB member $DB2NODE using hadr_local_host hostname"

db2 update db cfg for TESTDB using HADR_REMOTE_INST db2sdin1

db2 update db cfg for TESTDB member 0 using hadr_local_svc 6666

db2 update db cfg for TESTDB member 1 using hadr_local_svc 6667

db2 update db cfg for TESTDB using HADR_TIMEOUT 60

db2 update db cfg for TESTDB using HADR_SYNCMODE ASYNC

db2 update alternate server for database TESTDB using hostname purescalebm1 port 50000

清單 8.配置備資料庫

db2 "update db cfg for TESTDB using HADR_TARGET_LIST "

db2_all "db2 update db cfg for TESTDB member $DB2NODE using hadr_local_host hostname"

db2 update db cfg for TESTDB using HADR_REMOTE_INST db2sdin1

db2 update db cfg for TESTDB member 0 using hadr_local_svc 6666

db2 update db cfg for TESTDB member 1 using hadr_local_svc 6667

db2 update db cfg for TESTDB using HADR_TIMEOUT 60

db2 update db cfg for TESTDB using HADR_SYNCMODE ASYNC

db2 update alternate server for database TESTDB using hostname purescaleam1 port 50000

至此關於HADR的功能配置就已經完成了。這個裡面需要注意的是hadr_local_host和hadr_local_svc需要在對每個成員節點單獨設置。不同成員節點的hadr_local_svc要使用不同的埠。這點非常重要！而HADR_TARGET_LIST包含另一個集群的所有成員節點和埠。

在DB2 pureScale HADR集群環境下，為了保證主機角色切換之後，應用伺服器能夠自動連接到新的主集群，需要對客戶端進行配置。配置的方式主要分為兩種：ACR和Client Affinity。

首先討論自動重新路由(ACR)的配置方式：

DB2自動客戶端重新路由機制在DB2 pureScale集群中某成員節點發生故障的時候，將連接到該成員節點上所有的應用和工作負載自動的轉移到DB2 pureScale集群中其它仍然正常運行的節點上去。該機制是實現資料庫高可用性的重要保障。

DB2 pureScale的ACR是默認打開的，無論DB2客戶應用連接至DB2 pureScale集群的中的哪一個成員節點，該節點都會將DB2 pureScale集群中所有可用的成員節點列表返回給DB2客戶端，而DB2客戶端會將該列表緩存在自己的內存中。如果某應用程序當前連接的DB2 pureScale成員節點發生故障時，DB2客戶端會自動選擇成員節點列表中的其它某個節點重新建立連接。但是在HADR環境，DB2 pureScale的ACR是無法知道備集群的主機信息的，所以需要顯式的配置。

非JAVA應用需要通過客戶端的一個配置文件db2dsdriver.cfg來設置工作負載均衡和ACR選項，這個配置文件裡面包含多個元素。配置中在alternate_server_list裡面需要定義所有主備集群的member信息：

清單 9.配置非JAVA應用ACR

如果是JAVA應用，例如使用WAS，weblogic等中間件的數據源配置。以WAS環境下作為案例，配置ACR所使用到的對方一個member主機信息.

圖 1.配置JAVA應用ACR

除了ACR模式，路由偏好設置（Client Affinity）也是常用的方式。這種情況下資料庫客戶端或者jdbc驅動會基於路由列表來查找機器，按照優先順序訪問對應的節點。一般備集群的節點放在路由列表的後面位置。

非JAVA應用需要通過客戶端的一個配置文件db2dsdriver.cfg來設置Client Affinity選項，偏好列表裡面需要定義好所有主備集群所有member的信息。

清單 10.配置非JAVA應用Client Affinity

配置JAVA應用Client Affinity

例如在WAS環境下,配置偏好路由的方式是在WAS的數據源里定製屬性中配置以下參數.

enableClientAffinitiesList 設置是否啟用偏好列表。

clientRerouteAlternateServerName所有主備集群成員伺服器名稱，以逗號間隔。

clientRerouteAlternatePortNumber 所有主備集群成員伺服器埠，以逗號間隔。和clientRerouteAlternateServerName結合起來，相當於定義了前面所說的伺服器列表。

maxRetriesForClientReroute 自動重路由最大嘗試次數。前面WAS裡面設置的也就是更改這個參數。

retryIntervalForClientReroute 自動重路由時間間隔。

affinityFailbackInterval 重新路由回首選成員的時間間隔。

DB2 pureScale集群下的HADR功能啟動和單機版HADR的啟動邏輯是一樣的，也是先啟動備集群資料庫HADR，然後啟動主集群資料庫HADR。

清單11.啟動備資料庫HADR

db2 start hadr on db TESTDB as standby

清單12.啟動主資料庫HADR

db2 start hadr on db TESTDB as primary

啟動成功後，HADR功能會匹配主備集群的配置，完成握手並正常工作。

至此關於在DB2 pureScale集群如何安裝配置HADR功能已經展示完畢。在此過程中需要關注HADR相關的幾個重要參數。首先是配置pureScale集群的HADR使用的hadr_target_list參數，這和以前單機是不一樣的。這裡還要注意每個成員的HADR埠一定要不一樣，不然在發生HADR角色接管的過程中會衝突。HADR的同步模式有四種，需要根據實際需求，考慮性能，數據一致性等。

? Db2 for Linux UNIX and Windows：獲得 DB2 家族產品和特性的描述。

? 參考「IBM DB2 database and SAP software」，了解更多DB2和SAP的相關內容。

? 通過訪問 developerWorks 中國 Information Management 專區的 DB2 purScale 專題獲得關於DB2 pureScale集群更多的文章、教程和多媒體課件等學習資源。

? 通過訪問 developerWorks 中國 Information Management 專區的從 Oracle 遷移到 DB2獲得關於「從Oracel遷移到DB2」更多的文章、教程和多媒體課件等學習資源。

? IBM DB2 培訓和認證：找到獲獎的教員、業界領先的軟體、動手實驗室等。

? DB2 for Linux, UNIX, and Windows 最佳實踐：獲得DB2應用的最佳實踐等文章。

本文作者：孔再華，IBM 認證高級 DBA，SAP 認證 BASIS。在DB2 pureScale 集群產品的項目諮詢和實施上尤其具有豐富的經驗，力主了早期在煙草，銀行，證券等行業的推廣。曾是 IBM 大中華區 DB2 訓練營的講師，負責多門課程。現任職於中國民生銀行科技部，負責推廣資料庫同城雙活架構建設（主要DB2 GDPC雙活方案）。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！