SQL Server 2014 通过AlwaysOn实现高可用集群及负载分离

从 SQL Server 2008 开始,微软在“高可用”、“灾难恢复”技术中使用 AlwaysOn 一词。在 SQL Server 2012 中,微软明确地打出的 AlwaysOn 招牌。 SQL Server 2014 和 SQL Server 2016对AlwaysOn功能进行了改进与升级,其中2016版本升级较大,支持了负载均衡设置和无域集群,这两个功能比较实用,可惜这次的2014没有;

  SQL Server AlwaysOn 即“全面的高可用性和灾难恢复解决方案”。使用 AlwaysOn,您可以提高应用程序可用性,并且通过简化高可用性 (HA) 部署和管理方面的工作,获得更好的硬件投资回报。

AlwaysOn主要包含以下特性:

  • 同故障转移群集一样,也需要一个虚拟网络名称用于客户端的统一连接。

  • 一个主服务器可以最多对应四个(2014后支持8个)辅助服务器,总数达到五个,而且辅助服务器支持只读功能。

  • 辅助服务器可以独立执行备份和DBCC维护命令。通过配置,可以实现客户端的只读请求可以被自动定向到辅助服务器。

  • 主服务器和辅助服务器之间的数据会被加密和压缩,以提高安全性和网络传输效率。

  • 支持自动、手动和强制三种故障转移方式。

  • 有仪表盘用于监控AlwaysOn的运行状态。

  • 可以实现多站点的部署,即主站点和辅助站点可以跨物理网络。

  SQL Server AlwaysOn 在以下2个级别提供了可用性。

(1)数据库级可用性

  AlwaysOn 可用性组允许将一组数据库同步到最多4个只读副本,这是SQL Server 2012 引入的新特性。SQL Server 2014 将只读副本的数量提升到8个。

wKiom1OJ3-_wyLYPAABep6Xbuws496.gif

特点

  每个节点都安装了本地的 SQL Server,可以不使用共享存储,但是数据库在每个节点上的磁盘文件夹必须是一致的。

  主节点可读可写,其它辅助节点可读。

  全部节点都加入一个 Windows Fail-over Cluster 中。可以为AlwaysOn可用性组配置一个侦听器(虚拟计算机)。客户端如果访问这个侦听器则可以实现read/write;客户端如果访问指定的辅助节点,可能实现read/write(如果该节点是主节点),或者只能read-only。

负载分离:

  AlwaysOn可用性组具有一部分的负载平衡能力,即可以将一部分的read only请求发送到辅助副本。实现方法有2种。

  第一种:修改应用程序,在客户端实现。例如,指定将read/write都指向AlwaysOn可用性组的侦听器(不赞成指向某个节点,因为无法确保某个节点可以write),将部分read only请求指向辅助副本。

  第二种:为AlwaysOn可用性组配置只读路由

 
     
1
2
3
4
 
     
ALTER AVAILABILITY GROUP [AG1]  MODIFY REPLICA ONN 'COMPUTER01' WITH 
(SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY));
ALTER AVAILABILITY GROUP [AG1]  MODIFY REPLICA ONN 'COMPUTER01' WITH 
(SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N 'TCP://COMPUTER01.contoso.com:1433'));

  上述示例中,首先将某个节点设置为允许副本READ_ONLY,然后配置辅助角色的只读路由。完成上述配置后,客户端可以在连接字符串中添加只读意向。例如,.Net Framework 4.0的示例如下:

 
     
1
 
     
Server=tcp:MyAgListener,1433;Database=Db1;IntegratedSecurity=SSPI;ApplicationIntent=ReadOnly;MultiSubnetFailover=True

备注:在SQL Server 2016之前,AlwaysOn功能提供的是高可用解决方案方案,并不直接包含负载均衡功能,但是可以通过配置实现数据库之间的读写分离,将Read功能指向其他不同的read only的副本,来缓解主服务器压力;

SQL Server 2014 AlwaysOn 安装说明

更多文章参考我的个人博客

http://zhangzeshuai.com/2018/04/12/sqlserver2014alwayson/

猜你喜欢

转载自blog.csdn.net/zhangzeshuai/article/details/80151702