SQL Server AlwaysOn中的幾個誤區

    AlwaysOn自SQL Server2012之後已經發布很久了，最近我在給一些客戶做諮詢的時候經常被問起是不是應該使用AlwaysOn，從客戶的視角來看彷彿AlwaysOn是一個包治百病的良藥，但實際上沒有包治百病的良藥。因此在此我談一談AlwaysOn中的常見誤區。

 

1.AlwaysOn可以實現負載平衡。

答案是否定的，AlwaysOn在特定條件下（需要修改前端應用程式）可以負擔唯讀負載，但負載平衡是無法做到的。在SQL Server中如果希望實現負載平衡可以考慮兩個方向，通過複雜的架構以及和修改應用程式來共同實現，可以考慮的方向諸如：

可伸縮共用資料庫

該特性允許多個SQL Server執行個體串連到一個共用的唯讀儲存，從而使得報表格服務可以Scale-Out，但只能擴充唯讀負載，拓撲圖1所示。

 

圖1.可伸縮共用資料庫

 

點對點複寫

 點對點複寫允許節點中的每一個點進行更新。但點對點複寫有比較嚴格的限制，包括每個節點可更新的資料庫範圍的考慮、衝突的處理、對網路頻寬的要求、對營運人員水平的要求、對遺失資料方面的考慮等，典型拓撲圖2所示。

圖2.點對點複寫拓撲

 

分布式視圖

簡單理解，分布式視圖就是將資料分布到多個節點，通過視圖將這些資料匯總起來。這種方案需要對程式做大量修改，比較麻煩。

 

SQL Server Service Borker(SSB)

 說到這個方案，我曾經因為這個方案吃過不少苦頭。該方案實施起來過於複雜，並且需要應用程式端針對做大量修改，經常掉訊息。沒有專業的DBA來看就是自尋死路。

   

考慮第三方方案

 SQL Server一直沒有原生的負載平衡方案，如果自己沒有很強大的實力或是使用的是第三方廠商提供的產品無法修改代碼，可以考慮第三方方案，國內我知道一家公司，格瑞趨勢(http://www.grqsh.com/)專門做SQL Server上的負載平衡的方案。我在微軟舉辦的一次活動中和他們的資料庫諮詢顧問交流過，水平還不錯。

 

 

2.AlwaysOn是一個Share-Nothing方案

 只說對了一半。實際上，AlwaysOn中包含兩種方案，AlwaysOnFailover Cluster Instance可以看作之前SQL Server容錯移轉叢集的升級版本，升級的部分包括更靈活的容錯移轉策略、可以將TempDB放到本機存放區等特性。該方式是共用磁碟的解決方案。

   另一部分是AlwaysOnAvailability Group是Share-Nothing的方案，可以看作之前鏡像的升級版本，只是副本可以同時存在4個（SQL Server 2014中是8個）並且允許唯讀。

 

3.AlwaysOn是以一組資料庫為粒度，則可以執行針對改組資料庫的跨庫事務

   不允許。雖然可用性群組是以多個庫為粒度，但不允許事務中更新的資料涉及到AlwaysOn中的多個庫。

 

4.AlwaysOn中的每個節點都必須在物理機上

錯誤，實際上，AlwaysOn的WSFC也可以在虛擬環境中。

 

5.AlwaysOn可用性群組的效能會比鏡像高很多

   這也同樣是一個常見的誤區，或許和微軟對AlwaysOn的宣傳有關，我諮詢過的一些客戶都受到過微軟號稱AlwaysOn包治百病，但實際上AlwaysOn是基於鏡像，如果您的網路或IO效能存在問題，那麼即使使用了AlwaysOn可用性群組效能也會存在問題。