Azure SQL Database 主動異地備援 (Active Geo-Replication) 功能

感謝北科大劉建昌同學翻譯微軟公司主管 Tobias Ternstrom 於 2014 年 7 月 12 日所發表的文章 https://azure.microsoft.com/blog/2014/07/12/spotlight-on-sql-database-active-geo-replication/

在本篇文章中，我們將繼續針對 Azure SQL Database 各種業務連續性 ( Business Continuity ) 方案作介紹，以及討論最近 Azure SQL Database Premium 版所提供的主動異地備援 ( Active Geo-Replication ) 功能。除了本篇文章的介紹之外，您也可以透過 Channel 9 觀看由 Sasha Nosov 和 Scott Klein 所主講的關於主動異地備援如何運作以及如何確保業務連續性的介紹影片。

何謂業務連續性 ( Business continuity )

所謂業務連續性 ( Business continuity ) 意指當企業在面臨資訊基礎建設或系統發生中斷時，能夠讓資訊服務持續不間斷之機制、策略或是程序。依照資料庫的角度來看，最主要有四種造成服務中斷的狀況 :

1. 本地端硬體或軟體故障時會影響資料庫節點 ( node ) 之運作。( 例如 : 磁碟機故障 )

2. 資料庫內的資料損毀或是遭到刪除 : 此種錯誤通常是因為應用程式的 bug 或人為因素所造成，因此無法透過基礎建設 ( infrastructure ) 方式來偵測問題或排除問題。

3. 資料中心停止運作 : 發生這種原因可能是由自然災害所引起，在這種情況下，需要使用容錯轉移 ( failover ) 的異地備援 ( geo-redundancy )，將現有服務移轉到備用的資料中心。

4. 升級或維護時所發生的錯誤 : 當在進行更新或是維護時，發生了出乎意料的錯誤，此時需要將資料庫還原到更新前的原始狀態。

Azure SQL Database 如何保持業務連續性

從 Azure SQL Database 建立的那一刻起，Azure 系統一直維持每個資料庫都有三個甚至是更多的副本來保護資料庫，資料異動確認 ( updates committed ) 回應前至少已經有兩份資料副本，在高可用性 ( HA ) 措施的保護下，要是發生上述第一點服務中斷的情況，也就是本地端的硬體或軟體發生故障時，仍可以有效的保護資料庫持續提供服務。

而在最新發布的 Azure SQL Database 服務層 ( Basic,、Standard、Premium ) 中，也為了因應上述其他三種資料庫服務中斷情況，提供了確保用戶業務連續性方案。

以下將個別來介紹Azure SQL Database如何在中斷發生的狀況下維持商業連續性 :

資料庫內的資料損毀或是遭到刪除

所有的 Azure SQL Database 資料庫版本 ( Basic、Standard、Premium ) 服務層都提供了自動備份的功能。這項功能專門可以解決因資料損毀或被刪除所造成的錯誤。Azure SQL Database 會每週做一次完整備份 ( full backups )，每天做一次差異備份 ( differential backup ) 以及每五分鐘進行交易記錄備份 ( log backups )。而備份的保存期限會依照使用者所使用服務層而有所不同，Premium 版為 35 天、Standard 版為 14 天、Basic 版為 7 天。您可以利用在保存期限內的任何一個備份來還原資料庫，甚至可以還原最近遭到刪除的資料庫，此一自由還原資料至任意時間點的功能可參閱此篇內容。

資料中心停止運作

而針對 Azure 資料中心因為某些原因造成的長時間停擺，Azure SQL Database 各版本提供多種將資料庫備份到另外一個地區資料中心的功能，目前有三種跨資料中心的備援方式可供選擇 :

1. 異地還原功能 ( Geo-restore ) ，無論 Azure SQL Database 的 Basic、Standard 和 Premium 版都能夠透過異地還原功能，在配對的資料中心運用 Azure Storage 內的地理備援複本將資料還原，相關資訊可參閱此篇內容。

2. 標準異地備援 ( Standard geo-replication ) Azure SQL Database 在 Standard 和 Premium 版上擴展了本地端高可用性系統 ( Local HA system ) 能力，用戶可在 Azure 配對之資料中心 ( paired region ) 上建立和維護一個次要資料庫，在平時這個次要資料庫是離線並且是無法讀取的，一旦遇到主資料中心發生停止運作的情況，用戶可以決定是否進行容錯轉移，此時在配對資料中心備援用的次要資料庫方可使用，相關資訊可參閱此篇內容。

3. 主動異地備援 ( Active geo-replication ) Azure SQL Database Premium 版用戶可以選擇此異地備援方式，降低資料遺失風險、並能在最短時間恢復在異地恢復運作的一項災難備援解決方案。主動準異地備援功能可讓用戶選擇多達 4 個地理備援的次要資料庫，而這些次要資料庫可以在任何時候進行讀取，並且也可以用於負載平衡 ( Load Balance ) 快速讀取這些副本資料。主動異地備援目前已經進入技術預覽階段，用戶可以公開測試。

升級或維護時所發生的錯誤

使用主動異地備援，您可以建立一個連續的資料庫副本，透過它能夠立即的凍結先前更新或是維護的資料庫和應用程式，而在這個過程之中若是偵測到的錯誤，也能夠快速地回復到這個連續的資料庫副本。

