(轉)使用 DB2 HADR 選擇用於災難恢複的 SUPERASYNC 模式

標籤：more   purpose   line   disco   code   故障   好的   tip   情況   

使用 DB2 HADR 選擇用於災難恢複的 SUPERASYNC 模式Vishnu G 和 Hemant Singh
2013 年 6 月 25 日發布

WeiboGoogle+用電子郵件發送本頁面

0簡介和背景

HADR 是一個通過資料複製提供高可用性和災難恢複的 DB2 功能。在啟用該功能時，可以將主要資料庫資料日誌即時傳送到備用資料庫。備用資料庫繼續重放已收到的日誌，以便與主要資料庫保持同步。

從 DB2 V9.5 Fix Pack 8 和 DB2 V9.7 Fix Pack 5 開始，SUPERASYNC 被指定為hadr_syncmode，這樣主要資料庫在任何情況下都不會受阻。

本文將介紹 SUPERASYNC 模式的用途、如何在該模式中設定 HADR，以及該模式下不同的備用資料庫的轉換狀態。本文提供了實現 SUPERASYNC 模式的用例，還介紹了使用它的優缺點。

SUPERASYNC 模式的用途

您可能會面對主要資料庫受阻塞的問題，這是因為備用端日誌重播緩慢所導致的，而備用端日誌重播緩慢是因為備用系統缺少資源以及出現網路暫停。引入 SUPERASYNC 模式可以預防各種因為網路暫停或緩慢執行待機而導致的主要資料庫背壓（減慢/阻礙交易處理）。

HADR 如何在 SUPERASYNC 模式下工作

在 SUPERASYNC 模式下，HADR EDU在後台進行日誌發送，並且不會干擾交易處理的代碼路徑，這意味著日誌發送不在提交事務的範圍內。因此，它不會阻止主要資料庫運行交易處理。

HADR 對永遠不會進入Peer狀態或Disconnected Peer狀態。HADR 狀態將逐漸從 local catch up 變為 remote catch up，然後停留在 remote catch up。HADR 總是從磁碟或歸檔日誌的主要資料庫發送日誌。它不需要進入 Peer 狀態，其中日誌是從主要資料庫日誌緩衝區發送的，並且主要資料庫日誌的寫入程式將會變緩。

在與圖 1 所示的其他同步模式進行比較時，此模式提供了最佳效能。

圖 1. SUPERASYNC 中的 HADR 的工作原理

 

1. 主要資料庫將日誌記錄寫入主要資料庫的記錄檔。
2. 然後提交事務，無需等待將日誌複製到備用資料庫。

在 SUPERASYNC 模式下設定 HADR 對

要在 SUPERASYNC 模式下設定 HADR 對，可以使用清單 1 至清單 3 所示的 SUPERASYNC 參數更新 HADR_SYNCMODE db cfg 參數。

清單 1. 更新 HADR_SYNCMODE

123456

$ db2 update db cfg for hadrdb using HADR_SYNCMODE SUPERASYNCDB20000I The UPDATE DATABASE CONFIGURATION command completed successfully. SQL1363W One or more of the parameters submitted for immediate modificationwere not changed dynamically. For these configuration parameters, the databasemust be shutdown and reactivated before the configuration parameter changesbecome effective.

清單 2. 停用資料庫

12	$ db2 deactivate db hadrdbDB20000I The DEACTIVATE DATABASE command completed successfully.

清單 3. 啟用資料庫

12	$ db2 activate db hadrdbDB20000I The ACTIVATE DATABASE command completed successfully.

使用 MON_GET_HADR（V9.7 中可能沒有提供）表函數或有 -hadr 選項的 db2pd 命令監控主要資料庫或備用資料庫的狀態。

例如，

1	$db2pd –db dbname -hadr

SUPERASYNC 模式下的 HADR 狀態轉換

2 所示，在啟用備用資料庫時，資料庫將會進入 Local catchup 狀態並讀取本地日誌路徑上可用的記錄檔。在讀取本地記錄檔之後，備用資料庫將進入 Remote catchup 掛起狀態，並等待主要資料庫的串連。一旦主要資料庫連接到備用資料庫，它們將保持 Remote catchup 狀態而且不再進入 Peer 狀態，以避免產生主要資料庫背壓。

圖 2. SUPERASYNC 模式下的備用資料庫狀態

當主要資料庫和備用資料庫在 SUPERASYNC 模式下建立串連時，備用資料庫的狀態將是圖 3 所示的RemoteCatchup。

圖 3. 備用資料庫的狀態是 Remote catchup

 

備用資料庫不可用時，主要資料庫的狀態將為Disconnected， 4 所示。

圖 4. 備用資料庫不可用時，主要資料庫的狀態是中斷連線

 

當備用資料庫與主要資料庫中斷連線時，備用資料庫的狀態將是RemoteCatchupPending， 5 所示。

圖 5. 備用資料庫的狀態是 RemoteCatchupPending

 SUPERASYNC 在 DB2 災難恢複情境中進行配置

以下小節描述了可以將 SUPERASYNC 配置為 hadr_syncmode 的用例情境，以及其如何協助災難恢複實現更好的主要資料庫效能。

使用 HADR 和 HA 通過叢集服務實現 DB2 災難恢複

下列情境適用於 DB2 V9.7。

例如，在 Location 1 中建立主要資料庫可以在使用 TSA 或 HACMP 叢集服務的兩台機器（M1 和 M2）之間實現高可用性。在 Location 2 中建立備用資料庫，以便在 SUPERASYNC 模式下使用 HADR 複製過程實現災難恢複， 6 所示。

