Azure資料庫上的 HA與災難復原

by adonisy 4. 五月 2020 12:57

作 者:楊先民
審 稿:張智凱

 

高可靠度(High Availability)

高可靠度是指託管Azure SQL資料庫失敗在物理服務器上提供業務連續性,也就是說如果你有一台 SQL Server當作備援的話

這一台備援的機器將會接手提供服務。

 

而 Azure是將高可用性內置到Azure SQL資料庫中的方式,並且完全讓使用者覺得透明。

這種高可用性是建構在目前流行的Always On技術,在本地SQL服務器中可用。但是,您必須配置,管理,

並在本地環境中維護Always On。

在Azure SQL資料庫中則是由Microsoft配置,管理和維護。

 

加速資料庫恢復(Accelerated Database Recovery (ADR))

加速資料庫恢復或者是ADR是一種新的資料庫恢復選項,它可以極大的在崩潰恢復之類的場景中提高可用性並減少時間

(在服務器/資料庫崩潰的情況下恢復數據庫),始終在線可用性組故障轉移和長時間運行的事務回存(例如,大容量新增入或

索引重建回存)。

SQL資料庫由資料檔和LOG檔所組成。資料文件包含資料表。LOG檔包含了可跟踪對資料進行的所有更改以及

模式例如,如果表中有新增,則LOG檔案則包含新增語句以及新增語句是否已經交易完成。

為了更好地了解ADR,讓我們首先了解當前資料庫的恢復過程。

 

目前資料庫的復原方式分為三個階段,分別為:分析、重作和取消。

分析階段,從最後一個開始對LOG檔案進行正向掃描,檢查點或較舊的dirty page LSN(日誌序列號)。

分析階段的輸出是交易列表:

•將這些寫入日誌並提交,但不寫入實體的日誌資料庫檔案

•它們在日誌文件中,但是沒有交易完成或是寫回或者是已經在回寫狀態(活動事務)。

重做

在此階段,將從最舊的未完成交易轉發日誌,並且重做已提交給日誌但未提交給資料庫的交易。

換句話說,將所有dirty page中,從最早的未提交的刷新或寫入到磁碟事務處理到日誌末尾,以將系統還原到當時的狀態的情況。

取消

在此階段,從日誌末尾到最舊的日誌向後讀取未完成交易的事務和崩潰時的所有活動事務都是回寫或是取消。

此過程有助於在崩潰後將資料庫恢復到一致狀態。但是,這需要很長時間,並且與運行時間最長的事務成比例。

未提交事務的時間越長,日誌記錄就越多進行掃描,從而增加了恢復時間。

而且,恢復時間還取決於最長運行的工作量交易已執行。它執行的工作越多,滾動所需的時間就越多返回並恢復資料庫。

ADR解決了當前資料庫恢復過程中的問題,並提供了更快的資料庫恢復。

ADR具有以下新的元件,用於重新設計當前元件的恢復過程

永久版本存儲(PVS)

每當修改資料行時,該行的先前版本將保留在PVS中。

PVS類似於快照和讀取提交隔離中使用的版本儲存水平;但是,PVS並不是tempdb儲存在用戶資料庫中。

邏輯還原

邏輯還原是使用PVS執行取消/回寫操作的過程。

在當前的資料庫恢復過程中,如果事務中止或回寫,則所有其他事務必須等待第一個事務回寫才能訪問行。

但是,在ADR中,邏輯還原允許其他事務訪問前一個版本而不是等待第一個事務回寫。

日誌

sLog是一種低容量的內存日誌流,用於儲存非版本的日誌記錄鎖獲取和數據定義語言(DDL)命令之類的操作。

換句話說,它儲存PVS中不涉及的操作。

sLog在檢查點操作期間寫入磁碟,並通過以下方式保持低容量

定期刪除已提交交易的條目。

清潔器

這是從PVS清除過時的行版本的異步過程。清潔工該過程每分鐘運行一次,也可以使用sys.sp_persistent_手動運行

 

version_cleanup系統儲存過程。

ADR流程由與當前恢復流程相同的三個階段組成;

但是,每個階段執行的工作都不同於當前的恢復過程。

分析

從最後一個檢查點將日誌向前讀取到日誌末尾。

重建sLog(從磁盤讀取到記憶體),並記錄非版本的日誌記錄操作從事務日誌寫入sLog。

重做

重做分為兩個階段:

•階段1:sLog從最早的未提交事務讀取到最後一個事務重做檢查點和非版本日誌記錄。

•階段2:從上一個檢查點開始在事務日誌中重做該事務到日誌末尾。

取消

取消階段包括以下內容:

