DB2高可用性災難恢復思路與方法

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,以使該數據庫日誌記錄方式改為存檔日誌。
1

2

UPDATE DB CFG FOR SAMPLE USING LOGRETAIN ON

UPDATE DB CFG FOR SAMPLE USING TRACKMOD ON

  1. 修改索引日誌記錄參數
1

2

UPDATE DB CFG FOR SAMPLE USING LOGINDEXBUILD ON

UPDATE DB CFG FOR SAMPLE USING INDEXREC RESTART

註:這一步並不是必須的。

  1. 備份數據庫SAMPLE
1 BACKUP DB SAMPLE TO /database/dbbak

其中”/database/dbbak”是筆者用來存放數據庫備份文件的目錄,你完全可以指定任何一個db2inst1有寫入權限的其他目錄。

備份完成之後,在/database/dbbak目錄下我們會看到數據庫備份映像文件:

1 SAMPLE.0.db2inst1.NODE0000.CATN0000.20050726122125.001

註:你所得到的文件名的時間標誌部分肯定和我的不一樣,在下面的恢複數據庫命令中要注意做相應的修改。

  1. 將得到的數據庫映像文件複製到DB2SERV2對應的目錄下(/database/dbbak)。
  2. 在DBSERV2上恢複數據庫SAMPLE:
1

2

RESTORE DATABASE SAMPLE FROM “/database/dbbak” TAKEN AT

20050726122125 REPLACE HISTORY FILE WITHOUT PROMPTING

  1. 配置自動客戶端重新路由:

在主數據庫服務器(DBSERV1)上:

1 UPDATE ALTERNATE SERVER FOR DATABASE SAMPLE USING HOSTNAME 192.168.1.163 PORT 50000

在備用數據庫服務器上(DBSERV2):

1 UPDATE ALTERNATE SERVER FOR DATABASE SAMPLE USING HOSTNAME 192.168.1.162 PORT 50000
  1. 配置HADR服務和偵聽端口

用vi編輯/etc/services文件(需要切換到root用戶),加入下面兩行:

1

2

DB2_HADR_1      55001/tcp

DB2_HADR_2      55002/tcp

對於 Windows,編輯%SystemRoot%\system32\drivers\etc\services。

註:這一步不是必須的,因為在下面配置HADR_LOCAL_SVC和HADR_REMOTE_SVC數據庫參數的時候您可以直接使用端口號來替代服務名。

  1. 修改主數據庫(DBSER1 – SAMPLE)的配置參數:
1

2

3

4

5

6

7

8

9

10

11

UPDATE DB CFG FOR SAMPLE USING HADR_LOCAL_HOST 192.168.1.162

UPDATE DB CFG FOR SAMPLE USING HADR_LOCAL_SVC DB2_HADR_1

UPDATE DB CFG FOR SAMPLE USING HADR_REMOTE_HOST 192.168.1.163

UPDATE DB CFG FOR SAMPLE USING HADR_REMOTE_SVC DB2_HADR_2

UPDATE DB CFG FOR SAMPLE USING HADR_REMOTE_INST db2inst1

UPDATE DB CFG FOR SAMPLE USING HADR_SYNCMODE NEARSYNC

UPDATE DB CFG FOR SAMPLE USING HADR_TIMEOUT 120

CONNECT TO SAMPLE

QUIESCE DATABASE IMMEDIATE FORCE CONNECTIONS

UNQUIESCE DATABASE

CONNECT RESET

  1. 修改備用數據庫(DBSERV2 – SAMPLE)的配置參數:
1

2

3

4

5

6

7

UPDATE DB CFG FOR SAMPLE USING HADR_LOCAL_HOST 192.168.1.163

UPDATE DB CFG FOR SAMPLE USING HADR_LOCAL_SVC DB2_HADR_2

UPDATE DB CFG FOR SAMPLE USING HADR_REMOTE_HOST 192.168.1.162

UPDATE DB CFG FOR SAMPLE USING HADR_REMOTE_SVC DB2_HADR_1

UPDATE DB CFG FOR SAMPLE USING HADR_REMOTE_INST db2inst1

