（一）SQL Server-AlwaysOn 技術：SQL Server AlwaysOn 即“全面的高可用性和災難恢復解決方案”

1、數據庫級可用性-只讀副本：SQL Server 2012-4個，SQL Server 2014-8個
a、每個節點都安裝了本地的 SQL Server，可以不使用共享存儲，但是數據庫在每個節點上的磁盤文件夾必須是一致的。
b、主節點可讀可寫，其它輔助節點只可讀。
c、全部節點都加入一個 Windows Fail-over Cluster 中。
可以為AlwaysOn可用性組配置一個偵聽器（虛擬計算機）。客戶端如果訪問這個偵聽器則可以實現read/write；客戶端如果訪問指定的輔助節點，可能實現read/write（如果該節點是主節點），或者只能read-only。

負載分離：
a、可以將一部分的read only請求發送到輔助副本：
1）第一種：修改應用程序，在客戶端實現。例如，指定將read/write都指向AlwaysOn可用性組的偵聽器（不贊成指向某個節點，因為無法確保某個節點可以write），將部分read only請求指向輔助副本。
2）第二種：為AlwaysOn可用性組配置只讀路由：
腳本如下：
ALTER AVAILABILITY GROUP [AG1]
?MODIFY REPLICA ON
N'COMPUTER01' WITH
(SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY));
ALTER AVAILABILITY GROUP [AG1]
?MODIFY REPLICA ON
N'COMPUTER01' WITH
(SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://COMPUTER01.contoso.com:1433'));

連接字符串中添加只讀意向：
Server=tcp:MyAgListener,1433;Database=Db1;IntegratedSecurity=SSPI;ApplicationIntent=ReadOnly;MultiSubnetFailover=True


2、群集：實例級可用性-AlwaysOn 故障轉移群集實例可以在最多16個節點（企業版才支持16個節點，標準版只支持2個節點）間實現故障轉移（Fail-over）。
a、數據庫必須位于共享存儲。這可能是單一故障點。一旦共享存儲崩潰了，SQL Server 服務將停止，數據將全部丟失。
b、任何時刻只有主節點提供 SQL Server 服務，其它節點的 SQL Server 服務（實例）處于“冷備”狀態。當主節點的SQL Server服務發生故障時，才自動轉移，然后由另一個備用節點繼續提供服務。


（二）群集與偵聽器
一、群集
1、 MSFC-Microsoft Failover Cluster：創建SQL Server群集之前，必須在Windows中實現一個MSFC，然后再將SQL Server安裝成為MSFC中的一個“服務與應用程序”
2、節點：同一時間只能在其中一個節點（主節點）運行這個SQL Server實例
3、Fail-over：故障轉移群集是用于獲得高可用性的，而非用于實現負載平衡，只有在發生故障時才會轉移，而不是負載平衡（Load Balance）
4、仲裁-節點配置方式：仲裁需要使用投票機制，得票超過半數的節點才能成為主節點。
　Windows Server 2003-2個節點加1個仲裁磁盤。
　Windows Server 2008則推薦使用節點多數（奇數個節點），當節點數量為偶數時才推薦添加一個仲裁磁盤。也就是說，Windows Server 2008 創建 Microfost Windows Cluster 時，仲裁磁盤（共享存儲）并不是必須的。


二、偵聽器
偵聽器在MSFC中被稱為虛擬網絡名稱（Virtual Network Name）
MSFC自身就有一個偵聽器，客戶端可以直接訪問這個偵聽器。對這個偵聽器的訪問被MSFC重定向到主節點。
1、MSFC的偵聽器
2、SQL Server Cluster的偵聽器
3、AlwaysOn可用性組的偵聽器
a、訪問AlwaysOn可用性組的偵聽器
b、直接訪問指定的節點

（三）共享磁盤
1、共享磁盤-在群集技術中可能會用到共享磁盤。這類磁盤可以被多個節點同時訪問，但任一時間只有主節點對共享磁盤享有使用權。
2、使用共享磁盤的場景
a、在搭建MSFC時，如果是偶數個節點，那么可以添加一個仲裁磁盤，從而使投票時可以形成“多數”
b、SQL Server Cluster的數據磁盤
SQL Server Cluster的本質，是將所有的SQL Server數據庫放在一個所有節點共享的磁盤上，當主節點Fail時，下一個節點通過獲得共享磁盤的使用權，從而順利啟動SQL Server實例（服務）。

（四）故障轉移
1、SQL Server 故障轉移群集
實例級的故障轉移—備用節點需要較長的時間啟動SQL Server服務，然后讀取共享磁盤上的數據，最后才接管舊節點上的客戶端請求，有時候為了實現特定的目的，需要手動將服務從一個節點切換到另一個節點
2、AlwaysOn可用性組的故障轉移
數據庫級的故障轉移—在故障轉移之前，各節點的SQL Server服務已經開啟，并且數據已經同步提交（節點之間實時同步）。因此數據庫級的故障轉移速度非常快（通常在10秒內完成）。也可以手動將主副本轉移到新的節點。

（五）數據庫鏡像
數據庫鏡像是SQL Server 2005 sp1正式引入的一項數據庫級的高可用性技術。
1、鏡像的實現-鏡像是主體服務器、鏡像服務器和見證服務器（見證服務器為可選項）之間通過TCP5022端口進行實時通信從而實現數據同步或監控。
2、鏡像的3種運行模式
a、高性能（異步）-主體服務器上的更改被異步傳送給鏡像服務器。由于是異步執行，因此對性能的影響很小
b、高安全（同步）-主體服務器上的更改被同步傳送給鏡像服務器，而且只有當這些更改同時主體和鏡像服務器上完成之后主體服務器才可以繼續下一個更改。
c、高可用（同步）-數據的更改模式與高安全模式時相同。此模式必須存在一臺見證服務器，監控主體與鏡像服務器的運行狀態。如果主體服務器變得不可用，則見證服務器會控制自動故障轉移到鏡像服務器。
3、鏡像的故障轉移
a、服務器端-如果有見證服務器，則由見證服務器控制自動故障轉移。也可以手動控制。
b、客戶端-由于鏡像技術沒有采用MSFC作為底層，因此客戶端直接連接在原來的主體服務器。
可以在客戶端的連接字符串中添加鏡像服務器的IP地址，那么客戶端在連接主體服務器失敗時會自動嘗試連接鏡像服務器。
添加連接字符器的方法，請參考 http://technet.microsoft.com/zh-cn/library/ms175484.aspx

4、鏡像技術的不足

a、客戶端不能連接到一個虛擬網絡名稱。
b、對于標準版的用戶，鏡像只能使用高安全（同步）模式，通常都會對性能帶來很大的影響。一般在實現鏡像之前都需要對數據庫做一次性能調整與優化。
c、只能針對單個數據庫。例如，SharePoint用戶希望同時對一組數據庫實現高可用，而鏡像只能一個一個地對數據庫實現。
d、鏡像服務器上的數據庫一直處于“正在還原”狀態，只能通過創建快照才能實現只讀訪問。


（六）日志傳送
1、日志傳送的實現
日志傳送依賴于傳統的Windows技術與SQL Server代理。
a、 為主數據庫創建一個事務日志備份計劃
b、 為輔助數據庫創建一個文件復制計劃
c、 為輔助數據庫創建一個事務日志還原計劃

2、事務日志還原的選項
a、無恢復模式—在這種模式時，輔助數據庫在做事務日志還原時使用WITH NORECOVERY選項（未提交的事務沒有被回滾），數據庫一直處于“正在還原”狀態，不可以訪問。
b、備用模式—在這種模式時，輔助數據庫在做事務日志還原時使用WITH STANDBY選項（將未提交的事務在一個臨時文件中回滾）。數據庫處于“只讀，備用”狀態，可以提供只讀訪問。

3、日志傳送的優勢：廣泛地部署。輔助數據庫可以提供只讀訪問，作為報表等應用程序的數據源。
4、日志傳送的不足：不支持自動的故障轉移。數據同步被拆分成3個步驟實現，因此會有較大的延時

（七）復制
復制是一個開發范疇的技術，但是也可以像日志傳送一樣作為高可用技術的一個后備選項。
1、復制的拓撲
2、復制的沖突處理
a、合并復制—合并復制允許存在沖突。當沖突發生時，合并復制將比較這些記錄的時間戳，僅保留最新的記錄（時間戳最后的那條記錄）。
b、專用的寫入區—一種方式是將read請求隨機發送給任意一個數據庫，而將write指定只寫入發布服務器。另一種方式是設置專用的寫入區，所有寫入被事先隔離，從而避免沖突。
3、復制在負載均衡中的應用—在一些稍微容忍數據同步存在延遲的場合，復制可以作為負載均衡的手段。這種實現方法，其實質是通過復制實現分布式數據庫。

（八）負載平衡

1、服務的類型
a、 無狀態的服務（stateless service）：對單次請求的處理，不依賴其他請求。
　　處理一次請求所需的全部信息都包含在這個請求里或者可以從外部獲取（例如，數據庫），服務本身不存儲任何信息。
　　IIS（Web服務）可以設計成無狀態的服務，可以實現池化（負載均衡），從而橫向擴展。

b、 有狀態的服務（stateful service）：會在自身保存一些數據。先后的請求是有關聯的，通常用于實現事務。數據庫服務一般是有狀態的服務。

2、區別
a、高可用—針對“有狀態”的服務，其目標是為了減少硬件或軟件故障造成的影響，保持業務的連續性，從而將用戶可以察覺到的停機時間送到最少。
b、 負載平衡—針對“無狀態”的服務，其目標是通過對服務的“池化”（多個服務，形成一個“池”）使客戶端的請求被分攤到多個服務

3、聯系
a、高可用技術中兼具一部分的負載分攤功能。
b、負載均衡給客戶端的感覺就像高可用技術一樣，保持了業務的連續性。

4、SQL Server 負載分離示例
生產環境通常在設計時就要考慮到未來的數據增長，并且預留負載分離的接口。

總結

以上是生活随笔為你收集整理的SQL Server关于AlwaysOn的理解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。