DB2-HADR搭建

DB2-HADR搭建

1、系統環境搭建

系統版本：CentOS-6.7-x86_64-bin-DVD1  

1、選擇 minimal

2、安裝完成配置IP、主機名 （/etc/hosts  /etc/sysconfig/network  改為相同主機名）

數據庫版本：v9.7fp7_linuxx64_server.tar

3、在centos-6.7系統下安裝好主庫 erpdb、和從庫實例  

4、同步時間  ntpdate asia.pool.ntp.org  （可不做，看具體時間而定）

5、安裝scp   yum install -y openssh-clients （可不做，為了傳備份集而做）

以下實驗以數據庫devdb47為主庫，devdb49為備庫： 

1、備份主庫

db2 backup db devdb47

2、將備份集傳于從庫

scp xxx(備份集) 172.16.0.49：/home/db2inst1 

3、從庫還原備份集

db2 restore db devdb47

4、配置通訊端口

主從都修改

vi  /etc/service

添加 db2h_erpinst1 70000/tcp

5、主從參數配置   參數具體含義看最下解釋

主庫：

db2 update db cfg for devdb47 using hadr_local_host PrimaryNode-1

db2 update db cfg for devdb47 using hadr_local_svc db2h_erpinst1

db2 update db cfg for devdb47 using hadr_remote_host PrimaryNode-2

db2 update db cfg for devdb47 using hadr_remote_svc db2h_erpinst1

db2 update db cfg for devdb47 using hadr_remote_inst db2inst1

db2 update db cfg for devdb47 using logindexbuild on

db2 update db cfg for devdb47 using indexrec restart

db2 update db cfg for devdb47 using hadr_syncmode SUPERASYNC

從庫：

db2 update db cfg for devdb47 using hadr_local_host PrimaryNode-2

db2 update db cfg fordevdb47 using hadr_local_svc db2h_erpinst1

db2 update db cfg for devdb47 using hadr_remote_host PrimaryNode-1

db2 update db cfg for devdb47 using hadr_remote_svc db2h_erpinst1

db2 update db cfg for devdb47 using hadr_remote_inst db2inst1

db2 update db cfg for devdb47 using logindexbuild on

db2 update db cfg for devdb47 using indexrec restart

db2 update db cfg for devdb47 using hadr_syncmode SUPERASYNC

6、注冊變量配置：

主庫：

db2set db2_HADR_ROS=ON 

db2set db2_STANDBY_ISO=UR

#開啟備庫只讀

從庫：

db2set db2_HADR_ROS=ON

db2set db2_STANDBY_ISO=UR

7、啟動主從數據庫（第一次啟動，切記以后啟動不在使用）：

從庫：

db2start

db2 start HADR on db devdb47 as standby

主庫：

db2start

db2 start HADR on db devdb47 as primary

查看hadr：

db2 get db cfg  for devdb47| grep HADR

10、最后主查看表空間，在用工具查看數據

db2 list tablespaces show detail

第一次啟動以后的啟動：（附關閉過程）

主（關閉過程）：

取消激活主數據庫以及停止數據庫devdb47  

db2 list applications all    #斷開所有連接

db2 terminate 

db2 deactivate db erpdb

db2stop force

備（關閉過程）：

取消激活備用數據庫及停止數據庫devdb47  

db2 list applications all   #斷開所有連接

db2 terminate 

db2 deactivate db erpdb

db2stop force

以上關閉完成

開始啟動過程（第一次啟動后的啟動）：

備：

1、db2start

2、db2 activate db devdb47  # 激活數據庫

3、在主服務器上，運行以下命令以驗證此服務器的 HADR 角色

      db2 get snapshot for db on devdb47| grep Role

4、在各服務器上，運行以下命令以驗證數據庫是否已同步

      db2 get snapshot for database on devdb47| grep State

5、查看HADR狀態  （此時查看的數據不同步，插入數據后查看數據同步）

      db2pd -db erpdb   -hadr 

 主：

1、db2start

2、db2 activate db devdb47

3、在主服務器上，運行以下命令以驗證此服務器的 HADR 角色

      db2 get snapshot for db on devdb47| grep Role

4、在各服務器上，運行以下命令以驗證數據庫是否已同步

      db2 get snapshot for database on devdb47| grep State

5、查看HADR狀態  （此時查看的數據不同步，插入數據后查看數據同步）

      db2pd -db erpdb   -hadr  

HADR搭建完成后需要導入表結構及其數據

1、導入導出表結構（兩種方法）

目標表中導出表結構：

db2look -d devdb47 -e -a -x -i db2inst1 -w db21234 -o devdb47.sql 

導入到使用表：

db2 -tvf devdb47.sql  

由于導出的數據可能不會應用到相同的數據庫，所以必須先修改devdb47.sql文件中數據庫名稱