UPDATE DB CFG FOR SAMPLE USING HADR_SYNCMODE NEARSYNC

UPDATE DB CFG FOR SAMPLE USING HADR_TIMEOUT 120

  1. 啟動HADR:

首先啟動備用數據庫服務器的HADR:

1

2

DEACTIVATE DATABASE SAMPLE

START HADR ON DATABASE SAMPLE AS STANDBY

然後啟動主數據庫服務器的HADR:

1

2

DEACTIVATE DATABASE SAMPLE

START HADR ON DATABASE SAMPLE AS PRIMARY

註:如果你先啟動主數據庫服務器HADR,那麼你必須保證在HADR_TIMEOUT參數指定的時間內(單位為秒)啟動備用數據庫服務器HADR。否則將啟動失敗。

OK,到目前為止,我們已經成功配置並啟動了DB2 HADR。在下一節中我們將對這個配置好的HADR環境進行一些測試來驗證它是否能按照我們預期的方式工作。

HADR測試

  1. 連接到主數據庫,創建測試表HADRTEST,並插入幾條測試數據:
1

2

3

4

CONNECT TO SAMPLE USER db2inst1 USING db2inst1

CREATE TABLE HADRTEST(ID INTEGER NOT NULL WITH DEFAULT,NAME VARCHAR(10),PRIMARY KEY (ID))

INSERT INTO HADRTEST (ID,NAME) VALUES (1,’張三’)

INSERT INTO HADRTEST (ID,NAME) VALUES (2,’李四’)

  1. 使用備份數據庫接管主數據庫
1 TAKEOVER HADR ON DATABASE SAMPLE USER db2inst1 USING db2inst1

觀察數據庫主數據庫和備用數據庫的狀態:

1 GET SNAPSHOT FOR DB ON SAMPLE

新的主數據庫(原備用數據庫):

備用數據庫(原主數據庫):

  1. 連接到新的主數據庫,並查詢HADRTEST表:

顯然,我們的HADR環境已經可以正常工作了。讀者可以自己再針對數據的修改、刪除等進行一些測試。自動客戶端重新路由(Automatic Client Reroute)功能也留給讀者自己測試。

HADR管理操作匯總

  1. 啟動和停止HADR

使用START HADR命令啟動主數據庫和備用數據庫的HADR。啟動主數據庫使用AS PRIMARY子句,啟動備用數據庫使用AS STANDBY 子句。如果想以其他用戶啟動HADR,可以通過USER user-name USING password子句指定用戶名和密碼:

例子:

1 START HADR ON DATABASE SAMPLE USING db2inst1 USING db2inst1 AS STANDBY

在啟動主數據庫的HADR時,如果在數據庫HADR_TIMEOUT所指定的時間內未能建立與備用數據庫HADR的連接,啟動將失敗。這時候,你可以等排除故障並成功啟動備用數據庫HADR後再啟動主數據庫HADR,也可以通過指定BY FORCE子句強行啟動主數據庫。

例如:

1 START HADR ON DATABASE SAMPLE AS PRIMARY BY FORCE

使用STOP HADR 停止主數據庫和備用數據庫的HADR。

如果在活動的主數據庫上發出此命令,所有的數據庫連接都被斷開,數據庫恢復為標準數據庫(我們稱沒有啟用HADR的數據庫為標準數據庫),並保持聯機狀態。

如果在活動的備用數據庫上發出此命令,將停止失敗。你必須先使用DEACTIVATE DATABASE命令取消激活,然後再停止HADR。

  1. 查看HARD的配置及運行狀態

HADR連接狀態:

當備用數據庫的HADR啟動時,它首先進入本地同步更新狀態。並根據本地日誌路徑配置參數及日誌歸檔方法的設置檢索本地系統中的日誌文件並重放。當本地日誌文件重放完畢,備用數據庫進入遠程同步暫掛狀態。當與主數據庫建立連接之後,備用數據庫進入遠程同步更新狀態。即主數據庫將自己的日誌文件通過TCPIP協議發送給備用數據庫,備用數據庫接收到日誌文件並重放,直到所有日誌文件都重放完畢,備用數據庫和主數據庫進入對等狀態。見下圖:

