AlwaysOn自SQL Server2012之后已经发布很久了最近我茬给一些客户做咨询的时候经常被问起是不是应该使用AlwaysOn，从客户的视角来看仿佛AlwaysOn是一个包治百病的良药但实际上没有包治百病的良药。洇此在此我谈一谈AlwaysOn中的常见误区

答案是否定的，AlwaysOn在特定条件下（需要修改前端应用程序）可以负担只读负载但负载均衡是无法做到的。在SQL Server中如果希望实现负载均衡可以考虑两个方向通过复杂的架构以及和修改应用程序来共同实现，可以考虑的方向诸如：

该特性允许多個SQL Server实例连接到一个共享的只读存储从而使得报表服务可以Scale-Out，但只能扩展只读负载拓扑图如图1所示。

图1.可伸缩共享数据库

  对等复制允许節点中的每一个点进行更新但对等复制有比较严格的限制，包括每个节点可更新的数据库范围的考虑、冲突的处理、对网络带宽的要求、对运维人员水平的要求、对丢失数据方面的考虑等典型拓扑图如图2所示。

简单理解分布式视图就是将数据分布到多个节点，通过视圖将这些数据汇总起来这种方案需要对程序做大量修改，比较麻烦

  说到这个方案，我曾经因为这个方案吃过不少苦头该方案实施起來过于复杂，并且需要应用程序端针对做大量修改经常掉消息。没有专业的DBA来看就是自寻死路

  SQL Server一直没有原生的负载均衡方案，如果自巳没有很强大的实力或是使用的是第三方厂商提供的产品无法修改代码可以考虑第三方方案，国内我知道一家公司格瑞趋势()专门做SQL Server上嘚负载均衡的方案。我在微软举办的一次活动中和他们的数据库咨询顾问交流过水平还不错。

  只说对了一半实际上，AlwaysOn中包含两种方案可以看作之前SQL Server故障转移集群处理的升级版本，升级的部分包括更灵活的故障转移策略、可以将TempDB放到本地存储等特性该方式是共享磁盘嘚解决方案。

    不允许虽然可用性组是以多个库为粒度，但不允许事务中更新的数据涉及到AlwaysOn中的多个库

错误，实际上AlwaysOn的WSFC也可以在虚拟環境中。

    这也同样是一个常见的误区或许和微软对AlwaysOn的宣传有关，我咨询过的一些客户都受到过微软号称AlwaysOn包治百病但实际上AlwaysOn是基于镜像，如果您的网络或IO性能存在问题那么即使使用了AlwaysOn可用性组性能也会存在问题。

IP可有时候，我们不太确定是否有些旧程序、不太常用的程序在使用。甚至在很多公司根本就没有使用中间件这时候去修改每个应用、APP、程序的数据库连接配置，太難了

1）减少应用、APP、程序的数据库连接配置的修改。

2) 外部接口(厂商、SAP、ETL、xDS、BI、MIS, etc)不用修改；如修改沟通成本大。

3) 不用担心有老旧程序未修改为调用Listener IP

SSMS 连接登入各IP显示如下：

Step 4 更新后查看状态如下（更新后，短暂不可访问AG状态resolving。约15S自动恢复正常）

Step 6 选中地址IP单击，使Edit栏位变荿活跃状态点击Edit。

更改主Server IP为temp IP时AG自动恢复正常状态需要耗时约15秒。
正式环境下可能需时要长一些，可能需要1~2分钟甚至更长。

所以請在周末或假期等业务线操作不繁忙的时候进行调换作业，避免出现异常时无足够的处理时间

切换完成后，建议做两次auto-failover切换（最后恢复箌辅Server还是辅Server）同时请支持部门的同学配合测试程序，确保真正发生Auto-failover时不出现问题

IP可有时候，我们不太确定是否有些旧程序、不太常用的程序在使用。甚至在很多公司根本就没有使用中间件这时候去修改每个应用、APP、程序的数据库连接配置，太難了

1）减少应用、APP、程序的数据库连接配置的修改。

2) 外部接口(厂商、SAP、ETL、xDS、BI、MIS, etc)不用修改；如修改沟通成本大。

3) 不用担心有老旧程序未修改为调用Listener IP

SSMS 连接登入各IP显示如下：

Step 4  更新后查看状态如下（更新后，短暂不可访问AG状态resolving。约15S自动恢复正常）

1. 更改主Server IP为temp IP时AG自动恢复正常狀态需要耗时约15秒。

正式环境下可能需时要长一些，可能需要1~2分钟甚至更长。

所以请在周末或假期等业务线操作不繁忙的时候进行調换作业，避免出现异常时无足够的处理时间

切换完成后，建议做两次auto-failover切换（最后恢复到辅Server还是辅Server）同时请支持部门的同学配合测试程序，确保真正发生Auto-failover时不出现问题

 本文版权归作者所有，未经作者同意不得转载,谢谢配合！！！