一、AlwaysOn簡介
AlwaysOn可用性組是SQL Server 2012中提供的全新功能，確保了應用程序數據的可用性，實現零數據丟失。AlwaysOn可用性組技術融合了數據庫群集和數據庫鏡像的優點，此技術的一大好處是提供非共享存儲，可以避免因為存儲的單點故障而造成的整個可用性方案失效。
AlwaysOn可用性組基於數據庫(組)級別，是將一組用戶數據庫(可以是一個或多個)划到一個組中。每組可用性數據庫都由一個可用性副本承載。可用性副本包括一個主副本和一到四個輔助副本。 主副本用於承載主數據庫，輔助副本則承載一組輔助數據庫並作為可用性組的潛在故障轉移目標。主副本使主數據庫可用於客戶端的讀寫連接，實現對數據庫的更改操作。 同時在數據庫級別進行同步。 主副本將每個主數據庫的事務日志記錄發送到每個輔助數據庫。 每個輔助副本緩存事務日志記錄，然后將它們還原到相應的輔助數據庫。 主數據庫與每個連接的輔助數據庫獨立進行數據同步。 因此，一個輔助數據庫可以掛起或失敗而不會影響其他輔助數據庫，一個主數據庫可以掛起或失敗而不會影響其他主數據庫。
部署 AlwaysOn 可用性組需要一個 Windows Server 故障轉移群集 (WSFC) 群集。 給定可用性組的每個可用性副本必須位於相同 WSFC 群集的不同節點上。 部署AlwaysOn可用性組時，系統會為每個可用性組創建一個 WSFC 資源組。WSFC 群集將監視此資源組，判斷節點間的狀態，以便評估主副本的運行狀況。 當發生失敗時實現故障的轉移，針對 AlwaysOn 可用性組的仲裁基於 WSFC 群集中的所有節點，而與某一給定群集節點是否承載任何可用性副本無關。
用戶可以通過創建一個可用性組偵聽器來提供到給定可用性組的主副本的客戶端連接。 “可用性組偵聽器”采用DNS名稱的方式連接給定可用性組的資源，以便將客戶端連接定向到相應的可用性副本。
對於每個可用性副本，AlwaysOn所支持的事務提交模式分為同步提交模式或異步提交模式。在異步提交模式下，主副本無需等待確認異步提交輔助副本已強制寫入日志，便可提交事務。 異步提交模式可最大限度地減少輔助數據庫上的事務滯后時間，但允許它們滯后於主數據庫，因此可能會導致某些數據丟失。此可用性模式是一種災難恢復解決方案，適合於可用性副本的分布距離較遠的情況;所謂同步提交模式是指在提交事務之前，同步提交主副本要等待同步提交輔助副本確認它已完成強制寫入日志。 同步提交模式可確保在給定的輔助數據庫與主數據庫同步時，充分保護已提交的事務。 這種保護的代價是延長事務滯后時間。此可用性模式相對於性能而言更強調高可用性和數據保護，當主副本和輔助副本距離較近時可以使用此方法，解決時時同步的問題。
當Windows群集觸發故障轉移后，故障轉移目標（原先的輔助副本）能夠接管主副本角色，對自己管理的數據庫進行恢復操作，使它們作為新的主數據庫。原先的主副本如果在故障轉移后還可用，就會成為輔助副本，它上面的數據庫就成為了輔助數據庫。
故障轉移形式是由主副本和故障轉移目標兩者的模式所共同決定的。兩個副本間要發生自動故障轉移，需要兩者都配置為同步提交模式+自動故障轉移模式。兩者中有一個配置了手動故障轉移，則自動故障轉移就不能發生。兩者間有一個配置了異步提交模式，則它們之間就只能發生強制故障轉移。
強制故障轉移可能會丟失數據。自動故障轉移和手動故障轉移會保證數據的安全。為了防止丟失數據，自動故障轉移和手動故障轉移都要求故障轉移目標是使用同步提交模式的輔助副本且當時處於SYNCHRONIZED狀態。如果已處於SYNCHRONIZED狀態的輔助副本發出強制故障轉移命令，其行為與手動故障轉移時的行為相同。對於異步提交模式的輔助副本，無論數據是否已經達到同步，它永遠只會處於SYNCHRONIZING狀態，於是它只能支持強制故障轉移這一種形式。
相對於數據庫鏡像，AlwaysOn的一個重要優勢就是可以將輔助數據庫配置成可讀模式，這極大地增強了數據庫整體的伸縮性。通過將只讀請求分流到輔助數據庫，主副本的工作負載得到了減輕，讀和寫之間的沖突可以得到緩解，輔助副本的硬件資源也能得到利用。同時，通過AlwaysOn的“只讀路由”功能，只讀操作可以動態地被轉向輔助副本。在一定程度上，可以實現對終端用戶透明。利用這個功能，SQL Server可以實現工作負荷的Scale-out（由多台SQL Server同時響應客戶端發來的工作負載）。當客戶端連接使用Listener的名字來訪問SQL Server實例時，只讀路由功能可以將來自客戶端的只讀請求從主副本上自動重定向到可讀的輔助副本上去執行。客戶端應用程序只需要確保連接的服務器名是Listener的名字，而無須去關心背后到底是哪個副本響應這個請求。這個功能可以自動分流一部分主副本的工作負載，使得主副本有更多的資源處理其他讀寫請求。
要讓只讀操作能“透明”地被自動轉向輔助副本，必須解決下面三個問題：
-
客戶端要標明自己發來的操作是“只讀”操作。這個判定是程序開發員在編寫程序的時候，通過ApplicationIntent關鍵字指定的，ApplicationIntent=ReadOnly，ApplicationIntent=ReadWrite
-
輔助數據庫要被配成可讀模式。
-
客戶端的連接，要能夠被重定向到可讀輔助副本。AlwaysOn是用“只讀路由”機制來實現的。
本文原始出處：江健龍的技術博客 http://jiangjianlong.blog.51cto.com/3735273/1791763
二、部署環境准備
1、部署環境
2、創建故障轉移群集，使用共享磁盤作為仲裁盤。如果有3個以上節點，可以不必使用仲裁盤，但是使用仲裁盤仍是保障群集良好運行的推薦方式
3、在兩個節點都獨立安裝SQL2012SP1，注意是獨立安裝，而非群集節點安裝
4、在兩個節點都啟用SQL Server Always On可用性組
5、在SQL2012-01上創建TestDB，並設置恢復模式為完整
6、為TestDB做一次完整備份
7、將存儲備份包的目錄共享出來並設置相應的權限
三、配置Always On可用性組
1、使用向導創建可用性組
2、指定可用性組名稱
3、選擇要添加到可用性組中的數據庫
選要添加到可用組中的數據庫。這些數據庫將會成為一個整體一同發生故障轉移。在一個可用性組里最多可以添加100個數據庫。在數據庫名的右側，會顯示數據庫的狀態。如果該數據庫的狀態不滿足可用組的要求，那么就無法勾選這個數據庫。數據庫要滿足的要求包括：
需要是用戶數據庫，系統數據庫不能加入可用性組。
數據庫可以讀寫。只讀的數據庫不允許加入可用性組。
數據庫要處於多用戶模式。
數據庫沒有使用AUTO_CLOSE。
數據庫的恢復模式是完全恢復。
數據庫已經做過完整備份。
不屬於任何其他的可用性組。
數據庫上沒有配置數據庫鏡像。
4、指定副本
點擊添加副本，把第二個節點SQL2012-02添加進來（最多可以有5個可用性副本），並指定每個可用性副本的模式：
同步提交模式：該模式決定了主副本和輔助副本之間是否要保持完全同步。最多可以有3個同步提交副本。
自動故障轉移模式：該模式決定了當主副本失敗時是否將可用性組轉移到指定的輔助副本上。最多可以將兩個可用性副本配置為自動故障轉移。
可讀輔助副本：該模式決定了該副本作為輔助副本時是否可讀。
5、配置端點
端點是AlwaysOn可用性組的重要組成部分，它的主要作用有兩個：
（1）主副本和輔助副本之間通過端點傳送日志塊和消息，同步數據。
（2）主副本和每個輔助副本通過端點互相發送ping來確定彼此是否互相連通
端點的配置按默認即可。
6、指定備份首選項和優先級
首選輔助副本：如果有任何輔助副本可用，備份都應該在輔助副本上執行。如果主副本是唯一還處於在線狀態的副本，那么備份才會在主副本上執行。
副本備份優先級：1表示最低優先級，100表示最高優先級。默認情況下，所有輔助副本都具有相同的備份優先級，如果保持這個設置，Always On就必須使用其他因素來決定執行備份的副本。
7、創建偵聽器
只能通過 SQL Server 為每個可用性組創建一個偵聽器。 通常情況下，每個可用性組只需要一個偵聽器。偵聽器就是一個虛擬的網絡名稱，可以通過這個虛擬網絡名稱訪問可用性組，而不用關心連接的是哪一個節點，它會自動將請求轉發到主節點，當主節點發生故障后，輔助節點會變為主節點，偵聽器也會自動去偵聽主節點。
創建偵聽器需要提供：
（1）IP地址。建議使用靜態IP地址
（2）網絡名（DNS名）。確保該名字在網絡上是唯一的。這個名字就是應用程序用來連接主副本的接口，它和任意一個副本的服務器名都不相同。
（3）端口號。需要指派一個服務器上未被使用的端口。這樣副本實例才能成功綁定和監聽這個端口。
8、選擇初始數據同步
其他的副本通過這個共享目錄獲得數據庫的備份並在各自的實例上進行還原。這個和日志傳送進行初始化的步驟很像。這里要確保每個副本實例的服務賬戶對共享目錄和本地目錄有合適的讀寫權限。另外要注意，通過這種方式初始化，要確保主副本上存放主數據庫文件的路徑在輔助副本上也存在。
9、驗證可用性組
10、可用性組摘要
11、完成可用性組的創建
四、可用性組創建完成后檢查
1、在故障轉移群集中確認可用性組
已創建群集資源組AlwaysOnGrp01,並承載在SQL2012-01節點上。
2、登錄SQL2012-01確認是主副本
3、登錄SQL2012-02確認是輔助副本
4、使用偵聽器名稱登錄確認是登錄到主副本
五、讀寫分流配置與測試
通過將只讀請求分流到輔助數據庫，主副本的工作負載得到了減輕，讀和寫之間的沖突可以得到緩解，輔助副本的硬件資源也能得到利用。同時，通過Always On的“只讀路由”功能，只讀操作可以動態地被轉向輔助副本。在一定程度上，可以實現對終端用戶透明。利用這個功能，SQL Server可以實現工作負荷的Scale-out（由多台SQL Server同時響應客戶端發來的工作負載）。當客戶端連接使用偵聽器的名字來訪問SQL Server實例時，只讀路由功能可以將來自客戶端的只讀請求從主副本上自動重定向到可讀的輔助副本上去執行。客戶端應用程序只需要確保連接的服務器名是偵聽器的名字，而無須去關心背后到底是哪個副本響應這個請求。這個功能可以自動分流一部分主副本的工作負載，使得主副本有更多的資源處理其他讀寫請求。
1、建立read指針
SQL 語句如下：
ALTER AVAILABILITY GROUP [AlwaysOnGrp01]
MODIFY REPLICA ON
N'SQL2012-01' WITH
(SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'tcp://SQL2012-01.lab-sql.com:1433'))
ALTER AVAILABILITY GROUP [AlwaysOnGrp01]
MODIFY REPLICA ON
N'SQL2012-02' WITH
(SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'tcp://SQL2012-02.lab-sql.com:1433'))
2、建立primary、 read db ur list關系
在當前的primary上為各個primary建立對應的read only url 列表（有優先級概念），為每個可能成為primary角色的server，建立相應的只讀列表，下面的代碼由於互為readonly server，因此優先級都是1，SQL 語句如下：
ALTER AVAILABILITY GROUP [AlwaysOnGrp01]
MODIFY REPLICA ON
N'SQL2012-02' WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('SQL2012-01')));
ALTER AVAILABILITY GROUP [AlwaysOnGrp01]
MODIFY REPLICA ON
N'SQL2012-01' WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('SQL2012-02')));
3、查看關系與優先級
SQL 語句如下：
select ar.replica_server_name, rl.routing_priority,
(select ar2.replica_server_name
from sys.availability_read_only_routing_lists rl2
join sys.availability_replicas AS ar2 ON rl2.read_only_replica_id = ar2.replica_id
where rl.replica_id=rl2.replica_id and rl.routing_priority =rl2.routing_priority
and rl.read_only_replica_id=rl2.read_only_replica_id) as 'read_only_replica_server_name'
from sys.availability_read_only_routing_lists rl join sys.availability_replicas AS ar ON rl.replica_id = ar.replica_id
4、 測試連接到輔助副本
（1）使用偵聽器名稱連接數據庫
（2）指定要連接的數據庫是TestDB
（3）通過ApplicationIntent關鍵字ApplicationIntent=ReadOnly標明客戶端發來的操作是“只讀”操作
（4）成功連接到輔助副本
六、可用性組的故障轉移測試
1、斷開SQL2012-01的網卡，模擬主副本故障
2、群集資源組已自動轉移到SQL2012-02上
3、SQL2012-02已由輔助副本變為主副本
4、將SQL2012-01的網卡恢復連接
5、確認SQL2012-01警告消除（仍然為輔助副本）