通過GET SNAPSHOT命令觀察主數據庫和備用數據庫的連接狀態。

通過GET DB CFG命令可以查看HADR的配置情況,即HADR相關的幾個數據庫參數值。

  1. 接管/故障轉移

當主數據庫發生故障時,備用數據庫可以接管主數據庫的服務,成為新的主數據庫(稱為故障轉移)。當原主數據庫修復後,又可以作為備用數據庫加入HADR對。即使主數據庫服務器沒有故障,我們通過接管命令(TAKEOVER)切換主數據庫和備用數據庫的角色。接管命令只能用在備用數據庫上。

HADR提供兩種接管方式:

緊急接管:

當主數據庫發生故障時,可以在備用數據庫上使用緊急接管,使備用數據庫成為新的主數據庫。緊急接管必須指定TAKEOVER命令的BY FORCE子句,例如:

1 TAKEOVER HADR ON DATABASE SAMPLE BY FORCE

普通接管:

普通接管就是沒有使用BY FORCE子句的接管,例如:

1 TAKEOVER HADR ON DATABASE SAMPLE

這種接管必須在主數據庫和備用數據庫都正常運行的情況下使用。如果主數據庫發生故障,普通接管將失敗,這時候必須使用上面的緊急接管。

  1. 同步方式

在上面的配置實例中我們將主數據庫和備用數據庫的HADR_SYNCMODE參數值設置為NEARSYNC,當主數據庫和備用數據庫處於對等狀態時,HADR採用NEARSYNC(接近同步)同步方式管理日誌寫入。DB2提供了三種日誌同步方式:

SYNC(同步):

採用SYNC方式時,僅當主數據庫日誌寫入成功,並收到備用數據庫的應答,確保備用數據庫的日誌也成功寫入的情況下,才認為日誌寫入成功。

這種方式下的事務響應時間最長,但最大限度的確保不發生事務丟失。

NEARSYNC(接近同步):

採用NEARSYNC方式時,當主數據庫日誌寫入成功,並收到備用數據庫的應答,確定備用數據庫已經接收到日誌時,即認為日誌寫入成功。也就是說,備用數據庫接收到的日誌並不一定能成功寫入持久存儲設備上的日誌文件。

這種方式下的事務響應時間比SYNC方式短,且僅當兩台服務器同時發生故障時,才會發生事務丟失。

ASYNC(異步):

採用ASYNC方式時,當主數據庫日誌寫入成功,並將日誌發送出去之後,即認為日誌寫入成功。此方式並不保證備用數據庫能收到日誌,這要依賴於TCP/IP網絡情況。

這種方式下的事務響應時間最短,但產生事務丟失的可能性也最大

  1. 自動客戶端重新路由(Automatic Client Reroute)

要配置自動客戶端重新路由,使用UPDATE ALTERNATE SERVER命令設置備用數據庫信息(使用方法參考上面的配置實例),這些信息將被存放在數據庫的系統目錄中。請注意:必須使用此命令來設置備用數據庫,而不是HADR_REMOTE_HOST 和 HADR_REMOTE_SVC 數據庫配置參數,自動客戶端重新路由不使用這兩個參數。

當客戶端與數據庫建立連接時,備用數據庫的配置信息(主機/IP 及 端口號)也同時被發送給DB2客戶端。當客戶端與主數據庫的連接被中斷時,客戶端就使用這些信息連接到備用數據庫,從而最小限度的降低了數據庫故障所造成的影響。需要強調的是,這個過程由DB2客戶端自動完成,不需要用戶用程序干涉。見下圖:

通過LIST DB DIRECOTRY 命令可以查看系統數據庫目錄中自動客戶端重新路由的配置。

  1. 使用控制中心管理HADR

在上面的討論中我們主要通過DB2 CLP命令來創建和管理DB2 HADR。實際上DB2的控制中心也提供了創建和管理HADR的圖形界面,例如:工具-〉嚮導-〉設置高可用性災難恢復(HADR)數據庫。這些功能使用起來都非常簡單,在這裡我們就不詳細討論了。但是,筆者強烈建議盡量多使用DB2 CLP命令來管理DB2(不僅僅是針對HADR),不要過於依賴DB2控制中心,因為很多服務器環境都不安裝控制中心,這時候你如果沒有掌握DB2 CLP命令,那可就麻煩大了。

  1. 關於索引日誌記錄

