1、Informix 11.5 高可用集群技術及應用實現本文主要介紹了 Informix 11.5 中提供的高可用集群技術及其安裝、配置、管理的基本方法，各種高可用集群技術的選擇及應用場景，希望能夠使讀者能夠對 Informix 11.5 高可用集群技術有一個比較全面的了解。概述用戶的關鍵業務系統，特別是 OLTP 系統，都要求提供 24X7 不間斷的應用服務，這就要求數據庫系統能夠提供強大的高可用能力。這種能力不僅僅體現在主機及備機的接管方面，同時要能夠提供遠程容災能力，以及本地的負載均衡能力。針對上述對數據庫的要求，Informix 從版本 6 開始， 就提供了 HDR 技術，它是通過數據庫的

2、事務日志的方式實現了主、備機互相接管的功能，當主機工作時，備機提供只讀功能，因此，備機可以提供查詢、報表等功能，實現負載分擔的功能，當主機發生故障，備機會自動接管，實現主機及備機的接管功能。從 Informix 7.2.2 版本開始，Informix 數據庫提供了 ER(Enterprise Replication) 數據庫復制技術，它也是通過讀取數據庫日志的方式實現數據同步功能，當源數據庫數據發生變化后，Informix 數據庫通過讀取數據庫日志，將變化的數據及時同步到目標數據庫，采用 ER 的方式，和 HDR 不同，HDR 數據庫的接管是基于數據庫服務器的，也就是它的作用范圍是基于整個實例

3、的，而 ER 的作用范圍是作用于一個表，你可以靈活定義需要復制哪些數據列及數據行，而且可以靈活定義數據復制的方式，是采用主從方式、匯總方式還是雙向復制方式。從 Informix 11 開始，Informix 數據庫提供了 SDS(Shared Disk Secondary)、RSS(Remote Standalone Secondary)、CLR(Continuous Log Restore) 等高可用集群技術，提供了更加強大的高可用能力。從 Informix 11.5 開始，HDR、SDS、RSS 備機都支持讀寫能力，提供了更強大的負載均衡能力。同時，從 Informix 11.5 開始，I

4、nformix 還提供了 Connection Manager 功能部件，它可以提供 SLA(Service Level Agreement) 功能，更好地實現負載均衡的能力，同時提供了 FOC(Fail Over Connection) 功能，實現透明故障接管能力，而且，所有這些對客戶端應用來說是透明的。通過不斷的發展與創新，Informix 提供了業界領先的高可用集群技術。下邊，我們就具體講述一下 Informix 高可用集群技術特點、使用范圍及技術實現，希望讀者能夠對它有一個更全面的理解。HDR 技術高可用性數據復制 HDR 技術，從 Informix 6 版本就開始提供，它是采用一主、

5、一備方式，通過讀取數據庫邏輯日志方式，實現主備機互相切換功能。在 Informix 11.5 之前， HDR 備機支持只讀方式，我們通常會通過備機來完成數據查詢、報表功能，分擔主機系統的壓力。從 Informix 11.5 開始， HDR 備機支持讀寫操作，提供了更靈活的功能。 HDR 方式通常用來提供高可用性及 hot standby 功能。HDR 工作的基本原理圖 1. HDR 工作原理示例圖如圖中所示，當主數據庫服務器開始將共享內存中的邏輯日志緩沖區的內容刷新到磁盤上的邏輯日志時，數據庫服務器也將邏輯日志緩沖區的內容復制到主數據庫服務器上的數據復制緩沖區。然后主數據庫服務器將這些邏輯日志

6、記錄發送至 HDR 輔助數據庫服務器。HDR 輔助數據庫服務器將來自主數據庫服務器的邏輯日志記錄接收到共享內存接收緩沖區（數據庫服務器自動將接收緩沖區調節至適當的大小以適合正在發送的數據量）。然后輔助數據庫服務器在整個邏輯恢復中應用邏輯日志記錄 , ，并將這些記錄應用到其自己的數據庫空間。HDR 數據復制支持同步或異步兩種方式。 ONCONFIG 配置參數 DRINTERVAL 的值確定數據庫服務器使用同步更新還是異步更新。如果將 DRINTERVAL 設置為 -1，那么對 HDR 輔助服務器的數據復制同步發生。一旦主數據庫服務器將邏輯日志緩沖區內容寫入 HDR 緩沖區，它會將那些記錄從緩沖區

