轉自：https://www.cnblogs.com/jenrrychen/p/5199488.html
前言
SQL Server 2012引入了全新的HADR技術 -- AlwaysOn。AlwaysOn可謂是集SQL Server 2012之前各種HADR的優點於一身，比如故障轉移群集的高可用行，日志傳送的數據副本可訪問，鏡像技術的高同步和自動頁面修復。同時它的可用性組概念又規避了故障轉移群集必須是整個實例完全轉移的“缺點”。在架構上的可拓展性也是其一大優勢。多只讀輔助副本來幫助減輕主副本的數據讀取負載對於某些大型應用是一大利器。以及可以再與故障轉移群集相結合來實現更高層次的高可用也體現了其對於大型應用的支持。
AlwaysOn可用性組的前提條件
1）服務器不能是域控制器
2）服務器OS需要是Windows Server 2008或以后的版本
3）服務器需要是Windows故障轉移群集的節點
AlwaysOn可用行組數據庫的要求
1）只能是用戶數據庫，這點和鏡像技術是一樣的；
2）可讀寫；
3）多用戶模式；
4）完全恢復模式；
5）做過完整備份；
6）不屬於其他的可用性組；
重要特性
1）多用戶數據庫為可用性單位
2）虛擬網絡服務器名
3）三種故障轉移模式
4）最多可以有8個輔助服務器（SQL SERVER 2012最多4個，SQL SERVER 2014最多8個）
5）主服務器和輔助服務器數據加密和壓縮
6）自動修復某些類型的數據頁面損壞
7）輔助服務器數據只讀，分擔一部分主服務器負載
8）輔助服務器可以執行備份和DBCC命令
9）AlwaysOn專屬Dashboard、DMV、Performance Counter和Extended Events支持
與其他高可用與災難恢復（HADR）技術對比
SQL Server 2012之前的版本提供的高可用與災難恢復（HADR）技術眾多，但是難有一種是“完美”或者說可以被看成是一種解決方案的。各自都存在一些優缺點。
集群：優點是可以故障轉移；缺點是共享了同一份數據，無副本，一旦數據出問題就完全不可訪問；自動故障轉移是整個實例級別；
日志傳送：最老的HADR技術，依賴於事務日志。優點是一個數據庫可以同時有一個或多個數據庫副本，而且還是可以訪問的，可以實現讀寫分離分擔主服務器壓力，缺點是一旦災難發生，會出現短暫的數據丟失。不支持自動故障轉移。恢復時間相當長。相當於把副本備份然后還原到當前的生產數據庫，在承當數據丟失的情況下，前提是故障是數據庫級別，不能是硬件或者實例（Windows服務）級別。
事務復制：這個不是災難恢復技術，只是作為高可用技術的一種。依賴於事務日志。優點是高可用的對象可以細化到表級別，也可以把它看成是ETL技術的一種選擇，用於分發數據到其他的訂閱節點是非常好的技術，對於實現讀寫分離也是一個選擇。缺點是一旦災難發生，會出現數據丟失，而且會給服務器增加負擔。和日志傳送一樣依賴於事務日志，注定很多缺點兩者都相似。
數據庫鏡像：SQL Server 2005后的HADR技術。優點是可以保證不會出現任何數據丟失，也支持故障轉移；缺點是副本不可訪問，僅在故障轉移時才可訪問，無法讀寫分離減輕服務器壓力。
AlwaysOn：可以說它就是對其他高可用與災難恢復（HADR）技術的集大成者，吸取了數據庫鏡像的數據庫級別的故障轉移，日志傳送的副本可訪問（只讀）特點，故障轉移集群的多節點和自動故障轉移和檢測的能力。它不像故障轉移集群必須是對整個實例級，也不像數據庫鏡像和日志傳送只能對單個數據庫，AlwaysOn的核心思想是“可用性組”，每個可用性組包含的是一個或若干個數據庫，然后把整個可用性組一起進行故障轉移。
《SQL Server 2012實施與管理實戰指南》一書中總結了這5種技術的一些特點。
AlwaysOn和Windows群集的關系
AlwaysOn的故障轉移特性是基於Windows群集實現的。因為故障偵測和轉移也具備了一些Windows群集的特性：
1）同一可用性組的可用性副本必須處在同一Windows群集內
2）同一可用性組的可用性副本必須運行在不同的Windows節點上
3）如果某個可用性副本是一個SQL群集實例，同一SQL群集的其他非活躍節點上安裝的任何其他SQL實例不能作為它的輔助副本
4）一個數據庫只能屬於一個可用性組
使用虛擬網絡服務器名和Listener，由Listener來決定是否Failover
Listener決定把客戶端請求是否重定向到其他的輔助副本上。它本身是不支持SQL Browser的，因為使用虛擬網絡服務器名本身就是使用默認實例的一種用法。既然是使用默認實例，那也就不存在命令實例和其端口號一說了。那SQL Browser也就沒用了。如果本身使用虛擬網絡服務器名，每個副本都使用默認實例。
架構流程圖
可用性模式
異步提交模式：事務被提交前無需先等待某個輔助副本將事務日志固化。這種模式下一般輔助數據庫都是出於SYNCHRONIZING狀態。這種模式一般適用於那些主副本和輔助副本物理距離遠的情況。
同步提交模式：事務被提交前需要先等待某個輔助副本將事務日志固化。這種模式下輔助數據庫會出於SYNCHRONIZED狀態。
AlwaysOn事務提交流程
可用性副本連接狀態
DISCONNECTED: 主副本和輔助副本間互相發送ping。默認超時時間為10秒。最低為5秒。建議10秒甚至更長，避免SQL Server過於繁忙。
可用性模式對事務復制的影響
事務復制的Log Reader不會去處理那些尚未復制到輔助副本的日志記錄。因為如果事務復制處理了這些日志，就會造成訂閱服務器的記錄比輔助服務器的數據新鮮度要新。這時一旦發生Failover，輔助副本就會被自動切換成主副本，這樣就會出現輔助副本的數據比訂閱服務器的記錄舊。這種情況是不允許。
故障轉移形式
AlwaysOn通過加載了一個名為hadrres的DLL。因為AlwaysOn其實也是依托Windows群集服務，所以其實也是由RHS.exe進程來加載這個DLL。從名字可以看出是High Availibility Disaster Recovery Resource的簡稱。也就是其實這條進程是用於控制可用性組資源的上下線的。
AlwaysOn和SQL Server的群集其實是一樣通過調用存儲過程sp_server_dianostics來檢查群集的狀態。調用方法存在hadrres.dll中。hadrres.dll開啟一條線程連接到SQL Server並且一直保持，不斷調用這個存儲過程來獲取SQL Server的狀態信息。返回結果和AlwaysOn可用性組的FailureConditionLevel配置進行對比，以決定是否切換到輔助副本上。
HealthCheckTimeout間隔為30000毫秒。一個實例只會運行一次sp_server_dianostics，不管有多少個可用性組。多個可用性組將選擇最小的間隔設置值值除以3作為生效的間隔。sp_server_dianostics只是檢查實例的狀態，而不是檢查數據庫的狀態。
故障恢復模式：自動，手動和強制
AlwaysOn是否觸發故障轉移是由故障恢復模式和可用性模式決定的
自動故障轉移：
1）主副本和輔助副本連接狀態置為DISCONNECTED並且斷開所有客戶端連接；
2）等待輔助副本把日志操作前滾（redo）完畢
3）輔助副本切換為主副本，此時如果沒有任何可用輔助副本，主副本的可用性組狀態就是NOTSYNCHRONIZED
4）原來的主副本變成可用后變成輔助副本，同步現有主副本后面生成的日志記錄
手動故障轉移：
當主副本和輔助副本處於SYNCHRONIZED狀態時，可以執行手動故障轉移。此時不會出現數據丟失。
強制故障轉移
當主副本停止，輔助副本進入“RESOLVING”角色。此時RESOLVING角色既不是主副本也不是輔助副本。如果執行強制故障轉移把輔助副本轉成主副本，可能出現數據丟失。而且，其他副本在執行完強制故障轉移之后可能需要重新配置可用性組，因為強制故障轉移形式導致新的主副本不能確定與其他副本間的數據一致性。
手動故障轉移的途徑：
1）T-SQL語句
2）SSMS UI界面
3) PowerShell
多子網可用性組的故障轉移
客戶端應用程序使用MultiSubsetFailover來支持多子網可用性組的故障轉移，配置Listener
Split Brain（大腦分裂）
大腦分裂是指發生故障轉移時存在新的主副本上線和舊的主副本仍然在線存在的這種同時出現兩個主副本的情況。為了避免這種情況，AlwaysOn可用性組有一個叫LeaseTimeout，意思是如果主副本在LeaseTimeout之前沒有收到Windows群集服務的消息，就會自動終止SQL Server的運行。因為其實主動權在Windows群及服務手中。它認定故障轉移發生並轉向另外的新的主副本，從而不發生通信消息給舊的主副本。LeaseTimeout很快就到，這樣舊的主副本就會終止自己的服務。從而避免大腦分裂。
只讀輔助數據庫
輔助副本上的數據庫是可以被配置成只讀，然后通過AlwaysOn的只讀路由功能將只讀請求重定向到只讀輔助副本上，從而已經分擔主副本的工作負載。鑒於SQL Server允許最多可以有6個輔助副本，也就是意味着我們最多可以有6個只讀輔助數據庫來分擔讀的壓力。當然越多的輔助副本，數據滯后的可能性就越大，因為每個輔助副本的負載都不盡相同，與其增加多副本，倒不如把資源集中在兩個或者三個副本上。建議不要超過4個副本。把主副本和輔助副本都放置在同一局域網（同一台交換機相連），配置主副本和輔助副本的可用性模式為異步提交模式。雖然這樣數據滯后的發生可能性會增大，也就是數據出現延遲。這里其實是有兩種方案。一種是多個輔助副本，每個副本（包括主副本和輔助副本）的硬件配置相同（參考了攜程的架構設計），而且把輔助副本的數量保持在2個內。另外一種是主副本和輔助副本的硬件配置不相同，根據其角色的特征選定硬件，這種可以參考攜程的數據庫架構。前者的好處是可以把可用性模式設置為同步提交模式，讓可用性數據庫的數據延遲降至最低。這是基於相同的硬件和處在局域網高速網絡的條件考慮下做出的判斷。加上限定了盡可能少的輔助副本來避免過多副本造成的數據滯后影響。理論上是可以。不過即便如此，數據的延遲也肯定還是會出現。最重要的一點，也是缺點，就是硬件代碼太高了。容易造成硬件浪費。如果不是大型應用，而且對數據實時性的要求又很高，可以考慮這套做法，也就是把資源都盡量集中在兩個或者三個機器或者群集上。第二種做法是主副本使用SAN存儲結構，加上SQL Failover群集，多個輔助副本使用SSD存儲結構保證數據讀取和寫入的速度，可用性模式配置成異步，最后加上負載均衡硬件機器來分散數據讀取請求。可以參考《數據庫技術與應用專場-03AlwaysOn技術在攜程核心數據庫的應用》。對於整個架構我唯一處在的疑問在於，配置成異步提交模式以為着會出現數據延遲。而攜程的做法是通過一張代表可用性資源組時間戳的表來代表數據的新鮮度，然后應用程序在讀取輔助副本數據的時候檢查這張表以判斷是否超過數據延遲的容許程度，以決定是否把數據讀取訪問返回給主副本。如果可以有效地控制好數據延遲的上限，那也可以接受。因為這樣假設一旦出現N個線程排隊等待修改同一行數據的情況，這個時候交易事務提交后到了主副本中檢查數據行的數據版本（提交表單中帶有的，來自於輔助副本上）和數據庫中的當前行是否一致，不一致則說明數據過期，這個時候事務失敗。其實也就是要結合應用程序和數據庫技術，最后需要承當起一定的代價。我是這么看的。
SQL SERVER實現只讀輔助數據庫的重導向依靠的是：
1）它的“只讀路由”功能；
2）輔助數據庫配置為只讀模式；
3）應用程序發起連接時指定了ApplicationIntent為READONLY。
ApplicationIntent
目前支持ApplicationIntent的數據庫驅動有：SQLNCLI11 ODBC和OLEDB、.NET FRAMEWORK的SQLClient和JDBC for SQL Server 4.0
只讀路由
SQL Server的只讀路由功能會幫助你分流一部分的讀取請求去到輔助數據庫上。但是需要說明，在多個輔助數據庫的情況下，到底最后面會去到哪個輔助數據庫上是會收到路由配置和副本的狀態影響的。所以說本身SQL Server自己是沒有辦法實現負載均衡。要實現比較真實的負載均衡，你需要依靠專業的負載均衡機器來幫助實現（通過直接訪問實例名），或者通過應用程序層面編寫一套自己的算法來分攤負載。
主副本的連接訪問類型：ALL -- 默認，允許讀寫；READ_WRITE -- 不允許連接字符串帶有Application_Intent = Readonly
輔助副本的連接訪問類型：ALL -- 只是為了滿足那些無法使用Application_Intent的客戶端，其實無論如何只要嘗試修改數據都會報錯；READ_ONLY -- 為了支持只讀路由自動分流數據讀取；NONE -- 不接受任何訪問請求；
只讀路由的工作前提是Application_Intent = READONLY和使用Listener來連接可用性組。
輔助數據庫上的潛在性能問題
阻塞和死鎖
由於輔助數據庫需要和主數據庫進行數據同步，寫入操作是幾乎可能不間斷的發生，而又因為可能同時也是一個只讀的數據庫，所以鎖的沖突、阻塞和死鎖是潛在的問題。阻塞問題在AlwaysOn是有行版本控制來解決的。所有對輔助數據庫的數據查詢都運行在快照隔離級別下。即便如此，查詢還是會申請架構共享鎖（Sch-S），所以還是存在和DDL語句相沖突。死鎖也是可能發生的，不過AlwaysOn的事務日志重寫是優先級別高而不可能被選為犧牲者。
行版本控制和臨時統計信息帶來的Tempdb的空間增長
行版本控制和臨時統計信息可能帶來的Tempdb的空間增長。需要對Tempdb的合理配置，比如Growth和Maximum Size的配置，數據文件數量的配置，文件location的選擇。
監控AlwaysOn可用性組的運行狀態
1）系統視圖和動態管理視圖（DMV）
實例級別的：
sys.dm_hadr_cluster
sys.dm_hadr_cluster_members
sys.dm_hadr_cluster_networks
sys.dm_hadr_instance_node_map
sys.dm_hadr_name_id_map
可用性組級別：
sys.availability_groups
sys.availability_groups_cluster
sys.dm_hadr_availability_groups_states
可用性副本級別：
sys.availability_replicas
sys.availability_read_only_routing_lists
sys.dm_hadr_availability_replica_cluster_nodes
sys.dm_hadr_availability_replica_cluster_states
sys.dm_hadr_availability_replica_states
sys.fn_hadr_backup_is_preferred_replica
可用性數據庫級別：
sys.availability_databases_cluster
sys.databases
sys.dm_hadr_auto_page_repair
sys.dm_hadr_database_replica_states
sys.dm_hadr_database_replica_cluster_states
與可用性組的Listener相關
sys.availability_group_listener_ip_addresses
sys.availability_group_listeners
sys.dm_tcp_listener_states
2）性能計數器
SQL Server:Availability Replica
SQL Server:Database Replica
3）Dashboard
4) AlwaysOn_health會話（Extended Events）
5）SQLDIAG拓展事件日志
理論篇到此就結束了。接下來的實戰篇因為篇幅原因被拆成了兩部分：1）活動目錄域、DNS服務器和Windows故障轉移群集；2）AlwaysOn可用性組搭建；
參考：
《SQL Server 2012實施與管理實戰指南》
SQL Server 2012 - High Availability - AlwaysOn in Real-life
Prerequisites, Restrictions, and Recommendations for AlwaysOn Availability Groups (SQL Server)
Windows Server Failover Clustering (WSFC) with SQL Server
SQL Server 2012 AlwaysOn High Availability and Disaster Recovery Design Patterns