高可用性解決方案概述
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個。