大家好，今天我們在這裏探討Informix數據庫的高可用技術。衆所周知，用戶的關鍵業務系統，特別是 OLTP 系統，都要求提供 24X7 不間斷的應用服務，這就要求數據庫系統能夠提供強大的高可用能力。這種能力不僅僅體現在主機及備機的接管方面，同時要能夠提供遠程容災能力，以及本地的負載均衡能力。 針對上述對數據庫的要求，Informix 從版本 6 開始， 就提供了 HDR（High Availability Data Replication） 技術，從 Informix 11 開始，Informix 數據庫提供了 SDS(Shared Disk Secondary)、RSS(Remote Standalone Secondary)、CLR(Continuous Log Restore) 等高可用集羣技術，提供了更加強大的高可用能力。尤其是從 Informix 11.5 開始其高可用技術發生了質的飛躍，HDR、SDS、RSS 備機都具備可讀可寫的能力，提供了更強大的負載均衡能力。 本研討會，我們就針對 Informix 高可用技術不同方案的特點、技術實現和使用範圍等方面與大家共同探討。
informix 的高可用技術SDS(Shared Disk Secondary)、RSS(Remote Standalone Secondary)、CLR(Continuous Log Restore) 分別適用的場景是那些呢？條件是什麼呢？
SDS是雙主機同時讀寫共享磁盤，一般用在大型聯機交易應用業務，和Oracle RAC相似。RSS是廣域網異步HDR，用在數據庫級的災備環境。CLR是在網絡不太好的情況下的脫機連續邏輯日誌的數據恢復，用於數據庫備份。
SDS共享磁盤方案，類似ORACLE RAC，提供高可用性和負載均衡情況，但是不具備存儲容災能力。提供快速的故障切換能力。 HDR，近距離雙機方案，一般使用於同機房、2機房、同城2中心的雙機方案，提供數據災備能力。當主機故障時，備機快速接管。 RSS，就是遠程容災方案，是在HDR基礎上提供的遠程容災方案，適用於異地方案，長距離數據同步方案，提供異步通信工作模式，對網絡帶寬要求低。適用於自然災害（地震、海嘯）等災難情況。 CLR 基於邏輯日誌的容災方案，對平臺無要求，離線工作方式。
Informix數據庫是在UNIX開發的，其名字的含義爲Information for unix，在UNIX系統上佔用內存少，效率高，尤其是聯機處理優勢明顯。實際上ORACLE RAC技術，雙機共享磁盤的同時可讀可寫，在當時是領先Informix的HDR的。但是從 Informix 11.5 開始，IBM加大了研發力度，其HDR、SDS、RSS 備機都具備可讀可寫的能力，提供了更強大的負載均衡能力。
Informix仍然是主流的關係型數據庫之一，只是Informix的使用很多場景不爲人知。Informix的獨特性--高效、穩定、靈活，使之Informix在電信、零售、銀行、保險、電力等行業有較多的客戶。從2001年IBM收購INFORMIX後，市場上沒有Informix的廣告，客戶感覺Informix在退出市場，其實不然。 關於Informix的高可用性方案，相比其他數據庫要完善。HDR已經有10多年的歷史了，DB2纔在過去2年時間內學習了INformix的HDR技術提供了類似的HDAR功能。 INformix的高可用性方案架構與其他數據庫不同，基於邏輯日誌的同步，鬆耦合架構。實施成本低，部署快速，依賴硬件少。
目前國內客戶對數據庫的高可用性的需求有：1、在同一機房內，雙主機同時可讀寫共享磁盤的數據庫，如Informix SDS（Oracle RAC）技術，能夠提供負載均衡。2、同城2機房中的數據庫複製，主機和磁盤爲2套，Informix HDR。3、異地數據庫複製，如Informix RSS。
Informix11.5 HDR 當客戶在主用服務器上進行數據庫寫操作，通過複製邏輯日誌的方式，同步備用數據庫；當客戶對備用數據庫進行寫操作時，這時備用數據庫當作主用服務器的Informix客戶端，先向主用服務器寫操作，主用服務器再把邏輯日誌同步到備用服務器上。這樣就保持了主備數據庫的數據一致性。
Informix的高可用性方案的架構是鬆耦合架構。有主、備機之分，主備機之前不共享內存和鎖。通過邏輯日誌的同步和恢復來進行數據的同步。主備機之間的數據有毫秒級別的延遲。
Informix HDR 支持同步、異步工作方式。當設置爲同步模式時，主服務器的寫操作事務需要待備機完成同步後才結束。這種工作模式，對性能有影響。在異步工作模式下，通過控制延遲。DRINTERVAL，DRTIMEOUT參數設置來控制數據延遲程度。
概述
用戶的關鍵業務系統，特別是 OLTP 系統，都要求提供 24X7 不間斷的應用服務，這就要求數據庫系統能夠提供強大的高可用能力。這種能力不僅僅體現在主機及備機的接管方面，同時要能夠提供遠程容災能力，以及本地的負載均衡能力。
針對上述對數據庫的要求，Informix 從版本 6 開始， 就提供了 HDR 技術，它是通過數據庫的事務日誌的方式實現了主、備機互相接管的功能，當主機工作時，備機提供只讀功能，因此，備機可以提供查詢、報表等功能，實現負載分擔的功能，當主機發生故障，備機會自動接管，實現主機及備機的接管功能。
從 Informix 7.2.2 版本開始，Informix 數據庫提供了 ER(Enterprise Replication) 數據庫複製技術，它也是通過讀取數據庫日誌的方式實現數據同步功能，當源數據庫數據發生變化後，Informix 數據庫通過讀取數據庫日誌，將變化的數據及時同步到目標數據庫，採用 ER 的方式，和 HDR 不同，HDR 數據庫的接管是基於數據庫服務器的，也就是它的作用範圍是基於整個實例的，而 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 開始，Informix 還提供了 Connection Manager 功能部件，它可以提供 SLA(Service Level Agreement) 功能，更好地實現負載均衡的能力，同時提供了 FOC(Fail Over Connection) 功能，實現透明故障接管能力，而且，所有這些對客戶端應用來說是透明的。通過不斷的發展與創新，Informix 提供了業界領先的高可用集羣技術。
下邊，我們就具體講述一下 Informix 高可用集羣技術特點、使用範圍及技術實現，希望讀者能夠對它有一個更全面的理解。
HDR 技術
高可用性數據複製 HDR 技術，從 Informix 6 版本就開始提供，它是採用一主、一備方式，通過讀取數據庫邏輯日誌方式，實現主備機互相切換功能。在 Informix 11.5 之前， HDR 備機支持只讀方式，我們通常會通過備機來完成數據查詢、報表功能，分擔主機系統的壓力。從 Informix 11.5 開始， HDR 備機支持讀寫操作，提供了更靈活的功能。 HDR 方式通常用來提供高可用性及 hot standby 功能。
HDR 工作的基本原理
圖 1. HDR 工作原理示例圖
如圖中所示，當主數據庫服務器開始將共享內存中的邏輯日誌緩衝區的內容刷新到磁盤上的邏輯日誌時，數據庫服務器也將邏輯日誌緩衝區的內容複製到主數據庫服務器上的數據複製緩衝區。然後主數據庫服務器將這些邏輯日誌記錄發送至 HDR 輔助數據庫服務器。
HDR 輔助數據庫服務器將來自主數據庫服務器的邏輯日誌記錄接收到共享內存接收緩衝區（數據庫服務器自動將接收緩衝區調節至適當的大小以適合正在發送的數據量）。然後輔助數據庫服務器在整個邏輯恢復中應用邏輯日誌記錄 , ，並將這些記錄應用到其自己的數據庫空間。
HDR 數據複製支持同步或異步兩種方式。 ONCONFIG 配置參數 DRINTERVAL 的值確定數據庫服務器使用同步更新還是異步更新。如果將 DRINTERVAL 設置爲 -1，那麼對 HDR 輔助服務器的數據複製同步發生。一旦主數據庫服務器將邏輯日誌緩衝區內容寫入 HDR 緩衝區，它會將那些記錄從緩衝區發送至 HDR 輔助數據庫服務器。僅當主數據庫服務器接收到來自 HDR 輔助數據庫服務器的確認（已收到記錄）之後，主數據庫服務器上的邏輯日誌緩衝區清倉纔會完成。使用同步更新時，如果發生故障，那麼在主數據庫服務器上提交的事務在 HDR 輔助數據庫服務器上不會仍未提交或部分提交。
如果您將 DRINTERVAL 設置爲除 -1 以外的任何值，那麼數據複製將針對 HDR 輔助服務器異步發生。主數據庫服務器在將邏輯日誌緩衝區內容複製到 HDR 緩衝區之後會清倉邏輯日誌緩衝區。（與上述操作無關）當發生以下條件之一時，主數據庫服務器在整個網絡上發送 HDR 緩衝區的內容：
- HDR 緩衝區變滿。
- 自上次將記錄發送至輔助數據庫服務器以後，DRINTERVAL 配置參數在主數據庫服務器上指定的時間間隔已過去。
該更新方法可以提供比同步更新更好的性能。但是，可能會丟失事務。
HDR 處理數據複製的線程
主數據庫服務器啓動專門的線程來支持數據複製。如圖 2 所示，主數據庫服務器上名爲 drprsend 的線程將整個網絡上主服務器緩衝區的內容發送至輔助數據庫服務器上名爲 drsecrcv 的線程。
輔助數據庫服務器上名爲 drsecapply 的線程將接收緩衝區的內容複製到恢復緩衝區。 logrecvr 線程對恢復緩衝區的內容執行邏輯恢復，將邏輯日誌記錄應用到輔助數據庫服務器管理的數據庫空間。 OFF_RECVRY_THREADS 配置參數指定使用的 logrecvr 線程數。
數據庫服務器啓動的其餘線程是 drprping 和 drsecping 線程，它們負責發送和接收指示兩個數據庫服務器是否連接的消息。
圖 2. HDR 數據複製線程示例圖
HDR 主、備機之間採用半雙工通信協議，因此對網絡延遲非常敏感，通常要求網絡要非常穩定，同時距離支持有限，通常在同一個大樓裏面。
HDR 配置實現
HDR 對硬件和操作系統要求：
- 運行主數據庫服務器和輔助數據庫服務器的計算機必須相同（相同的供應商和體系結構）。
- 運行主數據庫服務器和輔助數據庫服務器的計算機上的操作系統必須相同。
- 運行主數據庫服務器和輔助數據庫服務器的硬件必須支持網絡能力。
- 分配給主數據庫服務器和輔助數據庫服務器的數據庫空間的磁盤空間量必須相等。磁盤空間類型是不相關的；您可以在兩個數據庫服務器上使用任何原始或格式化的空間組合。
HDR 對數據庫和數據要求：
- 數據庫必須將事務日誌記錄打開。
- 數據必須駐留在數據庫空間或 Sb 空間中。
HDR 對配置參數的要求：
以下 ONCONFIG 參數在每個數據庫服務器上都必須具有相同值：
- ROOTNAME
- ROOTOFFSET
- ROOTPATH
- ROOTSIZE
- MIRROROFFSET
- MIRRORPATH
- PHYSDBS
- PHYSFILE
- LTAPEBLK
- LTAPESIZE
- TAPEBLK
- TAPESIZE
- LOGFILES
- LOGSIZE
- DYNAMIC_LOGS
數據庫服務器記錄邏輯日誌文件的添加。在主服務器上動態添加的邏輯日誌文件將在輔助服務器上自動複製。儘管輔助服務器上的 DYNAMIC_LOGS 值不起作用，請保持主服務器上 DYNAMIC_LOGS 與值的同步，以免它們切換角色。
HDR 配置參數在複製對中的兩個數據庫服務器上必須設置爲相同的值：
- DRAUTO
- DRINTERVAL
- DRTIMEOUT
HDR 相關配置參數說明：
- DRAUTO：用來控制主服務器和 HDR 備用服務器在出現故障時的行爲。其取值範圍如下 :
- 0 表示 OFF = 不要在 HDR 環境中自動切換服務器類型。
- 1 表示 RETAIN_TYPE = 在 HDR 故障期間自動從輔助切換到標準。在重新啓動 HDR 時切換回輔助。
- 2 表示 REVERSE_TYPE= 在 HDR 故障時自動從輔助切換到標準。在重新啓動 HDR 時切換到主要（並將原來的主要切換爲輔助）。
- DRIDXAUTO：指定如果 HDR 輔助服務器檢測到了毀壞的索引，主服務器是否要自動啓動索引複製。其取值範圍如下 :
- 0 - 禁用自動索引修復
- 1 - 啓用自動索引修復
- DRINTERVAL：指定高可用性數據複製緩衝區的清倉之間的最大時間間隔（秒）。其取值範圍如下 :
- >= 0 - 異步更新
- -1 - 同步更新
- DRLOSTFOUND：指定 dr.lostfound.timestamp 文件的路徑名。該文件包含當主數據庫服務器遇到故障時在主數據庫服務器上提交但未在輔助數據庫服務器上提交的事務。如果在主數據庫服務器和輔助數據庫服務器之間同步發生更新（即，如果 DRINTERVAL 設置爲 -1），那麼此參數不適用。
- DRTIMEOUT：出現網絡超時的時間，以秒爲單位。 DRAUTO 使用該參數檢測故障轉移。其取值範圍如下 :>= 0 秒 , 缺省爲 30 秒
向集羣中添加 HDR 備用服務器
向集羣添加一個 HDR 備用服務器的具體步驟：
步驟1：準備 SQLHOSTS 文件
在主服務器更新 SQLHOSTS 文件，同時在 HDR 備用服務器中更新：
|
1 2 3 4 5 |
|
步驟2：配置 ONCONFIG 文件
保證 HDR 備用服務器上的 DRAUTO、DRINTERVAL、DRTIMEOUT、與根 dbspace 相關的設置、與物理日誌、邏輯日誌相關的 ONCONFIG 配置參數同主服務器上保持一致。
步驟3：備份主服務器
在主服務器中，使用 0 級備份：
|
1 |
|
步驟4：將 HDR 備份服務器註冊到主服務器
在主服務器中，運行：
|
1 |
|
步驟5：準備 HDR 備用服務器的磁盤
HDR 備用服務器使用的存儲必須匹配主服務器的存儲（例如，必須匹配 dbspace 的數量、塊的數量、塊大小、路徑名和偏移量）。
步驟6：恢復 HDR 備用服務器上的備份
在 HDR 服務器上，執行 0 級備份的物理恢復：
|
1 2 3 4 5 |
|
步驟7：使 HDR 備用服務器進入 online 模式
完成恢復後，HDR 備用服務器將進入 recovery 模式。運行以下命令：
|
1 |
|
HDR 狀態監控
onstat – 命令
每次執行 onstat 時顯示的頭信息均有字段指示數據庫服務器正在作爲主數據庫服務器還是輔助數據庫服務器運行。
以下示例爲作爲複製對中的主數據庫服務器並且處於聯機方式的數據庫服務器顯示頭信息：
|
1 2 |
|
以下示例顯示作爲複製對中的 HDR 輔助數據庫服務器並且處於讀寫方式的數據庫服務器：
|
1 2 |
|
以下示例顯示不包含在 HDR 中的數據庫服務器的標題。該數據庫服務器的類型爲標準類型。
|
1 2 |
|
onstat -g dri 命令
要獲得完整的 HDR 監視信息，請執行 onstat -g dri 選項。顯示以下字段：
- 數據庫服務器類型（主類型、輔助類型或標準類型）
- HDR 狀態（打開或關閉）
- 成對的數據庫服務器
- 最後一個 HDR 檢查點
- HDR 配置參數的值
oncheck – pr 命令
如果您的數據庫服務器正在運行 HDR，那麼保留頁面 PAGE_1ARCH 和 PAGE_2ARCH 將保存 HDR 用於同步主數據庫服務器和輔助數據庫服務器的檢查點信息。下圖中給出相關的 oncheck -pr 輸出示例。
運行 HDR 的數據庫服務器的 oncheck -pr PAGE_1ARCH 輸出 :
|
1 2 3 4 5 6 |
|
使用 SMI 表 sysdri
查詢 sysmaster 數據庫中的 sysdri 表，同樣可以獲得完整的 HDR 監視信息。 sysdri 表包含以下各列。
| 列 | 描述 |
|---|---|
| type | HDR 服務器類型 |
| state | HDR 服務器狀態 |
| name | 數據庫服務器名稱 |
| intvl | HDR 緩衝區清空時間間隔 |
| timeout | 網絡超時 |
| lostfound | HDR lost+found 路徑名 |
HDR 故障恢復
HDR 的失敗是失去了複製對中數據庫服務器之間的連接。任一以下情況均可能導致數據複製失敗：
- 一個數據庫服務器的站點上發生災難性故障（如火災或大地震）
- 連接兩個數據庫服務器的聯網電纜被破壞
- 一個數據庫服務器上的處理中延遲過長
- 輔助數據庫服務器上發生磁盤故障（未通過鏡像塊解決）
HDR 故障的檢測
數據庫服務器將以下任何一種情況解釋爲 HDR 失敗：
- 超過了指定的超時值。
在正常的 HDR 操作期間，數據庫服務器期待來自對中另一數據庫服務器的通信確認。對中的每個數據庫服務器都具有一個 ONCONFIG 參數 DRTIMEOUT，該參數指定秒數。如果來自對中另一數據庫服務器的確認沒有在 DRTIMEOUT 指定的秒數返回，那麼數據庫服務器會假設發生了 HDR 失敗。 - 主 － 輔助對中的另一數據庫服務器未響應網絡上的定期消息傳遞（pinging）嘗試。
無論主數據庫服務器是否向輔助數據庫服務器發送任何記錄，兩個數據庫服務器均會互相 ping 。如果主要 － 輔助對的一個數據庫服務器沒有響應四個連續的 ping 嘗試，那麼另一個數據庫服務器會假設發生了 HDR 失敗。
當數據庫服務器檢測到 HDR 失敗時，它將寫一個消息到其消息日誌（例如，DR: receive error）並關閉數據複製。如果發生了 HDR 失敗，那麼兩個數據庫服務器之間的 HDR 連接將斷開，並且輔助數據庫服務器將保持只讀方式。
如果輔助數據庫服務器在 high-availability data-replication 失敗後保持聯機狀態，並且 DRAUTO 配置參數設置爲 1（RETAIN_TYPE），那麼該數據庫服務器的類型將自動更改爲標準。如果 DRAUTO 設置爲 0（off），那麼輔助數據庫服務器將頂事嘗試重新建立與主數據庫服務器的通信。如果 DRAUTO 設置爲 2（REVERSE_TYPE），那麼當舊的主服務器發生故障時（而非舊的主服務器重新啓動時），在連接結束時，輔助數據庫服務器將立即成爲主數據庫服務器。
RSS 技術
從 Informix 11 開始，Informix 數據庫提供了 RSS 、SDS、CLR 技術，它擴展了以前 HDR 只支持主、備兩臺機器，系統可以支持多臺 RSS 、SDS 備機，進一步提高了高可用性。 Informix 11 提出了一種新的通信方式 SMX(Server Multiplexer) 用來建立節點之間的網絡連接。 SMX 採用全雙工的通信協議，支持異步通信方式，在低速網絡上提供更好的通信連接，簡化了節點之間的通信管理，支持加密傳輸，同一個 SMX 連接可以支持多個內部功能傳輸。
圖 3. SMX 通信示意圖
RSS 自動啓動 SMX 通信方式。
RSS 工作的基本原理
爲支持 RS 輔助服務器，主服務器要進行檢查以查看是否連接了 RS 輔助服務器，如果連接，那麼將頁面複製到用於將該頁面發送到 RS 輔助服務器的日誌高速緩存。
圖 4. RSS 數據複製線程示意圖
RSS_Send 線程將日誌頁面傳輸到 RS 輔助服務器。很有可能需要發送的下一頁不在日誌高速緩存中。在該情況下，RSS_Send 線程將直接從磁盤讀取日誌頁。 RSS_Send 線程與 SMX 交互，以使用全雙工方式發送數據。有了全雙工通信，線程在發送下一個緩衝區之前不等待來自 RS 輔助服務器的確認。在主服務器需要來自 RS 輔助服務器的確認之前最多可發送 32 個緩衝區傳輸。如果達到 32 個緩衝區的限制，那麼發送線程將等待 RSS_Recv 線程接收來自 RS 輔助服務器的確認。
在 RS 輔助服務器上，RSS_Recv 與 SMX 交互，以接收來自主服務器的日誌頁。
RSS 在很多方面都與 HDR 相似。將日誌發送到 RSS 的方式與主服務器將日誌發送到 HDR 輔助服務器的方式很相似。但是，RSS 採用 SMX 異步通信框架，因此其對主服務器的影響達到最小。出於該原因，主服務器和 RSS 輔助服務器之間事務落實或檢查點均不是同步進行的。換句話說，不保證在主服務器上落實的任何事務也在同一時間在 RSS 輔助服務器上得到落實。因爲 RSS 輔助服務器是異步進行更新的，所以 RSS 輔助服務器不能直接提升爲主服務器。相反，它可以提升爲 HDR 輔助服務器，然後可提升爲主服務器。另外，HDR 輔助服務器可降級爲 RS 輔助服務器。
儘管 RS 輔助服務器與 HDR 輔助服務器類似，但有某些操作是 HDR 輔助服務器可執行但 RS 輔助服務器卻不支持，例如：
- RS 輔助服務器不支持 SYNC 方式
- RS 輔助服務器不支持 DRAUTO
- RS 輔助服務器不具有同步檢查點
- RS 輔助服務器不能直接轉換爲主服務器
RSS 備用服務器的主要作用是提供災難恢復解決方案。如同在 HDR 中一樣，主服務器不斷將其所有的邏輯日誌記錄發送給 RS 備用服務器，不過 RS 使用的異步方式。與 HDR 不同，通信使用全雙工協議。因此 RS 對網絡延遲不是很敏感，並且可以更容易駐留在一個較遠的地理位置。同時，如果節點間通信線路比較差的情況下，頁經常採用 RS 備用服務器方式。 RS 備用服務器的一個特點是主服務器並不和 RS 備用服務器同步檢查點，這一點和 SD 和 HDR 服務器不同。因此不能立即替代主服務器；必須首先切換爲一個 HDR 服務器。
RSS 配置實現
硬件和軟件需求
RS 輔助服務器維護物理數據庫的完整副本。出於此原因，以下內容必須與主服務器相同：
- 運行數據庫服務器的計算機硬件
- 分配給數據庫空間的磁盤空間量
- 創建數據庫空間時使用的物理設備中的偏移量
索引頁日誌記錄（LOG_INDEX_BUILDS）
在創建索引時，索引頁日誌記錄將各頁寫入到邏輯日誌，以使高可用性環境中各服務器之間的索引創建同步。要使用 RS 輔助服務器，必須啓用索引頁日誌記錄。
索引頁日誌記錄將完整索引寫入到日誌文件，然後將該日誌文件異步地傳輸到輔助服務器。輔助服務器可以是 RS 輔助服務器，也可以是 HDR 輔助服務器。然後，日誌文件事務被讀入到輔助服務器上的數據庫，減少輔助服務器在恢復期間重新構建索引的需求。對於 RS 輔助服務器，主服務器不等待來自輔助服務器的確認，這允許對主服務器上索引的立即訪問。
索引頁日誌記錄是使用 onconfig 參數 LOG_INDEX_BUILDS 進行控制的。如果 LOG_INDEX_BUILDS 設置爲 1（已啓用），那麼在主服務器上構建索引然後將索引發送到輔助服務器。
向集羣中添加 RS 備用服務器
向集羣添加一個 RSS 備用服務器的具體步驟：
步驟1：準備 SQLHOSTS 文件
集羣中的所有服務器必須具有針對其他服務器的 SQLHOSTS 條目。
|
1 2 3 4 5 6 |
|
步驟2：在主服務器上，啓用索引頁面日誌記錄
|
1 |
|
步驟3：在主服務器上，註冊新的RS備用服務器
|
1 |
|
步驟4：對主服務器採取0級備份
|
1 |
|
步驟5：在RS備用服務器中，恢復備份
|
1 2 3 4 5 |
|
步驟6：使RS備用服務器進入online模式
|
1 |
|
RSS 狀態監控
onstat – 命令
每次執行onstat時顯示的頭信息均有字段指示數據庫服務器正在作爲主數據庫服務器還是輔助數據庫服務器運行。
以下示例顯示作爲複製對中的 RSS 輔助數據庫服務器並且處於讀寫方式的數據庫服務器：
|
1 2 |
|
onstat -g rss 命令
我們可以在主服務器和 RSS 節點中分別運行 onstat -g rss 命令查看 RSS 節點狀態。 在主服務器和 RSS 節點上的輸出稍有不同。
在主服務器上運行 onstat -g rss 命令輸出如下：
|
1 2 3 4 5 6 7 8 9 10 11 |
|
其中：
- 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 服務器是否已經連接
- Next LPG sent (log id, page)：最近發送的 LPG log ID and page
- Supports Proxy Writes：顯示輔助服務器是否可執行 update 操作，Y 代表支持，N 不支持
在輔助服務器上運行 onstat -g rss 命令輸出如下：
|
1 2 3 4 5 6 7 |
|
其中：
- 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 ID and page
RSS 故障切換
在高可用集羣環境中，數據庫服務器主要包含下述三種工作方式：
| 服務器方式 | 說明 |
|---|---|
| 標準方式 | 不是數據複製系統的一部分。 |
| 主要方式 | 數據複製系統的主要方式。可以更新數據。 |
| 輔助方式 | 數據複製系統的輔助方式。無法更新數據，但是可以讀取數據。 |
RSS 進行故障切換的基本原則：
- RSS 節點不能升級爲主節點
- DRAUTO 對 RSS 不起作用
- RSS 節點可以轉換爲 HDR 輔助節點
- HDR 輔助節點可以轉變爲 RSS 節點
- RSS 節點可以轉換爲 standard node
RSS 故障切換的基本方法及形式：
將 RSS 節點升級爲 HDR 輔助節點 :
|
1 |
|
將 RSS 節點轉換爲標準節點 :
|
1 |
|
將 HDR 輔助節點裝換爲 RSS 節點 :
|
1 |
|
除去 RSS 節點 :
|
1 |
|
SDS 技術
與 HDR、RSS 不同，SDS 採用和主機共享磁盤方式，避免了數據重複存儲的問題，節省了空間，同時安裝、配置更加簡單。而且，當主機發生故障後，它可以快速實現接管，另外，我們可以非常容易地配置多個 SDS，可以實現了負載均衡的功能。
由於 SD 備用節點利用了主服務器的磁盤並且可以輕鬆快速地啓動，因而非常適合規模擴展場景，由於 SD 備用服務器非常接近主服務器（即它們共享相同的磁盤），因此最適合在主服務器遇到問題時作爲故障轉移服務器。
SDS 工作的基本原理
所有輔助服務器類型都使用日誌從主服務器複製數據。對於 HDR 輔助服務器和 RS 輔助服務器可通過生成日誌時使主服務器將其所有邏輯日誌記錄發送到輔助服務器，從而在輔助服務器上覆制對主服務器所作的更新。 HDR 輔助服務器和 RS 輔助服務器接收在主服務器上生成的邏輯日誌記錄，並將這些記錄應用到其自己的數據庫空間。對於 SD 輔助服務器，如圖所示，同 HDR 輔助服務器和 RS 輔助服務器不同，主服務器不是將整個日誌進行發送，而只是將邏輯日誌頁的日誌位置發送到 SD 輔助服務器。通過使用從主服務器接收到的日誌位置，SD 輔助服務器從磁盤讀取邏輯日誌頁，並將其應用於內存數據緩衝區。
圖 5. SDS 數據複製示意圖
SD 輔助服務器不會向共享磁盤塊中寫任何東西，不會將共享內存的數據刷新到磁盤，即使是發生 checkpoint 操作也一樣。如果 SD 輔助服務器需要刷新共享內存數據，他們會備寫到臨時的‘ paging file ’ 中，直到下一次 checkpoint 操作才清空‘ paging file ’。
同時，如下圖所示，主服務器不會清倉共享內存中的數據頁，直到確認 SDS 不在需要該數據頁纔會清倉到磁盤上。
下圖顯示了啓動 SD 輔助服務器的基本過程：
SD 輔助服務器首先創建到主服務器的 SMX 連接，之後，SD 輔助服務器向主服務器發出 checkpoint 請求，主服務器響應 SD 輔助服務器的 checkpoint 請求，並將相應 LSN 發送給 SD 輔助服務器，SD 輔助服務器啓動必要的恢復操作，之後，主服務器開始不斷向 SD 輔助服務器發送當前的 LSN，SD 輔助服務器也開始不斷向主服務器發送 ACK 確認信息。
圖 6. SDS 數據複製工作原理示意圖
SDS 配置實現
輔助服務器的硬件和軟件需求
除了磁盤需求（與主服務器共享），硬件和軟件需求與 HDR 輔助服務器的需求相同。此外，具有數據庫服務器的計算機之間必須共享主磁盤系統。這表示從 SD 輔助服務器到數據庫空間的路徑必須與主服務器的數據庫空間路徑相同。
SDS 相關配置參數說明
- SDS_ENABLE：用來啓用 SD 輔助服務器功能。您必須在主服務器及 SD 輔助服務器中將 SDS_ENABLE 都設置爲 1（啓用），才能啓用 SD 輔助服務器功能。
其取值範圍：- 0 - 禁用 SDS 功能
- 1 - 啓用 SDS 功能
- SDS_PAGING： 指定了兩個要作爲緩存器調頁文件的文件的位置。如果未設置 SDS_PAGING，SD 輔助服務器可能無法啓動。在 SD 輔助服務上設置該值。
其取值範圍：
< 分頁文件 1 的絕對路徑 >，< 分頁文件 2 的絕對路徑 > - SDS_TEMPDBS：指定 SD 輔助服務器用於動態創建臨時數據庫空間的信息。爲了啓動 SD 輔助服務器，SD 輔助服務器的 ONCONFIG 文件中至少出現一次 SDS_TEMPDBS，最多可以配置爲 16 SDS_TEMPDBS 條目。在 SD 輔助服務上設置該值，主服務器上不使用 SDS_TEMPDBS 。
其取值範圍：
<dbspace_name>、< 路徑 >、< 頁面大小以 KB 爲單位 >、< 偏移量以 KB 爲單位 >、< 大小 >
示例：
SDS_TEMPDBS sdstmpdbs1, /work/dbspaces/sdstmpdbs1,2,0,16000 - SDS_TIMEOUT：該配置參數用於主服務器確定要從 SD 服務器獲得確認需要等待多長時間，如果沒有獲得確認，主服務器將停止 SD 服務器。在主服務器上設置該值。
其取值範圍：
>= 0 秒，默認值爲 20 秒。
向集羣中添加 SD 備用服務器
向集羣添加一個 SDS 備用服務器的具體步驟：
步驟1：準備SQLHOSTS文件
確保 SQHOSTS 文件在主服務器和 SDS 節點都具有另一個服務器的條目：
|
1 2 3 4 5 6 |
|
注意這裏使用的組是可選的。
步驟2：將主服務器設置爲共享磁盤的所有者
在主服務器中，運行：
|
1 |
|
步驟3：配置SD備用服務器
- 確保以下參數匹配主服務器的 ONCONFIG：ROOTNAME、ROOTPATH、ROOTOFFSET、ROOTSIZE、PHYSDBS、PHYSFILE、LOGFILES 和 LOGSIZE 。
- 將 SDS_ENABLE 設置爲 1 。
- 配置 SDS_PAGING 和 SDS_TEMPDBS 。
例如：
|
1 2 3 4 5 |
|
步驟4：啓動SD備用服務器
|
1 |
|
SDS 狀態監控
onstat – 命令
每次執行onstat時顯示的頭信息均有字段指示數據庫服務器正在作爲主數據庫服務器還是輔助數據庫服務器運行。
以下示例顯示作爲複製對中的 SDS 輔助數據庫服務器並且處於讀寫方式的數據庫服務器：
|
1 2 |
|
onstat -g sds 命令
您可以使用onstat -g sds命令來查看 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 id, page)：最近發送的 LPG log ID and page
- Supports Proxy Writes：顯示輔助服務器是否可執行 update 操作，Y 代表支持，N 不支持
下邊是執行 onstat -g sds 命令的輸出：
|
1 2 3 4 5 6 |
|
使用 SMI 表
查詢 syssrcsds 表可獲取關於主服務器上共享磁盤統計信息的信息。
查詢 systrgsds 表可獲取關於輔助服務器上共享磁盤統計信息的信息。
SDS 故障切換
輔助服務器環境中的災難恢復
在當前主服務器連接到新的主服務器時執行故障轉移
當高可用性環境處於活動狀態時，新的主服務器將通知舊主服務器它將採取共享磁盤的所有權。然後，舊的主服務器將回滾所有打開的事務，並將其自身切換爲輔助狀態。在舊的主服務器完成該過程之後，它將通知新的主服務器回滾完成。這將成爲新的主服務器繼續操作的信號。可通過在新的主服務器上發出onmode -d set sds primary命令來執行此過程。
在當前主服務器未連接到新的主服務器時執行故障轉移
在此場景中，新舊主服務器之間的連接不存在。在這種情況下，我們需要強制執行轉換。這可通過發出onmode -d set sds primary force命令完成。僅當在確定原始主服務器不活動時才能發出該命令。因爲強制關鍵字會使新的主服務器在不與舊主服務器通信的情況下成爲源服務器，所以如果舊的主服務器仍然處於活動狀態，它很可能導致數據庫毀壞。
當高可用性集羣中的所有節點不可用時執行故障轉移
這是在所有服務器出現故障而且未能啓動現有主服務器後嘗試故障轉移時的唯一問題。該問題的原因是主服務器必須能夠連接以啓動高可用性集羣中的輔助服務器。如果主服務器不處於活動狀態，那麼無法建立連接，因此無法啓動輔助服務器。如果無法啓動輔助服務器，那麼用於更改主服務器的 onmode 命令將不會起作用。要避免該問題，請使用 oninit -SDS=<new alias>，其中 <new alias> 是新的主服務器上的 TCP 別名。這允許啓動現有輔助服務器，並使其能夠同時採取環境的所有權。僅當啓動集羣內的第一個服務器時才能使用 oninit 命令的該選項。
SDS 故障切換的基本方法及形式
將 SD 輔助服務器提升爲主服務器
可通過在 SD 輔助服務器上發出以下命令來將 SD 輔助服務器轉換爲主服務器：
|
1 |
|
請注意：SD 輔助服務器不能轉換爲標準服務器。
禁用 SD 輔助服務器環境中的主服務器
可使用以下命令禁用主服務器：
在主服務器上，輸入以下命令：
|
1 |
|
該命令將使主服務器成爲標準服務器，並禁用共享磁盤環境。
SD 輔助服務器環境中的災難恢復的建議
如果主服務器發生故障，那麼故障轉移的順序應該是：
- 轉移到 SD 輔助服務器
- 轉移到 HDR 輔助服務器
- 轉移到 RS 輔助服務器
集羣環境下災難恢復的各種方式對比
可在任何類型的輔助服務器上運行 onmode -d make primary 命令以將該服務器提升爲主服務器。下表說明了每個服務器類型是如何受到影響的。
| 如果新的主服務器是： | 那麼該類型的對等服務器： | 受該方式的影響： |
|---|---|---|
| SD 輔助服務器 | SD 輔助服務器 | 連接到新的主服務器並繼續 |
| RS 輔助服務器 | 連接到新的主服務器並繼續 | |
| HDR 輔助服務器 | 連接到新的主服務器並繼續 | |
| 舊的主服務器 | 關閉 | |
| HDR 輔助服務器 | SD 輔助服務器 | 關閉 |
| RS 輔助服務器 | 連接到新的主服務器並繼續 | |
| HDR 主服務器 | 取決於用戶操作 | |
| RS 輔助服務器 | SD 輔助服務器 | 關閉 |
| HDR 輔助服務器 | 關閉 | |
| RS 輔助服務器 | 關閉 |
CLR 技術
有的時候，遠程災備服務器和主機服務器要實現物理隔離，或者數據網絡非常不穩定，這種情況下，Informix 11 提供了 CLR （Continuous Log Restore）技術，它是通過邏輯日誌備份的方式，將數據庫的邏輯日誌人工傳送到遠程災備服務器，通過數據庫邏輯日誌恢復的方式保持和主數據庫數據同步的方式。
圖 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 條目。
|
1 2 3 4 5 6 |
|
步驟 2 ：對主服務器採取 0 級備份
|
1 |
|
步驟 3 ：在 CLR 備用服務器中，恢復備份
|
1 2 3 4 5 6 |
|
步驟 4 ：備份邏輯日誌，並拷貝到 CLR 服務器，並按需要重命名日誌文件
|
1 |
|
步驟 5 ：對 CLR 服務器，恢復邏輯日誌文件
|
1 |
|
步驟 6 ：當需要時，停止前滾恢復狀態，經 CLR 服務器轉變爲 quiescent mode
|
1 |
|
高可用集羣技術使用場景舉例
三層服務器可用性的配置示例
圖 8. 三層服務器可用性配置示例圖
現在假設新奧爾良校園的建築物 A 中發生了本地中斷。可能是機房內的水管破裂使水對刀片服務器和共享磁盤子系統的主副本造成了損害。通過運行 onmode -d 以使主服務器名位於建築物 B 中的刀片服務器上運行的某個 SD 輔助服務器上來將主服務器的角色切換爲建築物 B 。這將導致其他所有輔助節點自動連接到新的主節點。
圖 9. 第一層保護
因新奧爾良發生了區域性中斷，所以建築物 A 和建築物 B 均丟失，那麼您可以將主服務器角色切換至孟菲斯。此外，您也可能使丹佛進入到 HDR 輔助服務器，並可將附加 SD 輔助服務器添加到孟菲斯中的機器。
圖 10. 第二層保護
影響兩個站點的更大型中斷應需要切換至最遠的系統。
圖 11. 第三層保護
高可用集羣技術的選擇
Informix 高可用集羣技術版本支持情況
| 功能 | IDS Express | IDS 工作組版 | IDS 企業版 |
|---|---|---|---|
| RS 輔助服務器 | 不可用 | 不可用 | 是 |
| HDR 輔助服務器 | 不可用 | 可選 | 是 |
| SD 輔助服務器 | 不可用 | 可選 | 可選 |
Informix 高可用集羣技術的選擇考慮
| 需求 | 建議配置 |
|---|---|
| 您需要定期增大報告容量 | 請使用 SD 輔助服務器 |
| 您正在使用提供足夠磁盤硬件可用性的 SAN 設備，但是擔心發生服務器故障 | 請使用 SD 輔助服務器 |
| 您正在使用提供足夠磁盤硬件鏡像的 SAN 設備，但是也需要當主操作丟失時能夠返回聯機狀態的第二組服務器（而已鏡像磁盤的限制不是問題） | 考慮使用在兩個站點上運行 SD 輔助服務器的兩個刀片服務器中心 |
| 您需要具有距離適中的備份站點，但不能容忍故障轉移期間出現任何數據丟失 | 考慮使用兩個刀片服務器中心，SD 輔助服務器在主刀片服務器中心上，HDR 輔助服務器在遠程刀片服務器上。 |
| 您想要具有未曾丟失事務的高度可用系統，但是還必須在世界的另一面上設置遠程系統 | 考慮使用附近的運行 SYNC 方式的 HDR 輔助服務器，並使用世界另一面的 RS 輔助服務器 |
| 您想要具有高可用性解決方案，但是因爲您所在區域中的網絡，ping 的最佳響應時間爲大約 200 ms | 考慮使用 RS 輔助服務器 |
| 您需要備份站點，但不具有與備份站點之間的任何直接通信 | 考慮使用帶有備份和恢復的“連續日誌恢復 CLR ” |
| 只要數據最終能夠到達目的地，您就能夠忍受數據交付過程中的延遲；但是在任何情況下都需要具有快速故障轉移 | 考慮使用硬件磁盤鏡像與 ER 相結合的 SD 輔助服務器。 |
| 您需要其他寫處理功能，能夠容忍這些寫交付中的某些延遲，需要高度可用的事物並能夠分割工作負載 | 考慮使用帶有 SD 輔助服務器的 ER |
結論
Informix 提供了業界領先的高可用集羣技術。通過結合使用 HDR、SDS、RSS、CLR，爲用戶不僅提供了業界領先的高可靠解決方案，同時提供了最全面的負載均衡能力及故障接管能力。同時，Informix 11.5 還提供了 Connection Manager 功能部件，它是採用 ESQLC 編寫的一個實用程序，通過它，可以爲應用程序屏蔽 informix 高可用集羣服務器的複雜性，對應用程序來說，它看到的永遠是一個數據庫實例，由 Connection Manager 來自動完成透明的負載均衡及故障接管工作，真正做到了用戶應用不間斷地運行。