vi /home/db2inst1/devdb47     將devdb47修改為目前的數據庫名稱

2、使用工具導出表結構 SqlDbx      后再目前數據庫操作表結構

導出：

導入：

3、導出 導入表數據

導出（備份表內容）：

導出全部數據：（只導出表數據  未導出表結構）

db2move devdb47 EXPORT    

導出部分表：(含IP、dim、ods的所有表)

db2move devdb47 EXPORT -tn IP*,DIM*,ODS* -tc db2inst1 -l /home/db2inst1

導單表：

db2move devdb47 EXPORT -tn DIM_GAME_RESULT -tc db2inst1 -l /home/db2inst1/

導多表：

db2move devdb47 EXPORT -tn ODS_BAC_ROUND_RESULT_COMP,ODS_BAC_ROUND_RESULT_DETAIL -tc db2inst1 -l /home/db2inst1/game

導入（還原表內容）:

db2move devdb47  IMPORT      （較慢）

db2move devdb47 LOAD -lo INSERT -l /home/db2inst1/  （較快）

此時就將未指定generated always選項的identity列 的數據導入了數據庫，但要所有數據相同還需導入指定了generated always選項的identity列。

3、恢復指定了generated always選項的identity列 需要結合identityoverride選項進行load導入

導出：db2move devdb47 EXPORT -tn ODS_ACCOUNT_BOOK_HISTORY -tc db2inst1 -l /home/db2inst1 

#可以單獨在導出，也可以直接使用已經導出的數據

導入：db2 "LOAD FROM tab98.ixf OF ixf modified BY identityoverride INSERT INTO acct.ODS_ACCOUNT_BOOK_HISTORY"

# tab98.ixf 是導出的ixf備份文件

導入成功后需要手動更新目標表中的identity字段的值。以保障下次寫入數據的連續性

"alter table acct.ODS_ACCOUNT_BOOK_HISTORY alter column history_id restart with 352120"

其中tab1.ixf 為備份導出的ixf格式文件    identityoverride（將數據導入到目標表中，指定使用輸入文件中標識列的值） 如要生成新的標識列則何以使用identitygnore  如下：

db2 "LOAD FROM tab1.ixf OF ixf modified BYidentitygnore INSERT INTO acct.ODS_ACCOUNT_BOOK_HISTORY

4、在進行導入數據其中有序列的列需要修改序列初始值（每次導入數據之前必須查看）

db2 select prevval for SEQ.SEQ_IP_ID from sysibm.sysdummy1 

#查看序列的當前值

db2 alter sequence SEQ.SEQ_AGENT_ID restart with 5000649

#修改序列的起始值

db2 values next value for SEQ.SEQ_AGENT_ID

#序列的下一個值（執行就會到下一個值）

此時可以對主庫進行操作，查看從庫是否同步

SELECT max(OP_ID) FROM U_OPERATOR

查看最大值

select NEXT VALUE for MAMA.SEQ_U_OPERATOR_OP_ID from sysibm.sysdummy1 

查看下一個值

alter sequence MAMA.SEQ_U_OPERATOR_OP_ID restart with 126

修改現在起始值

=====================================================================================================

=====================================================================================================

(HADR) 復制的操作：

高可用性災難恢復 (HADR) 使用數據庫日志將數據從主數據庫復制到備用數據庫。在備用數據庫上重放日志時，某些活動可能會導致備用數據庫落后于主數據庫。某些活動要進行大量記錄，它們生成的大量日志文件可能會導致存儲問題。雖然使用日志將數據復制到備用數據庫是可用性策略的核心，但記錄本身可能會對解決方案的可用性產生負面影響。合理設計維護策略，配置系統以盡可能降低日志記錄的負面影響，并允許日志記錄保護您的事務數據。

• 數據定義語言（DDL）  CREATE  ALTER  DROP TRUNCATE  COMMENT  RENAME   不需要commit

• 數據操作語言（DML） SELECT  INSERT  UPDATE  DELETE  MERGE  CALL  EXPLAIN PLAN LOCK TABLE  需要commit

• 緩沖池操作

• 表空間操作

• 聯機重組  詳細記錄所有操作

• 脫機重組  通常按幾百或幾千個受影響的行來記錄操作

• 存儲過程和用戶定義的函數（UDF）的元數據（但不是相關對象或庫文件）