7、發送至 HDR 輔助數據庫服務器。僅當主數據庫服務器接收到來自 HDR 輔助數據庫服務器的確認（已收到記錄）之后，主數據庫服務器上的邏輯日志緩沖區清倉才會完成。使用同步更新時，如果發生故障，那么在主數據庫服務器上提交的事務在 HDR 輔助數據庫服務器上不會仍未提交或部分提交。如果您將 DRINTERVAL 設置為除 -1 以外的任何值，那么數據復制將針對 HDR 輔助服務器異步發生。主數據庫服務器在將邏輯日志緩沖區內容復制到 HDR 緩沖區之后會清倉邏輯日志緩沖區。（與上述操作無關）當發生以下條件之一時，主數據庫服務器在整個網絡上發送 HDR 緩沖區的內容：HDR 緩沖區變滿。自上次將記錄發送

8、至輔助數據庫服務器以后，DRINTERVAL 配置參數在主數據庫服務器上指定的時間間隔已過去。該更新方法可以提供比同步更新更好的性能。但是，可能會丟失事務。HDR 處理數據復制的線程主數據庫服務器啟動專門的線程來支持數據復制。如圖 2 所示，主數據庫服務器上名為 drprsend 的線程將整個網絡上主服務器緩沖區的內容發送至輔助數據庫服務器上名為 drsecrcv 的線程。輔助數據庫服務器上名為 drsecapply 的線程將接收緩沖區的內容復制到恢復緩沖區。 logrecvr 線程對恢復緩沖區的內容執行邏輯恢復，將邏輯日志記錄應用到輔助數據庫服務器管理的數據庫空間。 OFF_RECVRY_T

9、HREADS 配置參數指定使用的 logrecvr 線程數。數據庫服務器啟動的其余線程是 drprping 和 drsecping 線程，它們負責發送和接收指示兩個數據庫服務器是否連接的消息。圖 2. HDR 數據復制線程示例圖HDR 主、備機之間采用半雙工通信協議，因此對網絡延遲非常敏感，通常要求網絡要非常穩定，同時距離支持有限，通常在同一個大樓里面。HDR 配置實現HDR 對硬件和操作系統要求：運行主數據庫服務器和輔助數據庫服務器的計算機必須相同（相同的供應商和體系結構）。運行主數據庫服務器和輔助數據庫服務器的計算機上的操作系統必須相同。運行主數據庫服務器和輔助數據庫服務器的硬件必須支持網

10、絡能力。分配給主數據庫服務器和輔助數據庫服務器的數據庫空間的磁盤空間量必須相等。磁盤空間類型是不相關的；您可以在兩個數據庫服務器上使用任何原始或格式化的空間組合。HDR 對數據庫和數據要求：數據庫必須將事務日志記錄打開。數據必須駐留在數據庫空間或 Sb 空間中。HDR 對配置參數的要求：以下 ONCONFIG 參數在每個數據庫服務器上都必須具有相同值：ROOTNAMEROOTOFFSETROOTPATHROOTSIZEMIRROROFFSETMIRRORPATHPHYSDBSPHYSFILELTAPEBLKLTAPESIZETAPEBLKTAPESIZELOGFILESLOGSIZEDYNAM

11、IC_LOGS數據庫服務器記錄邏輯日志文件的添加。在主服務器上動態添加的邏輯日志文件將在輔助服務器上自動復制。盡管輔助服務器上的 DYNAMIC_LOGS 值不起作用，請保持主服務器上 DYNAMIC_LOGS 與值的同步，以免它們切換角色。HDR 配置參數在復制對中的兩個數據庫服務器上必須設置為相同的值： DRAUTO DRINTERVAL DRTIMEOUTHDR 相關配置參數說明： DRAUTO：用來控制主服務器和 HDR 備用服務器在出現故障時的行為。其取值范圍如下 :o 0 表示 OFF = 不要在 HDR 環境中自動切換服務器類型。o 1 表示 RETAIN_TYPE = 在 HD

12、R 故障期間自動從輔助切換到標準。在重新啟動 HDR 時切換回輔助。o 2 表示 REVERSE_TYPE= 在 HDR 故障時自動從輔助切換到標準。在重新啟動 HDR 時切換到主要（并將原來的主要切換為輔助）。 DRIDXAUTO：指定如果 HDR 輔助服務器檢測到了毀壞的索引，主服務器是否要自動啟動索引復制。其取值范圍如下 :o 0 - 禁用自動索引修復o 1 - 啟用自動索引修復 DRINTERVAL：指定高可用性數據復制緩沖區的清倉之間的最大時間間隔（秒）。其取值范圍如下 :o = 0 - 異步更新o -1 - 同步更新 DRLOSTFOUND：指定 文件的路徑名。該文件包含當主數據庫

