none
AlwaysOn路由读 只能读一台服务器的问题 RRS feed

  • 问题

  • 发现alwayson做读写分离的时候,如果采用侦听器IP连接服务器的时候,此时对于客户端来说,此集群是透明的,但是,对于设置了readonly的情况,我们读备用数据库时,始终只能读一台,即使配置了多台,只有当这台出故障后,才会连接到其它台上去

    不知道 微软为何这样设置?

    如果想对每天仅允许读的服务器都能够拿来用,这样才能达到更大的负载量,那么就必须直接指定这些数据库的地址了,就不能利用侦听器了,对此表示很遗憾!

    2014年11月11日 9:19

答案

  • there is a  thread ,Here you are:http://www.cnblogs.com/ProJKY/p/SqlServerProxy.html
    2014年11月12日 7:23
  • 分布式分区视图和 Always on 是两个不同的方向

    分布式分区视图的组成成员中,每个成员具有不同的数据,这些数据不重复,任何一个成员不响应的话,操作都受影响,这个纯粹是分布负载

    Always on主要是高可用,每个成员具有相同的数据,只要不是所有成员都出问题,否则访问不受影响,重在保证高可用,只读副本只是部分的分担负载(我记得测试的时候专门查过连接,只读连接仍然会先到主事务,也就是说,可以在主副本看到只读连接的Login 和 logout)

    所以,如果纯粹是分布负载,可以考虑分布式分区视图,主要的问题是复杂的查询可能会有问题,可能会导致链接服务器的数据会先全部读取到查询指令执行的服务器上,这种开销比较恐怖(普通的跨服务器查询也会有这样的问题),所以用分布式分区视图的话,查询可能得经过严格的审核控制

    • 已标记为答案 wanyongwy 2014年11月12日 14:47
    2014年11月12日 7:24

