DB2 HADR概述
High Availability Disaster Recovery (HADR)是數據庫級別的高可用性數據復制機制,最初被應用于Informix數據庫系統中,稱為High Availability Data Replication(HDR)。IBM收購Informix之后,這項技術就應用到了新的DB2發行版中。一個HADR環境需要兩臺數據庫服務器:主 數據庫服務器(primary)和備用數據庫服務器(standby)。當主數據庫中發生事務操作時,會同時將日志文件通過TCP/IP協議傳送到備用數 據庫服務器,然后備用數據庫對接受到的日志文件進行重放(Replay),從而保持與主數據庫的一致性。當主數據庫發生故障時,備用數據庫服務器可以接管 主數據庫服務器的事務處理。此時,備用數據庫服務器作為新的主數據庫服務器進行數據庫的讀寫操作,而客戶端應用程序的數據庫連接可以通過自動客戶端重新路 由(Automatic Client Reroute)機制轉移到新的主服務器。當原來的主數據庫服務器被修復后,又可以作為新的備用數據庫服務器加入HADR。通過這種機制,DB2 UDB實現了數據庫的災難恢復和高可用性,最大限度的避免了數據丟失。下圖為DB2 HADR的工作原理圖:
注:處于備用角色的數據庫不能被訪問。
下面我們首先從一個配置實例入手來了解DB2 HADR環境的基本配置過程,然后再對HADR環境涉及到的一些技術要點展開討論。
![]() ![]() |
![]()
|
快速實例上手
要進行這個實例配置過程,你必須擁有DB2 UDB Enterprise Server Edition (ESE),筆者使用的是DB2 ESE v8.2.2 for Linux 32bit(在v8.2的基礎上打了Fixpack9a)。如果您沒有這個版本,可以到IBM官方網站下載試用版(可能需要花點時間填寫一些信息),下載 鏈接:https://www14.software.ibm.com/webapp/iwm/web/preLogin.do?source=db2udbdl 。
另外,筆者使用的是兩臺DELL PowerEdge 2850作為數據庫服務器,安裝Redhat Linux Enterprise Server v4.0。這兩臺機器的主機名和IP地址分別為:DBSERV1(192.168.1.162)和DBSERV2(192.168.1.163)。在下面 的配置過程中我們將DBSERV1作為主數據庫服務器,其實HADR配置好之后,這兩臺服務器的角色是可以轉換的。為簡單起見,我們就采用DB2的樣本數 據庫SAMPLE作為配置對象。
配置過程(以下命令均在DB2 CLP中執行):
1. 在DBSERV1和DBSERV2上安裝DB2,并創建缺省實例db2inst1,服務端口:50000,我們使用缺省的實例所有者用戶db2inst1,密碼:db2inst1
2. 使用db2sampl命令在DBSERV1上創建樣本數據庫SAMPLE
3. 修改SAMPLE數據庫配置參數LOGRETAIN為ON,以使該數據庫日志記錄方式改為存檔日志。
UPDATE DB CFG FOR SAMPLE USING LOGRETAIN ON |
4. 修改索引日志記錄參數
UPDATE DB CFG FOR SAMPLE USING LOGINDEXBUILD ON |
注:這一步并不是必須的。
5. 備份數據庫SAMPLE
BACKUP DB SAMPLE TO /database/dbbak |
其中"/database/dbbak"是筆者用來存放數據庫備份文件的目錄,你完全可以指定任何一個db2inst1有寫入權限的其他目錄。
備份完成之后,在/database/dbbak目錄下我們會看到數據庫備份映像文件:
SAMPLE.0.db2inst1.NODE0000.CATN0000.20050726122125.001 |
注:你所得到的文件名的時間標志部分肯定和我的不一樣,在下面的恢復數據庫命令中要注意做相應的修改。
6. 將得到的數據庫映像文件復制到DB2SERV2對應的目錄下(/database/dbbak)。
7. 在DBSERV2上恢復數據庫SAMPLE:
RESTORE DATABASE SAMPLE FROM "/database/dbbak" TAKEN AT |
8. 配置自動客戶端重新路由:
在主數據庫服務器(DBSERV1)上:
UPDATE ALTERNATE SERVER FOR DATABASE SAMPLE USING HOSTNAME 192.168.1.163 PORT 50000 |
在備用數據庫服務器上(DBSERV2):
UPDATE ALTERNATE SERVER FOR DATABASE SAMPLE USING HOSTNAME 192.168.1.162 PORT 50000 |
9. 配置HADR服務和偵聽端口
用vi編輯/etc/services文件(需要切換到root用戶),加入下面兩行:
DB2_HADR_1 55001/tcp |
對于 Windows,編輯%SystemRoot%/system32/drivers/etc/services。
注:這一步不是必須的,因為在下面配置HADR_LOCAL_SVC和HADR_REMOTE_SVC數據庫參數的時候您可以直接使用端口號來替代服務名。
10. 修改主數據庫(DBSER1 - SAMPLE)的配置參數:
UPDATE DB CFG FOR SAMPLE USING HADR_LOCAL_HOST 192.168.1.162 |
11. 修改備用數據庫(DBSERV2 - SAMPLE)的配置參數:
UPDATE DB CFG FOR SAMPLE USING HADR_LOCAL_HOST 192.168.1.163 |
12. 啟動HADR:
首先啟動備用數據庫服務器的HADR:
DEACTIVATE DATABASE SAMPLE |
然后啟動主數據庫服務器的HADR:
DEACTIVATE DATABASE SAMPLE |
注:如果你先啟動主數據庫服務器HADR,那么你必須保證在HADR_TIMEOUT參數指定的時間內(單位為秒)啟動備用數據庫服務器HADR。否則將啟動失敗。
OK,到目前為止,我們已經成功配置并啟動了DB2 HADR。在下一節中我們將對這個配置好的HADR環境進行一些測試來驗證它是否能按照我們預期的方式工作。
![]() ![]() |
![]()
|
HADR測試
1. 連接到主數據庫,創建測試表HADRTEST,并插入幾條測試數據:
CONNECT TO SAMPLE USER db2inst1 USING db2inst1 |
2. 使用備份數據庫接管主數據庫
TAKEOVER HADR ON DATABASE SAMPLE USER db2inst1 USING db2inst1 |
觀察數據庫主數據庫和備用數據庫的狀態:
GET SNAPSHOT FOR DB ON SAMPLE |
新的主數據庫(原備用數據庫):
備用數據庫(原主數據庫):
3. 連接到新的主數據庫,并查詢HADRTEST表:
顯然,我們的HADR環境已經可以正常工作了。讀者可以自己再針對數據的修改、刪除等進行一些測試。自動客戶端重新路由(Automatic Client Reroute)功能也留給讀者自己測試。
![]() ![]() |
![]()
|
HADR管理操作匯總
1. 啟動和停止HADR
使用START HADR命令啟動主數據庫和備用數據庫的HADR。啟動主數據庫使用AS PRIMARY子句,啟動備用數據庫使用AS STANDBY 子句。如果想以其他用戶啟動HADR,可以通過USER user-name USING password子句指定用戶名和密碼:
例子:
START HADR ON DATABASE SAMPLE USING db2inst1 USING db2inst1 AS STANDBY |
在啟動主數據庫的HADR時,如果在數據庫HADR_TIMEOUT所指定的時間內未能建立與備用數據庫HADR的連接,啟動將失敗。這時候,你可以等排除故障并成功啟動備用數據庫HADR后再啟動主數據庫HADR,也可以通過指定BY FORCE子句強行啟動主數據庫。
例如:
START HADR ON DATABASE SAMPLE AS PRIMARY BY FORCE |
使用STOP HADR 停止主數據庫和備用數據庫的HADR。
如果在活動的主數據庫上發出此命令,所有的數據庫連接都被斷開,數據庫恢復為標準數據庫(我們稱沒有啟用HADR的數據庫為標準數據庫),并保持聯機狀態。
如果在活動的備用數據庫上發出此命令,將停止失敗。你必須先使用DEACTIVATE DATABASE命令取消激活,然后再停止HADR。
2. 查看HARD的配置及運行狀態
HADR連接狀態:
當備用數據庫的HADR啟動時,它首先進入本地同步更新狀態。并根據本地日志路徑配置參數及日志歸檔方法的設置檢索本地系統中的日志文件并重放。當 本地日志文件重放完畢,備用數據庫進入遠程同步暫掛狀態。當與主數據庫建立連接之后,備用數據庫進入遠程同步更新狀態。即主數據庫將自己的日志文件通過 TCPIP協議發送給備用數據庫,備用數據庫接收到日志文件并重放,直到所有日志文件都重放完畢,備用數據庫和主數據庫進入對等狀態。見下圖:
通過GET SNAPSHOT命令觀察主數據庫和備用數據庫的連接狀態。
通過GET DB CFG命令可以查看HADR的配置情況,即HADR相關的幾個數據庫參數值。
3. 接管/故障轉移
當主數據庫發生故障時,備用數據庫可以接管主數據庫的服務,成為新的主數據庫(稱為故障轉移)。當原主數據庫修復后,又可以作為備用數據庫加入 HADR對。即使主數據庫服務器沒有故障,我們通過接管命令(TAKEOVER)切換主數據庫和備用數據庫的角色。接管命令只能用在備用數據庫上。
HADR提供兩種接管方式:
緊急接管:
當主數據庫發生故障時,可以在備用數據庫上使用緊急接管,使備用數據庫成為新的主數據庫。緊急接管必須指定TAKEOVER命令的BY FORCE子句,例如:
TAKEOVER HADR ON DATABASE SAMPLE BY FORCE |
普通接管:
普通接管就是沒有使用BY FORCE子句的接管,例如:
TAKEOVER HADR ON DATABASE SAMPLE |
這種接管必須在主數據庫和備用數據庫都正常運行的情況下使用。如果主數據庫發生故障,普通接管將失敗,這時候必須使用上面的緊急接管。
4. 同步方式
在上面的配置實例中我們將主數據庫和備用數據庫的HADR_SYNCMODE參數值設置為NEARSYNC,當主數據庫和備用數據庫處于對等狀態時,HADR采用NEARSYNC(接近同步)同步方式管理日志寫入。DB2提供了三種日志同步方式:
SYNC(同步):
采用SYNC方式時,僅當主數據庫日志寫入成功,并收到備用數據庫的應答,確保備用數據庫的日志也成功寫入的情況下,才認為日志寫入成功。
這種方式下的事務響應時間最長,但最大限度的確保不發生事務丟失。
NEARSYNC(接近同步):
采用NEARSYNC方式時,當主數據庫日志寫入成功,并收到備用數據庫的應答,確定備用數據庫已經接收到日志時,即認為日志寫入成功。也就是說,備用數據庫接收到的日志并不一定能成功寫入持久存儲設備上的日志文件。
這種方式下的事務響應時間比SYNC方式短,且僅當兩臺服務器同時發生故障時,才會發生事務丟失。
ASYNC(異步):
采用ASYNC方式時,當主數據庫日志寫入成功,并將日志發送出去之后,即認為日志寫入成功。此方式并不保證備用數據庫能收到日志,這要依賴于TCP/IP網絡情況。
這種方式下的事務響應時間最短,但產生事務丟失的可能性也最大
5. 自動客戶端重新路由(Automatic Client Reroute)
要配置自動客戶端重新路由,使用UPDATE ALTERNATE SERVER命令設置備用數據庫信息(使用方法參考上面的配置實例),這些信息將被存放在數據庫的系統目錄中。請注意:必須使用此命令來設置備用數據庫, 而不是HADR_REMOTE_HOST 和 HADR_REMOTE_SVC 數據庫配置參數,自動客戶端重新路由不使用這兩個參數。
當客戶端與數據庫建立連接時,備用數據庫的配置信息(主機/IP 及 端口號)也同時被發送給DB2客戶端。當客戶端與主數據庫的連接被中斷時,客戶端就使用這些信息連接到備用數據庫,從而最小限度的降低了數據庫故障所造成 的影響。需要強調的是,這個過程由DB2客戶端自動完成,不需要用戶用程序干涉。見下圖:
通過LIST DB DIRECOTRY 命令可以查看系統數據庫目錄中自動客戶端重新路由的配置。
6. 使用控制中心管理HADR
在上面的討論中我們主要通過DB2 CLP命令來創建和管理DB2 HADR。實際上DB2的控制中心也提供了創建和管理HADR的圖形界面,例如:工具-〉向導-〉設置高可用性災難恢復(HADR)數據庫。這些功能使用 起來都非常簡單,在這里我們就不詳細討論了。但是,筆者強烈建議盡量多使用DB2 CLP命令來管理DB2(不僅僅是針對HADR),不要過于依賴DB2控制中心,因為很多服務器環境都不安裝控制中心,這時候你如果沒有掌握DB2 CLP命令,那可就麻煩大了。
7. 關于索引日志記錄
索引的創建、重建、重組也是HADR環境中需要考慮的一個方面,DB2通過數據庫配置參數LOGINDEXBUILD和CREATE TABLE或ALTER TABLE語句中的LOG INDEX BUILD選項來控制是否對索引的相關操作進行詳細的日志記錄。我們在上面的HADR配置實例中將LOGINDEXBUILD數據庫參數配置為ON,意為 讓DB2記錄索引創建、重建、重組的完整日志。這顯然會降低主數據庫的運行效率并占用更多的日志空間。但因為備用數據庫可以通過重放日志來重新構建索引, 所以當主數據庫發生故障,備用數據庫的索引仍然可用。
用戶可以通過CREATE TABLE或ALTER TABLE語句的LOG INDEX BUILD選項來對單個表設定索引日志記錄級別。LOG INDEX BUILD選項有三個可選參數:
如果表選項LOG INDEX BUILD設置為OFF,或者LOG INDEX BUILD設置為NULL但數據庫配置參數LOGINDEXBUILD設置為OFF,DB2將不記錄這些表的索引維護日志,備用數據庫也就無法重放索引維 護操作,致使這些索引在備用數據庫上變為無效狀態。當主數據庫發生故障,備用數據庫切換為新主數據庫后,這些無效的索引必須重建才能被使用。DB2通過數 據庫配置參數INDEXREC來指定在什么時候檢查并重建無效索引。INDEXREC參數有三個可選值:
在上面的配置實例中,我們將INDEXREC的值設為RESTART,備用數據庫將在接管為新的主數據庫時檢查并重新構建所有無效索引。
![]() ![]() |
![]()
|
DB2 HADR的使用限制
聲明:本網頁內容旨在傳播知識,若有侵權等問題請及時與本網聯系,我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com