•通過向後讀取來取消sLog的所有非版本化操作從日誌末尾到最早的未提交事務。

•使用邏輯還原執行行級,基於版本的取消,如所述前面的“邏輯還原”部分。

ADR速度很快,因為它不依賴於工作時間或最早的活動時間交易。事務日誌僅從最後一個檢查點掃描到末尾日誌。

崩潰時的活動事務被標記為中止,並且行版本對於中止的事務,在恢復過程中將被忽略。

除了快速的資料庫恢復以外,使用ADR可以將事務日誌截斷在檢查點和備份期間積極進行。

這是因為日誌記錄為恢復資料庫不需要最早的未提交事務。

對於長期運行的事務工作負載和方案,由於活動的事務,事務日誌的大小很大應考慮使用ADR

區域冗餘配置(Zone Redundant Configuration)

區域冗餘配置是指在其中具有Azure SQL資料庫副本不同的可用區。

Azure可用區是其中的不同資料中心同一地區。可用區在斷電時提供額外的可用性特定區域或資料中心發生故障或網絡故障。

區域冗餘資料庫僅在資料庫的高級服務層中,且僅支援1 TB以內。

 

區域冗餘配置可能會影響某些在線交易的性能

處理(OLTP)工作負載。這是因為區域冗余副本位於不同區域(資料中心),並且兩個區域之間的網絡延遲可能會影響性能。

因此,建議首先測試區域冗餘配置性能影響。

但是,如果對性能有影響,則可以使用區域冗餘配置輕鬆關閉,如上圖所示。

災難恢復

DR指的是在自然災害或駭客入侵時具有業務連續性終止整個Azure區域。

有兩種實現災難恢復的方法:標準地理複製和活動地理複製。

標準地理複製

標準地理複製異步複製來自在預定義的Azure區域中將在線主資料庫轉換為脫機輔助資料庫:

在標準的地理複製中:

DR配對區域中僅允許一個輔助節點。

每個區域都有一個只能託管輔助資料庫的DR對。

輔助資料庫處於脫機狀態,並且不可讀。但是,它在母版中可見資料庫。故障轉移完成後,輔助資料庫是可讀的。

標準地理複製專為唯一目的的環境而設計

進行地理複製的目的是實現災難恢復,而不是將讀取卸載到可讀

如果Azure區域發生故障,您將在Azure門戶上收到有關該區域發生故障的警報。

該區域上Azure SQL Server的狀態設置為降級。你有兩個這裡的選項:

•立即執行手動故障轉移到輔助資料庫

標準地理複製的恢復點目標(RPO)小於5秒。 RPO是指可能會丟失資料的最大持續時間。

停電。因此,如果您的應用程序可以在少於5秒的時間內丟失數據或者您有一種方法可以管理應用程序代碼中的數據丟失,那麼建議您

故障轉移到輔助節點。

故障轉移完成後,您將必須確保應用程序已正確配置為連接到新的主資料庫。您還將必須通過地理複製到另一個Azure DR對來保護新的主資料庫。

•等待Azure區域恢復

如果您的應用程序對資料丟失敏感,並且沒有任何邏輯

應用程序端要控制資料丟失,您應該選擇等待該區域恢復。但是,如果停機時間超過24小時,並且Microsoft發現了故障,那麼恢復該地區將需要很長時間。

微軟將強制故障轉移從主資料庫到輔助資料庫。因此,如果您決定等待該區域恢復,Microsoft決定在24點後強制執行故障轉移小時,那麼您將丟失資料並

失去24小時的可用性:

假設美國東部地區發生故障,在環境故障轉移之後,美國西部地區將充當主要地區,一旦該地區到來,美國東部地區將成為新的主要地區回到網上。

但是,您可以使用美國東部以外的其他地區來創建二級資料庫,而不必等待美國東部地區重新聯機。

主動地理複製

主動式地理複製使用Always On技術將資料異地複製到在同一Azure區域或任何其他Azure區域中最多有四個可讀輔助副本。

主動地理複製適用於所有性能層。

DB1數據庫主要存儲在美國中南部地區,其中兩個可讀美國西部和美國東部地區的中學。

手動故障轉移與“標準地理複製”部分中說明的類似。

但是,當您故障轉移到輔助數據庫,端點或連接時字符串已更改,您將必須對應用程序進行更改,以便您可以連接到新的主資料庫。

故障轉移完成後,所有輔助數據庫將自動指向新的小學。除了手動故障轉移外,主動的地理複製還支持使用自動故障轉移組進行自動故障轉移。

同步複製

