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