13、服務器遇到故障時在主數據庫服務器上提交但未在輔助數據庫服務器上提交的事務。如果在主數據庫服務器和輔助數據庫服務器之間同步發生更新（即，如果 DRINTERVAL 設置為 -1），那么此參數不適用。 DRTIMEOUT：出現網絡超時的時間，以秒為單位。 DRAUTO 使用該參數檢測故障轉移。其取值范圍如下 := 0 秒 , 缺省為 30 秒向集群中添加 HDR 備用服務器向集群添加一個 HDR 備用服務器的具體步驟：步驟1：準備 SQLHOSTS 文件在主服務器更新 SQLHOSTS 文件，同時在 HDR 備用服務器中更新：production onsoctcp server_1 prod_tc

14、p sds1 onsoctcp server_1 sds1_tcp hdr1 onsoctcp server_1 hdr1_tcp rss1 onsoctcp server_1 rss1_tcp clr1 onsoctcp server_1 clr1_tcp步驟2：配置 ONCONFIG 文件保證 HDR 備用服務器上的 DRAUTO、DRINTERVAL、DRTIMEOUT、與根 dbspace 相關的設置、與物理日志、邏輯日志相關的 ONCONFIG 配置參數同主服務器上保持一致。步驟3：備份主服務器在主服務器中，使用 0 級備份：ontape -s -L 0步驟4：將 HDR 備份服務器

15、注冊到主服務器在主服務器中，運行：onmode -d primary hdr步驟5：準備 HDR 備用服務器的磁盤HDR 備用服務器使用的存儲必須匹配主服務器的存儲（例如，必須匹配 dbspace 的數量、塊的數量、塊大小、路徑名和偏移量）。步驟6：恢復 HDR 備用服務器上的備份在 HDR 服務器上，執行 0 級備份的物理恢復：ontape -p Three questions will be asked. Answer as shown below: Continue restore? (y/n) y Do you want to back up the logs? (y/n) n Res

16、tore a level 1 archive (y/n) n步驟7：使 HDR 備用服務器進入 online 模式完成恢復后，HDR 備用服務器將進入 recovery 模式。運行以下命令：onmode -d secondary productionHDR 狀態監控onstat 命令每次執行 onstat 時顯示的頭信息均有字段指示數據庫服務器正在作為主數據庫服務器還是輔助數據庫服務器運行。以下示例為作為復制對中的主數據庫服務器并且處于聯機方式的數據庫服務器顯示頭信息：IBM Informix Dynamic Server Version 11.50.UC1 - On-Line (Prim)

17、- Up 00:00:59 - 105120 Kbytes以下示例顯示作為復制對中的 HDR 輔助數據庫服務器并且處于讀寫方式的數據庫服務器：IBM Informix Dynamic Server Version 11.50.UC1 - Updatable (Sec) - Up 00:00:59 - 105120 Kbytes以下示例顯示不包含在 HDR 中的數據庫服務器的標題。該數據庫服務器的類型為標準類型。IBM Informix Dynamic Server Version 11.50.UC1 - On-Line - Up 00:00:59 - 105120 Kbytesonstat -

18、g dri 命令要獲得完整的 HDR 監視信息，請執行 onstat -g dri 選項。顯示以下字段： 數據庫服務器類型（主類型、輔助類型或標準類型） HDR 狀態（打開或關閉） 成對的數據庫服務器 最后一個 HDR 檢查點 HDR 配置參數的值oncheck pr 命令如果您的數據庫服務器正在運行 HDR，那么保留頁面 PAGE_1ARCH 和 PAGE_2ARCH 將保存 HDR 用于同步主數據庫服務器和輔助數據庫服務器的檢查點信息。下圖中給出相關的 oncheck -pr 輸出示例。運行 HDR 的數據庫服務器的 oncheck -pr PAGE_1ARCH 輸出 :Validatin

19、g Informix Database Server reserved pages - PAGE_1ARCH & PAGE_2ARCH Using archive page PAGE_1ARCH. Archive Level 0 Real Time Archive Began 01/11/95 16:54:07 Time Stamp Archive Began 11913 Logical Log Unique Id 3 Logical Log Position b018 DR Ckpt Logical Log Id 3 DR Ckpt Logical Log Pos 80018 DR Last

20、 Logical Log Id 3 DR Last Logical Log Page 128使用 SMI 表 sysdri查詢 sysmaster 數據庫中的 sysdri 表，同樣可以獲得完整的 HDR 監視信息。 sysdri 表包含以下各列。列描述typeHDR 服務器類型stateHDR 服務器狀態name數據庫服務器名稱intvlHDR 緩沖區清空時間間隔timeout網絡超時lostfoundHDR lost+found 路徑名HDR 故障恢復HDR 的失敗是失去了復制對中數據庫服務器之間的連接。任一以下情況均可能導致數據復制失敗： 一個數據庫服務器的站點上發生災難性故障（如火災或

