高可用性解決方案概述
1 可用性
可用性是指在某個考察時段內,系統能夠正常運行的概率或者時間占有率的期望值,,通常用以下公式進行計算,值越大則表明系統宕機時間越少,

例如,對于一個 24*365 運行的業務系統,99.999% 的可用性表示每年宕機時間不超過 5 分鐘,當然,正常預定的維護時間(即視窗)一般不計入宕機時間,例如,營業時間僅限于從上午7點到晚上10點(即7*15)的業務系統,在下班后進行停機維護的時間不算在宕機時間之內,
高可用性(High-Availability)是一系列的技術總和,用來減少宕機時間和增加對業務資料的保護,
在規劃高可用性方案時需要綜合考慮以下兩個因素:
● RTO(Recovery Time Objective,即目標恢復時間)
RTO 表示業務系統每次容忍多少宕機時間,如果業務停頓時間過長,損失自然也會增加,對于特別重要的業務系統,可能需要同時使用多種技術確保在發生故障時能夠迅速恢復業務,
● RPO(Recovery Point Objective,即目標恢復點)
RPO 表示容忍多少資料丟失,通常只要做好備份,就可以使資料不丟失,但當災難發生時,從備份進行恢復的操作會導致資料庫在現階段不可用;如果恢復的時間特別長,業務停頓所造成的損失可能比丟失少量資料更嚴重,特別對于資料量非常大的資料庫,更需要預先考慮到恢復時間和資料丟失之間的權重而制定充足的預案,
通常 RTO 與 RPO 兩者之間存在沖突,需要根據業務需求、投資規模等多方面因素來權衡,從而制訂服務水平協議(Service Level Agreement,簡稱 SLA),
2 AlwaysOn 高可用性解決方案
“AlwaysOn”一詞至少在 SQL Server 2008 中已經出現,表示 SQL Server 可以持續地提供服務,但是當時“AlwaysOn”技術并沒有提供管理界面(通過 Windows 管理工具進行管理),所以這個字樣鮮為人知,
盡管 SQL Server 2012 在 SSMS 中出現了“AlwaysOn”專用管理工具,但是其只能管理 AlwaysOn 可用性組,導致常被誤解為 AlwaysOn 只有(或者等同于)可用性組這一種技術,
SQL Server AlwaysOn 即“全面的高可用性和災難恢復解決方案”,客戶通過使用 AlwaysOn 技術,可以提高應用程式可用性,并且通過簡化高可用性的部署和管理方面的作業,獲得更好的硬體投資回報,
SQL Server AlwaysOn 在以下2個級別提供了可用性,
● 資料庫級可用性
AlwaysOn 可用性組(Availability Group,簡稱 AG)是SQL Server 2012 引入的新特性,它允許將一組資料庫(一個或多個用戶資料庫)傳送到最多4個只讀副本,SQL Server 2014 將只讀副本的數量提升到8個,
AG 可以是一種“熱備份”技術,在同步提交模式下,主副本的資料被同步更新到其他輔助副本,主副本與輔助副本之間可以保持實時同步,當系統監測到主副本發生故障時,輔助副本可以立即成為新的主副本,
由于這是一個資料庫級的技術,因此在 SSMS 中提供了管理和配置界面,
● 實體級可用性
AlwaysOn 故障轉移群集實體(Failover Cluster Instance,簡稱 FCI)可以在多個16個節點之間實作故障轉移(Failover),企業版最多支持16個節點,標準版只支持2個節點)
FCI 是一種“冷備份”技術,輔助節點并不從主節點同步資料,唯一的一份資料被保存在共享存盤(群集共享磁盤)中,當主節點發生故障時,輔助節點提升為主節點并獲取共享存盤中的資料,然后才在這個新的主節點服務器中啟動 SQL Server 服務,
SQL Server 2012 對 FCI 技術做了一些改進,例如,可以不使用群集共享磁盤而使用共享檔案夾,可以將 tempdb 配置在本地驅動器,
由于這是一個實體(服務器)級的技術,因此 SQL Server 沒有為它提供單獨的管理界面,而是在 Windows 管理工具中的“故障轉移群集管理器”界面中進行管理和配置,
3 其它高可用性解決方案
● 資料庫鏡像
資料庫鏡像是 SQL Server 2005 SP1 正式引入的一項資料庫級的高可用性技術,
鏡像可以是一種“暖備份”技術,主體服務器與鏡像服務器同時運行著 SQL Server 服務,鏡像服務器從主體服務器獲得備份資料后立即進行還原,從而實作了鏡像服務器的資料更新,鏡像服務器同時也會獲得少量的元資料,當主體服務器發生故障時,鏡像服務器可迅速加載所需的所有元資料,然后成為新的主體服務器,
資料庫鏡像技術存在著許多不足,SQL Server 2012 的聯機手冊就已經申明將在未來的版本中取消鏡像技術,
● 日志傳送
日志傳送依賴于傳統的 Windows 檔案復制技術與 SQL Server 代理,
主服務器定期產生一個備份檔案,輔助服務器再定期通過訪問 Windows 檔案夾從而讀取并復制這些備份檔案然后定期恢復到本地的資料庫,實際上,日志傳送技術只是分別在主服務器和輔助服務器上實作了自動備份與自動還原而已,
● 其它輔助技術
對資料庫進行備份,當出現故障時,手動將資料還原到服務器,使得資料庫重新聯機,這也可以算作實作高可用性的一種技術手段,
復制(Replication)并不算是一個高可用性解決方案,只是它的功能可以實作高可用性,復制通過“發布-訂閱”模式,由主服務器向輔助服務器發布資料,使這些服務器間實作可用性,
4 各項技術的綜合對比
下表將 SQL Server 常用的高可用性解決方案進行綜合對比,
| 對比專案 |
AlwaysOn故障轉移群集 |
AlwaysOn可用性組 |
資料庫鏡像 | 日志傳送 |
| 副本數量 | 無 | 最多8個 | 1個 | 無限制 |
|
副本的可用性 (只讀訪問) |
不適用 | 可以 | 創建快照,然后訪問快照 | “備用模式”時可以訪問 |
| 對外統一IP地址 | 是 | 是 | 各自獨立的IP地址 | 各自獨立的IP地址 |
| 自動故障轉移 | 可以 | 可以 | 可以(需要有見證服務器) | 不可以 |
| 故障轉移單元 | 實體 | 一組資料庫 | 單個資料庫 | 不適用 |
5 同步提交與異步提交
AlwaysOn 可用性組、資料庫鏡像等解決方案需要為主資料庫建立一個或多個“熱備用”或“溫備用”的輔助副本,因此需要在主資料庫和備用副本之間傳送資料,
在主資料庫和備用副本之間進行資料更新,有以下兩種模式,
◆ 同步提交模式
同步提交時,需要經過一系列的程序,
(1)主資料庫在將事務日志寫入檔案的同時就傳送給輔助資料庫,然后主資料庫等待輔助資料庫的回應,
(2)輔助資料庫收到了來自主資料庫的事務,寫入本地事務日志檔案(固化),然后發送確認資訊給主資料庫,
(3)主資料庫收到輔助資料庫發來的確認資訊,結束等待狀態,繼續運行,
(4)主資料庫在遇到檢查點時才將緩存中的“臟頁”回寫到資料檔案;輔助資料庫根據收到的事務在本地進行重做(Re-do),
同步提交模式可以保證時刻擁有著一模一樣的副本,因此具有極高的安全性,但是輔助服務器接收事務日志、寫入事務日志檔案和發送確認資訊這一系列程序也會帶來一定程度的延遲,從而影響到主資料庫的性能,
由于同步提交對性能影響較大,因此 SQL Server 僅允許單向的同步提交(從一個主副本單向同步到多個輔助副本),而且,SQL Server 嚴格限制了同步提交的副本數量,AlwaysOn 可用性組的一個主副本最多可以同時向 2 個輔助副本實作同步提交,其他副本則使用異步提交模式,,
◆ 異步提交模式
異步提交時,主資料庫將事務發送給輔助資料庫后,無需等待而直接繼續運行,
異步提交模式消除了主資料庫的等待狀態,因此這種提交模式對性能幾乎沒有影響,但是輔助資料庫可能遇到更新資料失敗的情況(例如,因網路故障導致未接受主資料庫的事務,或寫入本地事務日志日志檔案時遇到錯誤),而此時主資料庫如果發生故障則可能造成資料丟失,
SQL Server 2014 最多允許 AlwaysOn 可用性組擁有 8 個輔助副本,其中同步提交的副本數量不能超過2個,
本文來自博客園,作者:古道輕風,轉載請注明原文鏈接:https://www.cnblogs.com/88223100/p/SQL_Server_HA-High_Availability_Solutions_Solution_Overview.html
轉載請註明出處,本文鏈接:https://www.uj5u.com/shujuku/413177.html
標籤:SQL Server
