从 SQL Server 2008 开始,微软在“高可用”、“灾难恢复”技术中使用 AlwaysOn 一词。在 SQL Server 2012 中,微软明确地打出的 AlwaysOn 招牌。
SQL Server AlwaysOn 即“全面的高可用性和灾难恢复解决方案”。使用 AlwaysOn,您可以提高应用程序可用性,并且通过简化高可用性 (HA) 部署和管理方面的工作,获得更好的硬件投资回报。
SQL Server AlwaysOn 在以下2个级别提供了可用性。
(1)数据库级可用性
AlwaysOn 可用性组允许将一组数据库同步到最多4个只读副本,这是SQL Server 2012 引入的新特性。SQL Server 2014 将只读副本的数量提升到8个。
特点:
每个节点都安装了本地的 SQL Server,可以不使用共享存储,但是数据库在每个节点上的磁盘文件夹必须是一致的。
主节点可读可写,其它辅助节点可读。
全部节点都加入一个 Windows Fail-over Cluster 中。可以为AlwaysOn可用性组配置一个侦听器(虚拟计算机)。客户端如果访问这个侦听器则可以实现read/write;客户端如果访问指定的辅助节点,可能实现read/write(如果该节点是主节点),或者只能read-only。
负载分离:
AlwaysOn可用性组具有一部分的负载平衡能力,即可以将一部分的read only请求发送到辅助副本。实现方法有2种。
第一种:修改应用程序,在客户端实现。例如,指定将read/write都指向AlwaysOn可用性组的侦听器(不赞成指向某个节点,因为无法确保某个节点可以write),将部分read only请求指向辅助副本。
第二种:为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')); |
上述示例中,首先将某个节点设置为允许副本READ_ONLY,然后配置辅助角色的只读路由。完成上述配置后,客户端可以在连接字符串中添加只读意向。例如,.Net Framework 4.0的示例如下:
Server=tcp:MyAgListener,1433;Database=Db1;IntegratedSecurity=SSPI;ApplicationIntent=ReadOnly;MultiSubnetFailover=True |
(2)实例级可用性
AlwaysOn 故障转移群集实例可以在最多16个节点(企业版才支持16个节点,标准版只支持2个节点)间实现故障转移(Fail-over)。
下图是一个典型的群集配置。
特点:
数据库必须位于共享存储。这可能是单一故障点。一旦共享存储崩溃了,SQL Server 服务将停止,数据将全部丢失。
任何时刻只有主节点提供 SQL Server 服务,其它节点的 SQL Server 服务(实例)处于“冷备”状态。当主节点的SQL Server服务发生故障时,才自动转移,然后由另一个备用节点继续提供服务。
区别:
让我们首先揭穿这样一个常见误解。故障转移群集是用于获得高可用性的,而非用于实现负载平衡。此外,SQL Server 没有任何内置的、自动负载平衡功能。您必须通过应用程序的物理设计来实现负载平衡。
本文出自 “我们一起追过的MSSQL” 博客,请务必保留此出处http://jimshu.blog.51cto.com/3171847/1420526