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可用性組性能也會存在問題。
?
posted on 2015-03-07 09:39 NET未來之路 閱讀(...) 評論(...) 編輯 收藏轉載于:https://www.cnblogs.com/lonelyxmas/p/4319778.html
總結
以上是生活随笔為你收集整理的SQL Server AlwaysOn中的几个误区的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： iOS GCD编程
- 下一篇： linux cmake编译源码,linu