Posted on by Evan

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…

     

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