21、大地震） 連接兩個數據庫服務器的聯網電纜被破壞 一個數據庫服務器上的處理中延遲過長 輔助數據庫服務器上發生磁盤故障（未通過鏡像塊解決）HDR 故障的檢測數據庫服務器將以下任何一種情況解釋為 HDR 失敗： 超過了指定的超時值。在正常的 HDR 操作期間，數據庫服務器期待來自對中另一數據庫服務器的通信確認。對中的每個數據庫服務器都具有一個 ONCONFIG 參數 DRTIMEOUT，該參數指定秒數。如果來自對中另一數據庫服務器的確認沒有在 DRTIMEOUT 指定的秒數返回，那么數據庫服務器會假設發生了 HDR 失敗。 主 輔助對中的另一數據庫服務器未響應網絡上的定期消息傳遞（pinging）嘗

22、試。無論主數據庫服務器是否向輔助數據庫服務器發送任何記錄，兩個數據庫服務器均會互相 ping 。如果主要 輔助對的一個數據庫服務器沒有響應四個連續的 ping 嘗試，那么另一個數據庫服務器會假設發生了 HDR 失敗。當數據庫服務器檢測到 HDR 失敗時，它將寫一個消息到其消息日志（例如，DR: receive error）并關閉數據復制。如果發生了 HDR 失敗，那么兩個數據庫服務器之間的 HDR 連接將斷開，并且輔助數據庫服務器將保持只讀方式。如果輔助數據庫服務器在 high-availability data-replication 失敗后保持聯機狀態，并且 DRAUTO 配置參數設置為

23、1（RETAIN_TYPE），那么該數據庫服務器的類型將自動更改為標準。如果 DRAUTO 設置為 0（off），那么輔助數據庫服務器將頂事嘗試重新建立與主數據庫服務器的通信。如果 DRAUTO 設置為 2（REVERSE_TYPE），那么當舊的主服務器發生故障時（而非舊的主服務器重新啟動時），在連接結束時，輔助數據庫服務器將立即成為主數據庫服務器。RSS 技術從 Informix 11 開始，Informix 數據庫提供了 RSS 、SDS、CLR 技術，它擴展了以前 HDR 只支持主、備兩臺機器，系統可以支持多臺 RSS 、SDS 備機，進一步提高了高可用性。 Informix 11 提出

24、了一種新的通信方式 SMX(Server Multiplexer) 用來建立節點之間的網絡連接。 SMX 采用全雙工的通信協議，支持異步通信方式，在低速網絡上提供更好的通信連接，簡化了節點之間的通信管理，支持加密傳輸，同一個 SMX 連接可以支持多個內部功能傳輸。圖 3. SMX 通信示意圖RSS 自動啟動 SMX 通信方式。RSS 工作的基本原理為支持 RS 輔助服務器，主服務器要進行檢查以查看是否連接了 RS 輔助服務器，如果連接，那么將頁面復制到用于將該頁面發送到 RS 輔助服務器的日志高速緩存。圖 4. RSS 數據復制線程示意圖RSS_Send 線程將日志頁面傳輸到 RS 輔助服務器

25、。很有可能需要發送的下一頁不在日志高速緩存中。在該情況下，RSS_Send 線程將直接從磁盤讀取日志頁。 RSS_Send 線程與 SMX 交互，以使用全雙工方式發送數據。有了全雙工通信，線程在發送下一個緩沖區之前不等待來自 RS 輔助服務器的確認。在主服務器需要來自 RS 輔助服務器的確認之前最多可發送 32 個緩沖區傳輸。如果達到 32 個緩沖區的限制，那么發送線程將等待 RSS_Recv 線程接收來自 RS 輔助服務器的確認。在 RS 輔助服務器上，RSS_Recv 與 SMX 交互，以接收來自主服務器的日志頁。RSS 在很多方面都與 HDR 相似。將日志發送到 RSS 的方式與主服務器

26、將日志發送到 HDR 輔助服務器的方式很相似。但是，RSS 采用 SMX 異步通信框架，因此其對主服務器的影響達到最小。出于該原因，主服務器和 RSS 輔助服務器之間事務落實或檢查點均不是同步進行的。換句話說，不保證在主服務器上落實的任何事務也在同一時間在 RSS 輔助服務器上得到落實。因為 RSS 輔助服務器是異步進行更新的，所以 RSS 輔助服務器不能直接提升為主服務器。相反，它可以提升為 HDR 輔助服務器，然后可提升為主服務器。另外，HDR 輔助服務器可降級為 RS 輔助服務器。盡管 RS 輔助服務器與 HDR 輔助服務器類似，但有某些操作是 HDR 輔助服務器可執行但 RS 輔助服務