不同的 Azure SQL Database 服務層提供了不同的災難備援解決方案。我們想要強調的是，在不同 Azure SQL Database 服務層之間用戶可以輕易地進行 ”降級” 或是 ”升級”，因此，當資料庫需要進行一些很重要的更新時，您可以先將資料庫從 Standard 版 ”升級” 到 Premium 版，這樣就能夠使用最保險的主動異地備援方式進行系統更新。等到更新完成之後，再將資料庫 ”降級” 回 Standard 版。這樣的好處一方面可以減少成本，另外一方面又能夠提升資料庫在更新時的可靠度。

主動異地備援細節

接下來我們將仔細的描述主動異地備援如何使用於確保業務連續性，並且透過下面的圖示來說明它是如何運作的。

圖一 一個 Azure SQL Database Premium 版的資料庫可以同時在同個區域或是不同的區域上建立最多四個可讀取的次要資料庫

主動異地備援關係 ( Active geo-replication relationships ) 可以透過 Azure 入口管理網站、PowerShell、REST API 來進行管理和建立。在入口網站中，您可以從主要或是輔助的資料庫中管理其備援關係，並且從主資料庫中監控每一個次要資料庫複製的狀況。

圖二 可以使用 Azure 管理入口網站建立和監控多達四個不同資料中心上的次要資料庫

每個資料庫可以建立多達四個可讀取的次要資料庫，每一個都與主資料庫擁有相同的名稱，但是分別建立於不同的伺服器上(伺服器所在的資料中心區域可以相同，也可以不同 )。當次要資料庫第一次被建立時，其狀態為主資料庫當前的狀況，一旦當次要資料庫建立完畢之後，它將會從主資料庫那裡進行連續性的資料複製。

次要資料庫就如同一般的資料庫，在本地端同樣地擁有高可用性系統 ( HA system ) 架構的保護。

圖三 次要資料庫的名稱與主資料庫相同，但是位於不同的伺服器上

不同於 Azure SQL Database 本地端高可用性架構下採用即時的資料複製方式，主動異地備援從主資料庫將資料複製到次要資料庫的資料複製方式是屬於非同步的，當主資料庫正在等待與次要資料庫完成資料交易時，主資料庫不會產生封鎖 ( blocked ) 的狀況。當複製資料到較遙遠的資料中心時，這項改變將可以解決資料複製時發生連線問題 (connection problems) 或網路高延遲 ( high-latency )。

為了確保次要資料庫進行資料交易時，不會造成主資料庫發生瓶頸 ( bottleneck )，因此次要資料庫需要擁有與主資料庫相同 ( 甚至更高 ) 的服務水準等級。

在使用主動異地備援時，次要資料庫是可以讀取的，所以可以支援唯讀 (read-only) 負載之應用情境。當使用者要跨越多個資料庫進行複雜的查詢動作或是需要低延遲時間讀取資料時，這項功能就能夠派上用場。

圖四 : 當某地資料中心發生停擺，可以終止備援關係，並且應用程式將進行容錯轉移到次要位置上。

每個主資料庫的備援關係 ( Replication relationships ) 是可以手動進行調整的，它允許您可以在任何時間點終止複寫。如果您決定終止主區域的複寫，您可以選擇立即終止 ( 這樣會遺失所有尚未執行的交易 )，也可以選擇在所有交易結束之後再終止。如果是資料中心停止運作，連帶影響到主資料庫停止服務，此時仍然可以手動使用容錯移轉。

圖五 : 您可以選擇立即停止或是等待所有數據交易處理完之後再停止

注意 : 只有主資料庫才有提供上述兩種停止作業方式。

若是從次要資料庫終止備援關係的話，備援關係將立即終止，並且您將會失去尚未被複製的資料交易。而會失去多少將取決於主資料庫在故障的時間點所做的備份以及在連線中緩衝多少資料交易。當您決定是否要終止備援關係時，您需要考慮到資料遺失的問題以及是否資料庫是否需要再進行備份。

圖六 : 若是從次要資料庫上進行停止異地備援的動作，就只能夠選擇立即停止

一旦您終止了主資料庫與次要資料庫間的備援關係，此時次要資料庫將成為一個可以正常讀寫的資料庫，同時您也擁有這個資料庫完整的存取權限。由於次要資料庫與主資料庫擁有相同的名稱 ( 但是在不同的伺服器上 )，因此您需要在應用程式上重新配置連接字串 ( Connection String )。若您進行了容錯移轉，這將需要在新的資料庫上重新建立與先前主資料庫相同的地理備援關係，以確保在容錯轉移之後，仍繼續擁有地理備援或負載平衡的能力，滿足業務連續性上的需求。

圖七 : 在終止次要資料庫的備援關係之後，新的主資料庫也需要建立地理備援關係來保護資料庫，並且也支援負載平衡

主動異地備援可以被整合進任何應用程式架構中，但是在某些應用架構中使用它是有風險存在的。更多關於此主題的資訊請參照本文。

結論

主動異地備援不僅提供了強大的地理備援功能來保護資料庫不受到資料中心停擺所影響，更能夠使用在不同的商業連續性方案。主動異地備援目前已進入技術預覽階段，只有 Azure SQL Database Premium 版方有提供。

您可以透過此文章了解更多關於 Azure SQL Database 使用主動異地備援來維持業務連續性，或是觀看在Channel 9上由 Sasha 和Scott 主講關於主動異地備援如何支援實際業務的影片。我們將認真聽取您的意見，請您放心使用它，並且告知我們您的想法。