活動地理位置複製中的預設的製類型是非同步。但是,如果應用程序需要同步複製,那麼您可以通過調用提交事務後立即sp_wait_for_database_copy_sync。

這將阻塞調用線程,直到所有提交的事務都已復製到次要的。

該過程可能會在調用線程的大小增加明顯的延遲。

事務日誌正在復制。建議使用此程序來防止丟失僅包含關鍵資料,而不是所有資料。

自動故障轉移組

自動故障轉移組使您可以自動恢復一個或多個SQL組。

區域故障時的資料庫。自動故障轉移組中的所有資料庫應屬於單個服務器,它們也將故障轉移到單個服務器。

自動故障轉移組條款

•故障轉移組:主服務器和服務器之間的一組資料庫。

輔助服務器,如果服務器中斷,將作為一個單元進行恢復主要地區。

將資料庫添加到故障轉移組:服務器或彈性服務器中的資料庫時池被添加到故障轉移組中,該二級資料庫具有性能級別

與主資料庫類似,在輔助資料庫上自動創建服務器。如果主資料庫位於彈性池中,則具有在輔助服務器上會自動創建相同的名稱。

添加輔助資料庫服務器中已經存在的資料庫時,但是,它不屬於故障轉移組,因此需要一個新的輔助資料庫在輔助服務器中創建。

讀寫偵聽器:這是指向主服務器的DNS CNAME記錄網址。

它允許應用程序透明地連接到可用的主資料庫故障轉移時使用服務器。這類似於中的可用性組偵聽器本地“始終在線”配置。

該應用程序未連接到主要或輔助服務器URL。相反,它連接到讀寫聽眾。發生故障轉移時,讀寫偵聽器將自動指向

到新的主(備用)服務器。因此,與手動故障轉移不同,用戶故障轉移時不必更改應用程序連接字符串。

•只讀偵聽器:這是指向輔助DNS的DNS CNAME記錄服務器。它允許應用程序透明地連接到輔助

只讀查詢。如果您想將讀取的工作負載卸載到輔助服務器上服務器,您可以通過在服務器上添加ApplicationIntent = ReadOnly

應用程序連接字符串。但是,讀取的工作負載應容忍資料過時。這是因為複制是非同步的,並且輔助資料庫將在主資料庫後面提供一些資料。

•故障轉移策略:預設的故障轉移策略設置為自動;但是,這可以是如果故障轉移過程由應用程式控制,則關閉。

如果自動故障轉移已關閉並且故障轉移,則需要手動故障轉移流程不受應用程式控制。

手動故障轉移也可以在需要的任何時間啟動,而與自動故障轉移策略。手動故障轉移的一個示例是切換回一旦該區域從中斷中恢復並可供主機使用

資源。

•資料遺失時間的寬限期:此設置控制系統的持續時間在啟動自動故障轉移之前失敗。例如,如果寬限期為資料遺失設置為2小時,

然後在主資料庫發生故障的情況下區域,將在2小時後進行故障轉移。但是,如果中斷得以解決在寬限期到期之前,不會執行故障轉移。

•友好的故障轉移:如果主要區域尚未發生故障

影響資料庫(但可能會在不久的將來影響資料庫)

並且資料庫仍然在線,具有完全同步的友好故障轉移是立即啟動,使用資料丟失小時數繞過寬限期

(友好的故障轉移中沒有資料丟失–寬限期設置僅在無法進行友好的故障轉移時有效)。

升級主資料庫服務層:服務層和性能可以在需要時修改主資料庫的級別。

無需修改同一服務層內的性能水平斷開輔助資料庫的連接。換句話說,您可以升級

從標準S0到標準S1的主資料庫,而無需斷開相應的輔助資料庫連接。

但是,如果要在服務層之間進行切換,則建議使用(並且強制執行)首先升級輔助資料庫,然後再升級主資料庫

以避免終止輔助資料庫連接。

如果輔助資料庫是自動故障轉移組的一部分,則建議不要降級輔助資料庫服務層。這是為了避免性能故障轉移時性能下降。

下期將會看如何設定。

 

 


Tags:

SQL Server資料庫 | 楊先民Adonis Young

不允許評論

NET Magazine國際中文電子雜誌

NET Magazine國際中文電子版雜誌,由恆逸資訊創立於2000,自發刊日起迄今已發行超過500篇.NET相關技術文章,擁有超過40000名註冊讀者群。NET Magazine國際中文電子版雜誌希望藉於電子雜誌與NET Developer達到共同學習與技術新知分享,歡迎每一位對.NET 技術有興趣的朋友們多多支持本雜誌,讓作者群們可以有持續性的動力繼續爬文。<請加入免費訂閱>

月分類Month List