索引的創建、重建、重組也是HADR環境中需要考慮的一個方面,DB2通過數據庫配置參數LOGINDEXBUILD和CREATE TABLE或ALTER TABLE語句中的LOG INDEX BUILD選項來控制是否對索引的相關操作進行詳細的日誌記錄。我們在上面的HADR配置實例中將LOGINDEXBUILD數據庫參數配置為ON,意為讓DB2記錄索引創建、重建、重組的完整日誌。這顯然會降低主數據庫的運行效率並佔用更多的日誌空間。但因為備用數據庫可以通過重放日誌來重新構建索引,所以當主數據庫發生故障,備用數據庫的索引仍然可用。

用戶可以通過CREATE TABLE或ALTER TABLE語句的LOG INDEX BUILD選項來對單個表設定索引日誌記錄級別。LOG INDEX BUILD選項有三個可選參數:

  • NULL:這是缺省值,當使用此參數時,表的索引日誌記錄級別由數據庫配置參數LOGINDEXBUILD的值決定。
  • ON:使用此參數,數據庫配置參數LOGINDEXBUILD的值將被忽略,DB2將記錄這個表上所有索引維護的詳細日誌。
  • OFF:使用此參數時,數據庫配置參數LOGINDEXBUILD的值將被忽略,DB2將不記錄這個表上索引維護的日誌。

如果表選項LOG INDEX BUILD設置為OFF,或者LOG INDEX BUILD設置為NULL但數據庫配置參數LOGINDEXBUILD設置為OFF,DB2將不記錄這些表的索引維護日誌,備用數據庫也就無法重放索引維護操作,致使這些索引在備用數據庫上變為無效狀態。當主數據庫發生故障,備用數據庫切換為新主數據庫後,這些無效的索引必須重建才能被使用。DB2通過數據庫配置參數INDEXREC來指定在什麼時候檢查並重建無效索引。INDEXREC參數有三個可選值:

  • RESTART:DB2將在顯式或隱式重啟數據庫(RESTART DATABASE)的時候檢查並重新構建無效索引。
  • ACCESS:DB2將在無效索引第一次被訪問的時候才會重新構建它。
  • SYSTEM:使用數據庫管理器配置參數(Database Manager Configuration)INDEXREC的值。

在上面的配置實例中,我們將INDEXREC的值設為RESTART,備用數據庫將在接管為新的主數據庫時檢查並重新構建所有無效索引。

DB2 HADR的使用限制

  • 只有DB2 UDB Enterprise Server Edition(ESE)支持HADR,但HADR不能支持分區數據庫(Database Partitioning Feature,DPF)。
  • 主數據庫和備用數據庫必須運行在相同的操作系統版本上,並且DB2 UDB的版本也必須一致,除非短暫的軟件升級過程。
  • 主數據庫和備用數據庫的位大小必須一致(32位或64位)。
  • 不能在備用數據庫上進行備份操作
  • 備用數據庫是不能訪問的,客戶端程序無法連接備用數據庫。
  • 日至歸檔操作只能在主數據庫上進行。
  • 帶有COPY NO選項的LOAD命令是不支持的
  • 主數據庫和備用數據庫必須是一對一的。
  • HADR不能使用循環日誌
  • HADR不複製數據庫配置參數、共享庫、DLLs、UDFs或存儲過程

結束語

你也可以通過一些專門的HA軟件來實現高可用性和災難恢復,但這些HA軟件一般都很昂貴,而DB2 HADR是包含在DB2 ESE里的,不需要額外的費用,另外,DB2 HADR配置和管理也很簡單,而且功能也很不錯,所以筆者一直喜歡將它推薦給客戶。

 

以下文章點擊率最高

Loading…

     

如果這文章對你有幫助,請掃左上角微信支付-支付寶,給於打賞,以助博客運營

發表評論

您的電子郵箱地址不會被公開。 必填項已用*標註