圖 6. 使用 SUPERASYNC 的災難恢複

 

使用者應用程式在主要資料庫（如 M1）上串連並執行事務。日誌將從 M1 發送到備用資料庫。由於備用資料庫是在 SUPERASYNC 模式下建立的，所以不會因為它遠離主要資料庫（高網路延遲）或網路暫停而產生主要資料庫背壓。因此，主要資料庫效能比較好。

如果主要資料庫（Location 1 中）上的 M1 速度下降，那麼叢集服務將會啟動啟用另一個設定為高可用性的節點（如 Location 1 中的 Machine M2）。

在完成 HA 容錯移轉之後，會通過 HADR 複製過程將日誌從 M2 發送到備用資料庫。如果 Location 1 速度下降（M1 和 M2 均下降）。備用資料庫將被作為主要資料庫啟用。通過這種設定，您可以獲得資料庫高可用性最佳效能和資料庫恢複，從而防止災難發生。

在 SUPERASYNC 模式下使用 HADR 建立多個備用資料庫來實現災難恢複

下列情境適用於 DB2 V10.1

在有多個備用資料庫的 HADR 中，可擁有多達三個備用資料庫，這是 DB2 V10.1 中的一個新功能。其中一個資料庫可設計為 主要備用資料庫（支援所有 HADR 同步模式），其他兩個用作輔助備用資料庫（只支援 SUPERASYNC 模式）。主要備用資料庫在相同位置可部署為主要資料庫。輔助備用資料庫是遠程進行部署的，可以為主要資料庫和主要備用資料庫提供保護，防止災難發生。

以下是在 SUPERASYNC 模式下使用 HADR 建立多個備用資料庫來實現災難恢複的兩個可能情境。

• 情境 1：使用 HADR 實現 DB2 高可用性災難恢複
• 情境 2：使用 HADR 實現 DB2 高可用性和多個災難恢複

情境 1：使用 HADR 實現 DB2 高可用性和災難恢複

在該情境中，在 Location 1 上使用了 TSA 叢集服務在主要資料庫和主要備用資料庫之間設定高可用性。輔助備用資料庫被設定為實現 Location 2 上的災難恢複， 7 所示。

圖 7. 使用多個備用資料庫實現高可用性和災難恢複

 

使用者應用程式在主要伺服器上串連並執行事務。交易記錄將從主要伺服器發送到主要待命伺服器和輔助待命伺服器。因為輔助待命伺服器是在 SUPERASYNC 模式下建立的，所以不會因為它遠離主要伺服器（高網路延遲）或網路暫停而在主要伺服器上產生任何背壓。

如果出現主要伺服器中斷，那麼主要待命伺服器將被作為主要伺服器而使用叢集服務 (TSA) 自動啟用，現在新的主要伺服器會將日誌發送到 Location 2 的待命伺服器上。

如果 Location 1 上發生災難（主要伺服器和主要待命伺服器同時停機），那麼 Location 2 上的待命伺服器可作為主要伺服器啟用。因為您在災難恢複網站上使用了 SUPERASYNC 模式，所以在主要伺服器上可以通過避免因遠距離或網路延遲而產生的背壓來實現最佳效能。

情境 2：使用 HADR 實現 DB2 高可用性和多個災難恢複

該情境中，可以在 Location 1 上使用 TSA 叢集服務在主要伺服器和主要待命伺服器之間建立高可用性。對於災難恢複，可在 Location 2 上建立輔助待命伺服器 1，在 Location 3 上建立輔助待命伺服器 2， 8 所示。

圖 8. 使用多個待命伺服器實現高可用性和多個災難恢複

 

使用者應用程式在主要伺服器上建立串連並執行事務。交易記錄從主要伺服器傳送到主要待命伺服器，同時也傳送到兩個輔助待命伺服器上。因為輔助待命伺服器是在 SUPERASYNC 模式下建立的，所以不會因為距離或網路延遲而影響主要伺服器上的活動。

如果主要伺服器發生故障，那麼會通過使用叢集服務 (TSA) 自動啟用主要待命伺服器作為主要伺服器，並且將日誌從新的主要伺服器發送到其他待命伺服器。

如果在 Location 1 上發生災難，其中一個輔助待命伺服器將作為主要伺服器啟用，同時應用程式會串連到這個新的主要伺服器，並將日誌從新的主要伺服器發送到其餘待命伺服器。因為您在災難恢複網站上使用了 SUPERASYNC 模式，所以在主要伺服器上可以通過避免因遠距離或網路延遲產生的背壓來實現最佳效能。

結束語

在本文中，您已經瞭解了使用 SUPERASYNC 模式的優點和缺點，分別是：

1. 在 SUPERASYNC 模式下，事務回應時間比其他所有同步模式的時間都短。但是，如果主要系統發生故障，那麼造成事務損失的可能性最大。如果您不想讓主要系統上的事務因網路問題而受阻或遭遇更長的回應時間，那麼該模式非常有用。
2. 主要資料庫上的事務提交不受 HADR 網路或待命伺服器的影響。這可能導致主要資料庫和備用資料庫間的日誌空白 (log gap) 不斷增加。較大的日誌空白會導致漫長的恢復。如果災難發生在主要系統上，那麼日誌空白中的所有資料都將丟失。因此，使用 hadr_log_gap 監控元素或 db2pd –hadr 命令監控日誌空白十分重要。如果您觀察到無法接受的日誌空白，那麼應該調查網路效能或備用資料庫的相對速度，並採取矯正措施來控制日誌空白。

(轉)使用 DB2 HADR 選擇用於災難恢複的 SUPERASYNC 模式