因為篇幅原因，AlwaysOn可用性組被拆成了兩部分：理論部分和實戰部分。而實戰部分又被拆成了准備工作和AlwaysOn可用性組搭建。
三篇文章各自的鏈接：
SQL Server ->> 高可用與災難恢復（HADR）技術 -- AlwaysOn（理論篇）
SQL Server ->> 高可用與災難恢復（HADR）技術 -- AlwaysOn（實戰篇）之建立活動目錄域、DNS服務器和Windows故障轉移群集（准備工作）
SQL Server ->> 高可用與災難恢復（HADR）技術 -- AlwaysOn（實戰篇）之AlwaysOn可用性組搭建
前面兩篇文章介紹了AlwaysOn和搭建AlwaysOn之前的准備工作。這篇文章也是這整一個系列的主題，也就是搭建AlwaysOn可用性組。
本篇主要通過一步步的步驟從如何啟動AlwaysOn，配置AlwaysOn可用性組，中間的一些其他Windows層面的配置（如防火牆），數個驗證的例子來驗證AlwaysOn的功能（故障轉移、只讀路由、只讀副本等）。這里的環境沿用了前兩篇文章所搭建的環境。
架設環境信息
域名：jerrychen.com
AlwaysOn虛擬IP地址：192.168.2.200
WSFC虛擬IP地址：192.168.2.201
WSFC群集名：AOCLUSTER
| Domain Controller | Primary Replica | Secondary Replica | |
| Server Name | dc.jerrychen.com | main.jerrychen.com | slave1.jerrychen.com |
| OS | Windows Server 2012 Data Center x64 | Windows Server 2012 Data Center x64 | Windows Server 2012 Data Center x64 |
| IP Address | 192.168.2.100 | 192.168.2.102 | 192.168.2.101 |
| Gateway | 192.168.2.2 | 192.168.2.2 | 192.168.2.2 |
| SQL Server Version | - | SQL Server 2014 enterprise x64 | SQL Server 2014 enterprise x64 |
| DNS | 127.0.0.1 | 192.168.2.100 | 192.168.2.100 |
安裝SQL Server實例和配置SQL Server服務賬戶
首先是在Main和Slave1分別安裝SQL Server 2014 Enterprise x64。以單機模式默認安裝即可，這里不細講。這樣保持默認實例名稱即可。
安裝完畢后配置DomainAdmin為服務賬號
啟用Always可用性組
然后在SQL Server Configuration Management中打開SQL Server服務的屬性界面。在AlwaysOn High Availability選項卡勾選Enable AlwaysOn Availability Groups選項。
我們就選用SQL Server數據庫最常用的DEMO數據庫 -- AdventureWorks來作為這次的實驗數據庫吧。數據庫的來源自行谷歌或者百度搜索AdventureWorks2012尋找連接下載。
配置防火牆
由於AlwaysOn需要節點間互相通信，所以我們需要在每個節點上配置防火牆保證SQL Server應用程序可以與外部進行TCP/IP通信
配置服務賬戶保證其有足夠的權限操作
如果服務賬戶不是sysadmin成員添加它作為sysadmin角色成員
滿足所有AlwaysOn可用性組創建的必要條件
數據庫完整恢復模式
有過完整備份歷史
可用性組的創建
通過向導來創建
配置可用性組名字
如果你不滿足前面的創建可用性組的條件，比如沒有完整備份過或者數據庫是只讀狀態或者單用戶模式，這里的Status會提示你。這里滿足的先決條件。
把Slave1添加進來作為輔助副本。勾選Synchronous Commit（同步提交），Up to 3的意思是最多可以有3個的同步提交模式的輔助副本。
無論是主副本或者輔助副本都選擇同步提交模式，輔助副本的Readable Secondary選擇為Yes。只是為了后面的只讀輔助數據庫准備。
AlwaysOn和鏡像一樣都采用Endpoint（端點）來進行數據傳輸。AlwaysOn使用端點是為了和輔助副本進行日志傳輸和心跳線的通信。
備份優先級勾選Prefer Secondary。意思是有限考慮輔助副本上做數據備份。只有在沒有輔助副本的情況下才使用主副本。把輔助副本的優先級別調為100，而主副本50。
最后一個頁面是Listener（偵聽器）。這里需要配置偵聽器的虛擬服務器名、端口號和IP地址。也就是前面架構環境信息里面寫的。
點擊Yes進入下一頁
這個地方是選擇初始化數據庫的方式。如果你選擇Full，你需要提供一個共享地址，AlwaysOn自己自動備份數據庫然后還原到目標的輔助副本上。這里我們選擇Join only，所以我們需要事先把數據庫備份並還原到目標的輔助數據庫上。
還原過程需要加上WITH NORECOVERY，后面才不會報錯。
確認沒有出現錯誤提示
成功把MAIN和SLAVE1加入可用性組
驗證可用性組創建的成功與否
這個時候你會發現你前面配置的虛擬服務器名出現在DNS服務器上
同樣也出現在域控制器上
通過Dashboard觀察副本的運行情況。是否可用性組處於Healthy狀態？是否副本間處於同步狀態？
仲裁信息
驗證輔助數據庫的只讀訪問是否成功
SSMS對象瀏覽器可以顯示出我們創建好的可用性組，包括主副本和輔助副本的服務器上都能顯示出來。
這個時候你嘗試用SSMS開啟一個查詢窗口，在連接前添加APPLICATIONINTENT=READONLY選項來連接SLAVE1服務器。嘗試訪問任意一張數據表。是可以只讀訪問的。
接下來換成虛擬服務器名來訪問，看看到底會不會被重導向到SLAVE1
結果可以開到還是在MAIN上面。
只讀路由功能
其實是因為我們還沒有配置只讀路由
ALTER AVAILABILITY GROUP [AG_AdventureWorks2012] MODIFY REPLICA ON N'MAIN' WITH (SECONDARY_ROLE (ALLOW_CONNECTIONS = ALL)); ALTER AVAILABILITY GROUP [AG_AdventureWorks2012] MODIFY REPLICA ON N'MAIN' WITH (SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://MAIN.jerrychen.com:1433')); ALTER AVAILABILITY GROUP [AG_AdventureWorks2012] MODIFY REPLICA ON N'SLAVE1' WITH (SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY)); ALTER AVAILABILITY GROUP [AG_AdventureWorks2012] MODIFY REPLICA ON N'SLAVE1' WITH (SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://SLAVE1.jerrychen.com:1433')); ALTER AVAILABILITY GROUP [AG_AdventureWorks2012] MODIFY REPLICA ON N'MAIN' WITH (PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('SLAVE1','MAIN'))); ALTER AVAILABILITY GROUP [AG_AdventureWorks2012] MODIFY REPLICA ON N'SLAVE1' WITH (PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('MAIN','SLAVE1'))); GO
運行下面代碼觀察前面的配置是否成功
select rp.replica_server_name, rp2.replica_server_name as readonly_replica_server_name, rl.routing_priority from sys.availability_read_only_routing_lists rl join sys.availability_replicas rp on rl.replica_id = rp.replica_id join sys.availability_replicas rp2 on rl.read_only_replica_id = rp2.replica_id
SSMS其實不太支持這個APPLICATIONINTENT=READONLY。為了測試目的，我們用SSRS報表來測試。創建一個SSRS報表，報表的Dataset的datasource使用下面的connection string，也就是加入了APPLICATIONINTENT=READONLY。然后查看服務器名。
預覽一下你就可以發現，其實是重導向只讀訪問到輔助副本的數據庫上。
驗證數據同步情況
實驗1： 簡單的測試
我們先關閉輔助副本的網卡，然后在主副本上創建一張表並插入一行記錄
可以從主副本上得Dashboard看到SLAVE1處於斷開狀態。SLAVE1的同步狀態為NOT SYNCHRONIZING。
然后我們再把網卡重新啟動，再在SLAVE1上查詢剛才在MAIN上創建的表。數據同步過來了。
實驗2： 並發測試
在MAIN上再創建一張表。然而這次我們開啟兩個會話不間斷地這張表插入數據。在兩個會話不不間斷插入數據的同時，我們再把SLAVE1的網卡切斷。
會話1：
會話2
SLAVE1的網卡切斷口我們停止兩個會話的數據庫插入操作。再來觀察下一共插入多少行記錄。
重新啟用SLAVE1的網卡，再看看是否同步過來了？而且數據也是一致的。從下圖可以看出，副本在重新恢復后會自動“跟上” -- 重做日志尾端 -- 這點是沒錯。
測試輔助副本FailOver
既然AlwaysOn主要的功能就是Failover。這里就測試下把SLAVE1的網卡斷開后，MAIN是否會接過只讀訪問的活？
可以看到重新刷新SSRS報表后，訪問的目標服務器確實變成了MAIN.
測試主副本FailOver
反過來，也是最主要的測試：主副本FAILOVER。斷開主副本網卡。
再刷新報表。發現目標的服務器變了。
觀察SLAVE1上的dashboard，我們可以看到現在SLAVE1的角色被提升為了PRIMARY。
當然，我們更重要的是測試FAILOVER后，原來的輔助副本是否能接受數據寫入。我們用AGVM這個虛擬服務器名開啟連接后新建一張表再插入一條記錄驗證是否能寫入數據。
我們再把MAIN的網卡重啟。這個時候ALWAYSON會先等待MAIN先重新加入CLUSTER的節點后再重新成為一個輔助副本。
我們再訪問MAIN數據庫，看看剛才它下線的時候在SLAVE1上創建的表被同步過來了沒有。
有一點我不解的是，在FAILOVER之后，SLAVE1的角色居然是Unknown
有人會問，那我們想把現在輔助副本再切換回主副本怎么辦？那就手動Failover咯。
Main重新成了主副本
總結：
好了。AlwaysOn系列的最后一篇文章就到此結束了。 最后在這里做一個小小的總結：AlwaysOn作為SQL Server 2012的一大特性，集之前版本中的各項HADR技術的優點於一身，確實讓人眼前一亮。它也不負它SQL Server 2012后HADR的首選技術之名。一番體驗下來，確實看到了它於Failover Cluster、Mirroring和Log Shipping等的不同點和相同點。我想它對產品而言更具又意義的是SQL Server HADR技術向來不是一項技術即可滿足公司的業務需求，往往都是結合其他的HADR的技術來達成最優的解決方案。而如今AlwaysOn的出現是給出了一個更加優秀的解決方案。在設計高可用解決方案的時候可以提供強大的功能性。
參考：
《SQL Server 2012實施與管理實戰指南》
Configure Read-Only Routing for an Availability Group (SQL Server)
AlwaysOn Client Connectivity (SQL Server)
Creation and Configuration of Availability Groups (SQL Server)
Use the Availability Group Wizard (SQL Server Management Studio)