27、器卻不支持，例如： RS 輔助服務器不支持 SYNC 方式 RS 輔助服務器不支持 DRAUTO RS 輔助服務器不具有同步檢查點 RS 輔助服務器不能直接轉換為主服務器RSS 備用服務器的主要作用是提供災難恢復解決方案。如同在 HDR 中一樣，主服務器不斷將其所有的邏輯日志記錄發送給 RS 備用服務器，不過 RS 使用的異步方式。與 HDR 不同，通信使用全雙工協議。因此 RS 對網絡延遲不是很敏感，并且可以更容易駐留在一個較遠的地理位置。同時，如果節點間通信線路比較差的情況下，頁經常采用 RS 備用服務器方式。 RS 備用服務器的一個特點是主服務器并不和 RS 備用服務器同步檢查點，這一點

28、和 SD 和 HDR 服務器不同。因此不能立即替代主服務器；必須首先切換為一個 HDR 服務器。RSS 配置實現硬件和軟件需求RS 輔助服務器維護物理數據庫的完整副本。出于此原因，以下內容必須與主服務器相同： 運行數據庫服務器的計算機硬件 分配給數據庫空間的磁盤空間量 創建數據庫空間時使用的物理設備中的偏移量索引頁日志記錄（LOG_INDEX_BUILDS）在創建索引時，索引頁日志記錄將各頁寫入到邏輯日志，以使高可用性環境中各服務器之間的索引創建同步。要使用 RS 輔助服務器，必須啟用索引頁日志記錄。索引頁日志記錄將完整索引寫入到日志文件，然后將該日志文件異步地傳輸到輔助服務器。輔助服務器可以

29、是 RS 輔助服務器，也可以是 HDR 輔助服務器。然后，日志文件事務被讀入到輔助服務器上的數據庫，減少輔助服務器在恢復期間重新構建索引的需求。對于 RS 輔助服務器，主服務器不等待來自輔助服務器的確認，這允許對主服務器上索引的立即訪問。索引頁日志記錄是使用 onconfig 參數 LOG_INDEX_BUILDS 進行控制的。如果 LOG_INDEX_BUILDS 設置為 1（已啟用），那么在主服務器上構建索引然后將索引發送到輔助服務器。向集群中添加 RS 備用服務器向集群添加一個 RSS 備用服務器的具體步驟：步驟1：準備 SQLHOSTS 文件集群中的所有服務器必須具有針對其他服務器的

30、SQLHOSTS 條目。production onsoctcp server_1 prod_tcp sds1 onsoctcp server_1 sds1_tcp hdr1 onsoctcp server_1 hdr1_tcp rss1 onsoctcp server_1 rss1_tcp clr1 onsoctcp server_1 clr1_tcp步驟2：在主服務器上，啟用索引頁面日志記錄onmode -wf LOG_INDEX_BUILDS=1步驟3：在主服務器上，注冊新的RS備用服務器onmode -d add RSS rss1步驟4：對主服務器采取0級備份ontape -s -L 0

31、步驟5：在RS備用服務器中，恢復備份ontape -p Three questions will be asked. Answer as shown below: Continue restore? (y/n) y Do you want to back up the logs? (y/n) n Restore a level 1 archive (y/n) n步驟6：使RS備用服務器進入online模式onmode -d RSS myprimRSS 狀態監控onstat 命令每次執行onstat時顯示的頭信息均有字段指示數據庫服務器正在作為主數據庫服務器還是輔助數據庫服務器運行。以下示例顯示

32、作為復制對中的 RSS 輔助數據庫服務器并且處于讀寫方式的數據庫服務器：IBM Informix Dynamic Server Version 11.50.UC1 - Updatable (RSS)- Up 00:00:59 - 105120 Kbytes onstat -g rss 命令我們可以在主服務器和 RSS 節點中分別運行 onstat -g rss 命令查看 RSS 節點狀態。 在主服務器和 RSS 節點上的輸出稍有不同。在主服務器上運行 onstat -g rss 命令輸出如下： Local server type: Primary Index page logging stat

33、us: Enabled Index page logging was enabled at: 2007/02/20 18:10:01 Number of RSS servers: 3 RSS Server information: RSS Srv RSS Srv Connection Next LPG to send Supports name status status (log id,page) Proxy Writes cdr_ol_nag_1_c1 Active Connected 7,899 Y cdr_ol_nag_1_c2 Active Connected 7,899 Y其中：

34、Local server type：是 Primary 還是 RSS (remote standalone secondary) 服務器類型 Index page logging status： 顯示索引頁日志記錄狀態是否被激活 Index page logging was enabled at：顯示索引頁日志記錄激活的時間 Number of RSS servers：連接到主服務器上 RSS 服務器的數量 RSS Srv name: RSS 服務器的名稱 RSS Srv status: 顯示 RSS 服務器數否活動 Connection status：顯示 RSS 服務器是否已經連接 Nex