• 聯機重組過程中，詳細記錄所有操作。結果，HADR 可以復制操作，而不會使備用數據庫比它在進行更多典型數據庫更新時更加遠遠地落在后面。但是，由于生成大量日志記錄，所以此行為可能對系統產生較大影響。

  如果未如聯機重組那樣大量地記錄脫機重組，通常按幾百或幾千個受影響的行來記錄操作。這意味著備用數據庫將落后，因為它等待每個日志記錄，然后立刻重放許多更新。如果脫機重組是非集群的，那么在整個重組操作之后生成單一日志記錄。此方式在最大程度上影響備用數據庫與主數據庫保持同步的功能。備用數據庫從主數據庫接收日志記錄之后，將執行整個重組過程。

  HADR 不復制存儲過程、UDF 對象和庫文件。必須在主數據庫和備用數據庫中相同路徑上創建文件。如果備用數據庫無法找到引用的對象或庫文件，那么備用數據庫上的存儲過程或 UDF 調用將失敗
  

  (HADR) 不復制的操作：

  高可用性災難恢復 (HADR) 使用數據庫日志將數據從主數據庫復制到備用數據庫。主數據庫允許不進行日志記錄的操作，但不會將此類操作復制到備用數據庫。如果要在備用數據庫中反映未日志記錄的操作（例如，對歷史記錄文件的更新），那么必須執行額外的步驟來實現此目的。

  以下是一些情況示例，在這些情況下，不會將主數據庫上的操作復制到備用數據庫：

  • 在指定了 NOT LOGGED INITIALLY 選項的情況下創建的表不會被復制。在 HADR 備用數據庫接管主數據庫后嘗試訪問這樣的表將導致錯誤。

  • 將復制所有已進行日志記錄的 LOB 列。將不會復制未進行日志記錄的 LOB 列。但是，在備用數據庫上將為它們分配空間，將二進制的零作為該列的值。

  • 不復制使用 UPDATE DATABASE CONFIGURATION（更新數據庫配置） 和 UPDATE DATABASE MANAGER CONFIGURATION（更新數據庫管理配置） 命令對數據庫配置所作的更新。

  • 不復制數據庫配置參數和數據庫管理器配置參數。

  • 對于用戶定義的函數（UDF）來說，不復制對數據庫外部的對象（例如相關的對象和庫文件）所作的更改。您需要通過其他方法在備用數據庫上對它們進行設置。

  • 不會自動地將恢復歷史記錄文件（db2rhist.asc）以及對其所作的更改從主數據庫復制到備用數據庫。

    通過發出具有 REPLACE HISTORY FILE 選項的 RESTORE DATABASE 命令，可以將歷史記錄文件的原始副本（從主數據庫的備份映像中獲取）放到備用數據庫上：

       RESTORE DB KELLY REPLACE HISTORY FILE

    初始化 HADR 并接著對主數據庫執行備份活動后，備用數據庫上的歷史記錄文件就已過期。但是，每個備份映像中都存儲了歷史記錄文件的一個副本。通過使用以下命令從備份映像中抽取歷史記錄文件，可以更新備用數據庫上的歷史記錄文件：

       RESTORE DB KELLY HISTORY FILE

    請不要使用正規操作系統命令將數據庫目錄中的歷史記錄文件從主數據庫復制到備用數據庫。進行復制時，如果主數據庫正在更新歷史記錄文件，那些文件就會損壞。

    如果執行接管操作并且備用數據庫有最新的歷史記錄文件，那么對新的主數據庫執行的備份和復原操作將在歷史記錄文件中生成新記錄，并且與原始主數據庫上生成的記錄完全混合。如果歷史記錄文件過期或者缺少條目，那么可能無法進行自動增量復原；而是，您將需要執行手動增量復原操作。

=========================================================================================================

=========================================================================================================

HADR的同步方式：

目前使用的是： SUPERASYNC （超級異步）

#db2 update db cfg for devdb47 using hadr_syncmode SUPERASYNC

1、SYNC（同步） #當日志寫入到主數據庫，且主收到備庫應答，已經寫入到備庫，則成功，確保主 備同時存儲

#此方式將最大可能地避免事務丟失，但使用此方式會導致事務響應時間最長，

2、NEARSYNC（接近同步）#當日志寫入到主數據庫，且主收到備庫應答，已經寫入到備庫，則成功，確保主 備同時存儲僅當兩處同時發生故障，并且目標位置未將接收到的所有日志數據轉移至非易失性存儲器時，才會出現數據的丟失

此方式具有比同步方式更短的事務響應時間，但針對防止事務丟失的能力也相對較低

3、ASYNC（異步）#僅當日志記錄已寫入主數據庫上的日志文件，而且已將這些記錄傳遞給主系統主機的 TCP 層時，才認為日志寫操作是成功的，不用等待備庫的確認。

4、SUPERASYNC（超級異步）#HADR 對永遠不會處于對等狀態或斷開連接的對等狀態，一旦數據寫入主 就認為是成功

具有最短的事務響應時間，但如果主系統發生故障，那么丟失事務的可能性也最大。如果您不希望事務因為網絡中斷或擁塞而導致阻塞或經歷較長的響應時間，那么此方式很有用

HADR同步的幾中狀態：