全部回复

  • 确实如此,不会自动均衡负载,只读只是把读取意向重定向到能够访问的第一个可读副本,这点确实挺讨厌的

    可以考虑把一些不重要的读取操作,直接连接到特定的可读副本,不好的地方在于,因为是直接连接的,所以无法享受到 Always on的好处

    2014年11月12日 1:09
  • 不曉得透過只读应用程序意向,是否能夠符合您的需求?這樣就可以透過Listener自動導向 read-only replica。

    http://msdn.microsoft.com/zh-cn/library/hh213417.aspx#ReadOnlyAppIntent


    | SQL PASS Taiwan Page | SQL PASS Taiwan Group

    | My Blog

    2014年11月12日 1:41
  • 《sqlserver2012实施与管理实战指南》
    3.只读路由

    你有两种方法来连接可读的辅助数据库。

    1、客户端应用可以指定辅助副本的真实实例名,直接连接到该实例上。

    当辅助副本的连接访问选项设置为ALL时,客户端的连接字符串不用做任何特殊设置。
    当辅助副本设成READONLY时,客户端需要将ApplicationIntent设置为ReadOnly。
    由于是直接连接辅助数据库,所以不会发生任何的连接重定向。

    2、AlwaysOn有一个叫作只读路由(Read-Only Routing)的功能。
    当客户端连接使用Listener的名字来访问SQL Server实例时,
    只读路由功能可以将来自客户端的只读请求从主副本上自动重定向到可读的辅助副本上去执行。
    客户端应用程序只需要确保连接的服务器名是Listener的名字,而无须去关心背后到底是哪个副本响应这个请求。
    这个功能可以自动分流一部分主副本的工作负载,使得主副本有更多的资源处理其他读写请求。

    如果可用性组有多个副本,你无法保证只读路由始终将所有连接全部重定向到相同的只读副本上。
    副本的运行状态的变化,副本的路由配置发生更改等因素都可能导致客户端连接到不同的只读副本。
    若要确保所有只读请求都连接到相同的只读副本,请使用指定可读辅助副本的实例名的方式来进行连接,
    而不要依靠只读路由。

    实现只读路由功能需要以下条件:

    客户端应用程序使用TCP协议,通过Listener连接到主副本,而非直接通过主副本的实例名。

    客户端应用程序的连接字符串中,将ApplicationIntent属性设置为ReadOnly。

    至少有一个辅助副本被配置为可读辅助副本,且其连接访问设置必须是ALL或者READONLY。

    已经为可用性副本配置了只读路由。这包括:

    为每个副本设置一个只读路由URL(read-only routing URL)。

    为每个副本设置其作为主副本时的只读路由列表(read-only routing list)。

    接下来详细介绍一下只读路由URL和只读路由列表。只读路由URL是一个如下形式的字符串:

    'TCP://servername.domain.com:1433' 

    如果发现了只读路由列表,主副本就会按照列表的顺序依次检查每个副本,
    直到发现第一个连接访问设置为READONLY或ALL并且可用的副本(彼此之间的ping正常)为止。

    主副本把发现的那个副本的只读路由URL通过TDS包发还给客户端。

    客户端读取URL后即重新将自己定向到那个只读辅助副本。

    所以对于每个用Listener名字发出的只读连接,它会先到主副本上转一圈,
    拿到只读辅助副本的URL以后,再连接到真正的辅助副本上。


    4.辅助数据库上可能出现的性能问题

    一个可读的辅助副本可能会同时受到读操作和写操作。读操作来自于直接连接它的客户端或者通过只读路由被重定向到它的客户端
    。而写操作只会来自于主数据库和辅助数据库之间的数据库同步。
    辅助数据库只有在重做日志的时候才会发生数据更改。
    客户端无法直接在辅助数据库上执行数据修改操作。

    像其他所有数据库一样,只读辅助数据库也有可能遇到性能问题。由于其工作方式的特殊性,其性能问题也有所不同。



    (2)系统资源的争抢

    如果读操作比较复杂,其所带来的CPU和IO的负载也可能会影响辅助数据库上重做操作的性能。
    因此,如果有一个需要长时间运行的只读操作,最好还是安排在非业务高峰时间来运行会比较好。



    2014年11月12日 2:53
  • 伤不起呀 这样很明显是一大折扣赛 不知道ORACLE的DATA GURAD 是否对只读副本也只能连一台

    邹建老师不知道对SQLSERVER的分布式分区视图有研究没有

    SQLSERVER的帮助文档如下:

    为达到最大型网站所需的高性能级别,多层系统一般在多个服务器之间平衡每一层的处理负荷。SQL Server 通过对数据库中的数据进行水平分区,在一组服务器之间分摊数据库处理负荷。这些服务器独立管理,但协作处理应用程序的数据库请求;这样一组协作服务器称为“联合体”。

    如果我们的业务所需要的数据不能容忍有任何延迟,(事务复制、always on的可读副本、日志传送可读副本、数据库镜像的快照都有数据延迟),而且这种并发量又相当的大,假设我们一台服务器已经无法升级硬件了,那么我觉得只能用多台服务器,即:分布式的,而且不能有延迟,现在能够想到的数据库的解决方案只有利用分布式分区视图达到的微软所谓的“联合数据库服务器”了

    谢谢指导!

    2014年11月12日 5:46
  • So ,why AlwaysOn is called AlwaysOn ,That's because  the high availability is the first thing to consider
    2014年11月12日 7:12
  • 的确也是这样的!那微软也应该搞个类似ORACLE RAC的东西出来赛,兼顾下高性能赛!
    2014年11月12日 7:19
  • there is a  thread ,Here you are:http://www.cnblogs.com/ProJKY/p/SqlServerProxy.html
    2014年11月12日 7:23
  • 分布式分区视图和 Always on 是两个不同的方向

    分布式分区视图的组成成员中,每个成员具有不同的数据,这些数据不重复,任何一个成员不响应的话,操作都受影响,这个纯粹是分布负载

    Always on主要是高可用,每个成员具有相同的数据,只要不是所有成员都出问题,否则访问不受影响,重在保证高可用,只读副本只是部分的分担负载(我记得测试的时候专门查过连接,只读连接仍然会先到主事务,也就是说,可以在主副本看到只读连接的Login 和 logout)

    所以,如果纯粹是分布负载,可以考虑分布式分区视图,主要的问题是复杂的查询可能会有问题,可能会导致链接服务器的数据会先全部读取到查询指令执行的服务器上,这种开销比较恐怖(普通的跨服务器查询也会有这样的问题),所以用分布式分区视图的话,查询可能得经过严格的审核控制

    • 已标记为答案 wanyongwy 2014年11月12日 14:47
    2014年11月12日 7:24
  • 感谢邹建老师的指导!

    由于现在的项目是并发量较大的典型的小事务的OLTP业务,而且很多表要求数据必须一致,不能有延迟,所以我觉得应该是适合的,而且我觉得扩展应该很方便。

    2014年11月12日 14:43
  • 感谢桦仔老师的指导!
    2014年11月12日 14:51