35、t LPG sent (log id, page)：最近發送的 LPG log ID and page Supports Proxy Writes：顯示輔助服務器是否可執行 update 操作，Y 代表支持，N 不支持在輔助服務器上運行 onstat -g rss 命令輸出如下：IBM Informix Dynamic Server Version 11.50.UC1 - Read-Only (RSS) - Up 00:05:18 - 55296 Kbytes Local server type: RSS Server Status : Active Source server name: c

36、dr_ol_nag_1 Connection status: Connected Last log page received(log id,page): 7,877其中： Local server type：是 Primary 還是 RSS (remote standalone secondary) 服務器類型 Server Status: 顯示 RSS 服務器是否活動 Source server name：主服務器名稱 Connection status：顯示 RSS 服務器是否已經連接 Last log page received (log id,page)：最近接受的 LPG log

37、ID and pageRSS 故障切換在高可用集群環境中，數據庫服務器主要包含下述三種工作方式：服務器方式說明標準方式不是數據復制系統的一部分。主要方式數據復制系統的主要方式。可以更新數據。輔助方式數據復制系統的輔助方式。無法更新數據，但是可以讀取數據。RSS 進行故障切換的基本原則： RSS 節點不能升級為主節點 DRAUTO 對 RSS 不起作用 RSS 節點可以轉換為 HDR 輔助節點 HDR 輔助節點可以轉變為 RSS 節點 RSS 節點可以轉換為 standard nodeRSS 故障切換的基本方法及形式：將 RSS 節點升級為 HDR 輔助節點 :onmode d secondar

38、y 將 RSS 節點轉換為標準節點 :onmode d standard將 HDR 輔助節點裝換為 RSS 節點 :onmode d RSS 除去 RSS 節點 :onmode -d delete RSS rss_servernameSDS 技術與 HDR、RSS 不同，SDS 采用和主機共享磁盤方式，避免了數據重復存儲的問題，節省了空間，同時安裝、配置更加簡單。而且，當主機發生故障后，它可以快速實現接管，另外，我們可以非常容易地配置多個 SDS，可以實現了負載均衡的功能。由于 SD 備用節點利用了主服務器的磁盤并且可以輕松快速地啟動，因而非常適合規模擴展場景，由于 SD 備用服務器非常接近主

39、服務器（即它們共享相同的磁盤），因此最適合在主服務器遇到問題時作為故障轉移服務器。SDS 工作的基本原理所有輔助服務器類型都使用日志從主服務器復制數據。對于 HDR 輔助服務器和 RS 輔助服務器可通過生成日志時使主服務器將其所有邏輯日志記錄發送到輔助服務器，從而在輔助服務器上復制對主服務器所作的更新。 HDR 輔助服務器和 RS 輔助服務器接收在主服務器上生成的邏輯日志記錄，并將這些記錄應用到其自己的數據庫空間。對于 SD 輔助服務器，如圖所示，同 HDR 輔助服務器和 RS 輔助服務器不同，主服務器不是將整個日志進行發送，而只是將邏輯日志頁的日志位置發送到 SD 輔助服務器。通過使用從主服

40、務器接收到的日志位置，SD 輔助服務器從磁盤讀取邏輯日志頁，并將其應用于內存數據緩沖區。圖 5. SDS 數據復制示意圖SD 輔助服務器不會向共享磁盤塊中寫任何東西，不會將共享內存的數據刷新到磁盤，即使是發生 checkpoint 操作也一樣。如果 SD 輔助服務器需要刷新共享內存數據，他們會備寫到臨時的 paging file 中，直到下一次 checkpoint 操作才清空 paging file 。同時，如下圖所示，主服務器不會清倉共享內存中的數據頁，直到確認 SDS 不在需要該數據頁才會清倉到磁盤上。下圖顯示了啟動 SD 輔助服務器的基本過程：SD 輔助服務器首先創建到主服務器的 SM

41、X 連接，之后，SD 輔助服務器向主服務器發出 checkpoint 請求，主服務器響應 SD 輔助服務器的 checkpoint 請求，并將相應 LSN 發送給 SD 輔助服務器，SD 輔助服務器啟動必要的恢復操作，之后，主服務器開始不斷向 SD 輔助服務器發送當前的 LSN，SD 輔助服務器也開始不斷向主服務器發送 ACK 確認信息。圖 6. SDS 數據復制工作原理示意圖SDS 配置實現輔助服務器的硬件和軟件需求除了磁盤需求（與主服務器共享），硬件和軟件需求與 HDR 輔助服務器的需求相同。此外，具有數據庫服務器的計算機之間必須共享主磁盤系統。這表示從 SD 輔助服務器到數據庫空間的路徑

42、必須與主服務器的數據庫空間路徑相同。SDS 相關配置參數說明 SDS_ENABLE：用來啟用 SD 輔助服務器功能。您必須在主服務器及 SD 輔助服務器中將 SDS_ENABLE 都設置為 1（啟用），才能啟用 SD 輔助服務器功能。其取值范圍：o 0 - 禁用 SDS 功能o 1 - 啟用 SDS 功能 SDS_PAGING： 指定了兩個要作為緩存器調頁文件的文件的位置。如果未設置 SDS_PAGING，SD 輔助服務器可能無法啟動。在 SD 輔助服務上設置該值。其取值范圍：， SDS_TEMPDBS：指定 SD 輔助服務器用于動態創建臨時數據庫空間的信息。為了啟動 SD 輔助服務器，SD

43、輔助服務器的 ONCONFIG 文件中至少出現一次 SDS_TEMPDBS，最多可以配置為 16 SDS_TEMPDBS 條目。在 SD 輔助服務上設置該值，主服務器上不使用 SDS_TEMPDBS 。其取值范圍：、示例：SDS_TEMPDBS sdstmpdbs1, /work/dbspaces/sdstmpdbs1,2,0,16000 SDS_TIMEOUT：該配置參數用于主服務器確定要從 SD 服務器獲得確認需要等待多長時間，如果沒有獲得確認，主服務器將停止 SD 服務器。在主服務器上設置該值。其取值范圍：= 0 秒，默認值為 20 秒。向集群中添加 SD 備用服務器向集群添加一個 SD

44、S 備用服務器的具體步驟：步驟1：準備SQLHOSTS文件確保 SQHOSTS 文件在主服務器和 SDS 節點都具有另一個服務器的條目：production onsoctcp server_1 prod_tcp sds1 onsoctcp server_1 sds1_tcp hdr1 onsoctcp server_1 hdr1_tcp rss1 onsoctcp server_1 rss1_tcp clr1 onsoctcp server_1 clr1_tcp注意這里使用的組是可選的。步驟2：將主服務器設置為共享磁盤的所有者在主服務器中，運行：onmode -d set SDS primar

45、y myprim步驟3：配置SD備用服務器 確保以下參數匹配主服務器的 ONCONFIG：ROOTNAME、ROOTPATH、ROOTOFFSET、ROOTSIZE、PHYSDBS、PHYSFILE、LOGFILES 和 LOGSIZE 。 將 SDS_ENABLE 設置為 1 。 配置 SDS_PAGING 和 SDS_TEMPDBS 。例如：SDS_ENABLE 1 SDS_PAGING /ids/sds/dbspaces/page_1,/ids/sds/dbspaces/page_2 SDS_TEMPDBS sdstmpdbs1,/ids/sds/dbspaces/sdstmpdbs1,

46、2,0,16000 REDIRECTED_WRITES 1 TEMPTAB_NOLOG 1步驟4：啟動SD備用服務器oninitSDS 狀態監控onstat 命令每次執行onstat時顯示的頭信息均有字段指示數據庫服務器正在作為主數據庫服務器還是輔助數據庫服務器運行。以下示例顯示作為復制對中的 SDS 輔助數據庫服務器并且處于讀寫方式的數據庫服務器：IBM Informix Dynamic Server Version 11.50.UC1 - Updatable (SDS)- Up 00:00:59 - 105120 Kbytesonstat -g sds 命令您可以使用onstat -g s

47、ds命令來查看 SD 輔助服務器統計信息。 onstat 實用程序的輸出取決于實用程序是在主服務器還是在輔助服務器上運行。onstat-g sds 命令輸出基本包括： Local server type：是 Primary 還是 SDS (shared disk secondary) 服務器類型 Number of SDS servers：連接到主服務器上 SDS 服務器的數量 SDS Srv name: SDS 服務器的名稱 SDS Srv status: 顯示 SDS 服務器數否活動 Connection status：顯示 SDS 服務器是否已經連接 Last LPG sent (log

48、 id, page)：最近發送的 LPG log ID and page Supports Proxy Writes：顯示輔助服務器是否可執行 update 操作，Y 代表支持，N 不支持下邊是執行 onstat -g sds 命令的輸出：Local server type: Primary Number of SDS servers:1 SDS server information SDS srv SDS srv Connection Last LPG sent Supports name status status (log id,page) Proxy Writes C_151162 A

49、ctive Connected 554,4998使用 SMI 表查詢 syssrcsds 表可獲取關于主服務器上共享磁盤統計信息的信息。查詢 systrgsds 表可獲取關于輔助服務器上共享磁盤統計信息的信息。SDS 故障切換輔助服務器環境中的災難恢復在當前主服務器連接到新的主服務器時執行故障轉移當高可用性環境處于活動狀態時，新的主服務器將通知舊主服務器它將采取共享磁盤的所有權。然后，舊的主服務器將回滾所有打開的事務，并將其自身切換為輔助狀態。在舊的主服務器完成該過程之后，它將通知新的主服務器回滾完成。這將成為新的主服務器繼續操作的信號。可通過在新的主服務器上發出onmode -d set s

50、ds primary命令來執行此過程。在當前主服務器未連接到新的主服務器時執行故障轉移在此場景中，新舊主服務器之間的連接不存在。在這種情況下，我們需要強制執行轉換。這可通過發出onmode -d set sds primary force命令完成。僅當在確定原始主服務器不活動時才能發出該命令。因為強制關鍵字會使新的主服務器在不與舊主服務器通信的情況下成為源服務器，所以如果舊的主服務器仍然處于活動狀態，它很可能導致數據庫毀壞。當高可用性集群中的所有節點不可用時執行故障轉移這是在所有服務器出現故障而且未能啟動現有主服務器后嘗試故障轉移時的唯一問題。該問題的原因是主服務器必須能夠連接以啟動高可用性集

51、群中的輔助服務器。如果主服務器不處于活動狀態，那么無法建立連接，因此無法啟動輔助服務器。如果無法啟動輔助服務器，那么用于更改主服務器的 onmode 命令將不會起作用。要避免該問題，請使用 oninit -SDS=，其中 是新的主服務器上的 TCP 別名。這允許啟動現有輔助服務器，并使其能夠同時采取環境的所有權。僅當啟動集群內的第一個服務器時才能使用 oninit 命令的該選項。SDS 故障切換的基本方法及形式將 SD 輔助服務器提升為主服務器可通過在 SD 輔助服務器上發出以下命令來將 SD 輔助服務器轉換為主服務器：onmode -d set SDS primary 請注意：SD 輔助服務

52、器不能轉換為標準服務器。禁用 SD 輔助服務器環境中的主服務器可使用以下命令禁用主服務器：在主服務器上，輸入以下命令： onmode -d clear SDS primary 該命令將使主服務器成為標準服務器，并禁用共享磁盤環境。SD 輔助服務器環境中的災難恢復的建議如果主服務器發生故障，那么故障轉移的順序應該是： 轉移到 SD 輔助服務器 轉移到 HDR 輔助服務器 轉移到 RS 輔助服務器集群環境下災難恢復的各種方式對比可在任何類型的輔助服務器上運行 onmode -d make primary 命令以將該服務器提升為主服務器。下表說明了每個服務器類型是如何受到影響的。如果新的主服務器是：

53、那么該類型的對等服務器：受該方式的影響：SD 輔助服務器SD 輔助服務器連接到新的主服務器并繼續RS 輔助服務器連接到新的主服務器并繼續HDR 輔助服務器連接到新的主服務器并繼續舊的主服務器關閉HDR 輔助服務器SD 輔助服務器關閉RS 輔助服務器連接到新的主服務器并繼續HDR 主服務器取決于用戶操作RS 輔助服務器SD 輔助服務器關閉HDR 輔助服務器關閉RS 輔助服務器關閉CLR 技術有的時候，遠程災備服務器和主機服務器要實現物理隔離，或者數據網絡非常不穩定，這種情況下，Informix 11 提供了 CLR （Continuous Log Restore）技術，它是通過邏輯日志備份的方式

54、，將數據庫的邏輯日志人工傳送到遠程災備服務器，通過數據庫邏輯日志恢復的方式保持和主數據庫數據同步的方式。圖 7. CLR 數據復制工作原理示意圖CLR 方式，就是我們常說的 log shipping 方式，CLR 服務器一直處于 fast recover 狀態，不斷接收新的邏輯日志，當需要恢復時，執行 ontape l X 命令，數據庫會轉變為靜態模式，之后就可以正常使用了。CLR 方式，主要用于遠程災備服務器和主機服務器采用物理隔離，或者數據網絡非常不穩定的情況下實現災難恢復的場景。CLR 工作的基本原理主服務器通過定期或連續進行邏輯日志備份，并將日志備份數據手工的方式傳送到 CLR 服務器端， CLR 服務器不斷采用 ontape -l C 命令前滾日志， CLR 處于 logical roll-forward 模式，當需要使用 CLR 服務器時，采用 ontape l X 命令，數據庫會轉變為靜態模式，之后就可以正常使用了。CLR 配置實現向集群中添加CLR備用服務器向集群添加一個 CLR 備用服務器的具體步驟：步驟1：準備SQLHOSTS文件集群中的所有服務器必須具有針對其他服務器的 SQLHOSTS 條目。production onsoctcp server_1 prod_tcp sd