MSSQL AlwaysOn中的“主角色中的连接”和“可读辅助副本”
MSSQL AlwaysOn中的“主角色中的连接”和“可读辅助副本”
一、开篇
在进行配置只读路由的时候,需要进行配置可用性组中的可用性副本,如下如所示:
每一项都是啥意思可以看看这个链接
https://msdn.microsoft.com/zh-cn/library/hh213002(v=sql.120).aspx
-
在“可用性副本属性”对话框中,可以更改主角色和辅助角色的连接访问设置,如下所示:
-
对于辅助角色,从“可读取辅助角色”下拉列表中选择一个新值,如下所示:
- 否
-
不允许与此副本的辅助数据库的用户连接。它们不可用于读访问。这是默认设置。
- 仅读意向
-
仅允许与此副本的辅助数据库的只读连接。辅助数据库全都可用于读访问。
- 是
-
允许与此副本的辅助数据库的所有连接,但仅限读访问。辅助数据库全都可用于读访问。
-
对于主角色,从“主角色中的连接”下拉列表中选择一个新值,如下所示:
- 允许所有连接
-
主副本中的数据库允许所有连接。这是默认设置。
- 允许读/写连接
-
在 Application Intent 属性设置为 ReadWrite 或者未设置 Application Intent 连接属性时,将允许连接。不允许 Application Intent 连接属性设置为 ReadOnly 的连接。这可帮助阻止客户错误地将读意向工作负荷连接到主副本。有关 Application Intent 连接属性的详细信息,请参阅将连接字符串关键字用于 SQL Server Native Client。
-
看完之后几个地方很暧昧:
1.什么是“仅读意向”?
2.啥是“主角色中的连接”和“可读辅助副本”,它们都是做什么的?有啥联系?
特别对于“主角色中的连接”和“可读辅助副本”两个选项的解释,让人匪夷所思,扑朔迷离,看了网友的一些文章,基本都是配置完解释一下,但是也没讲清楚,不同的配置可能出现什么现象,
于是乎我有点较真了,有时候我较真起来,都吓到了我自己,囧!!!
分析一下:
首先:我们知道副本分为“主副本”和“辅助副本”,对应的就是上面的“主角色”和“辅助角色”,并且“主角色”只有一个
其次:像我图中的两个副本,他们的配置是一样的,是为了保证,当主副本和辅助副本因为故障切换之后,能够依然保证像故障前一样工作。
最后:我的理解是作为主角色的时候,副本的“可读辅助副本”是不生效的,而作为辅助角色时候“主角色中的连接”也是不生效的。
那么下面我就来具体看看,当只有两个副本时候,他们的不同组合会产生什么样的效果。
二、测试
1.环境呢依然是上一篇的环境:http://www.cnblogs.com/dcz2015/p/5444438.html
2.列出需要测试的观点:(测试图有点多,可以直接略过看结果和结论)
主角色中的连接 | 可读辅助角色 | 客户端行为 | 读请求 | 写请求 | |
1 | 允许所有 | 否 | 不设置ReadOnly | ||
2 | 允许所有 | 仅读意向 | 不设置ReadOnly | ||
3 | 允许所有 | 是 | 不设置ReadOnly | ||
4 | 允许所有 | 否 | 设置ReadOnly | ||
5 | 允许所有 | 仅读意向 | 设置ReadOnly | ||
6 | 允许所有 | 是 | 设置ReadOnly | ||
7 | 允许读写 | 否 | 不设置ReadOnly | ||
8 | 允许读写 | 仅读意向 | 不设置ReadOnly | ||
9 | 允许读写 | 是 | 不设置ReadOnly | ||
10 | 允许读写 | 否 | 设置ReadOnly | ||
11 | 允许读写 | 仅读意向 | 设置ReadOnly | ||
12 | 允许读写 | 是 | 设置ReadOnly |
测试1:
配置:
结果:
测试2:
配置:
结果:
测试3:
配置:
结果:
测试4:
配置:
结果:
测试5:
配置:
写数据库:
读数据库:
结果:写数据库会路由到辅助副本,辅助副本是只读的,所以抛出异常
测试6:
配置:
结果:
测试7:
配置:
结果:
测试8:
配置:
结果:
测试9:
配置:
结果:
测试10:
配置:
结果:
测试11:
配置:
结果:
写操作:
读操作:
测试12:
配置:
结果:
写操作:
读操作:
三、总结
经过上面的12次测试,进行一下总结:
主角色中的连接 | 可读辅助角色 | 客户端行为 | 读请求 | 写请求 | |
1 | 允许所有 | 否 | 不设置ReadOnly | 主副本 | 主副本 |
2 | 允许所有 | 仅读意向 | 不设置ReadOnly | 主副本 | 主副本 |
3 | 允许所有 | 是 | 不设置ReadOnly | 主副本 | 主副本 |
4 | 允许所有 | 否 | 设置ReadOnly | 主副本 | 主副本 |
5 | 允许所有 | 仅读意向 | 设置ReadOnly | 辅助副本 | 异常 |
6 | 允许所有 | 是 | 设置ReadOnly | 辅助副本 | 异常 |
7 | 允许读写 | 否 | 不设置ReadOnly | 主副本 | 主副本 |
8 | 允许读写 | 仅读意向 | 不设置ReadOnly | 主副本 | 主副本 |
9 | 允许读写 | 是 | 不设置ReadOnly | 主副本 | 主副本 |
10 | 允许读写 | 否 | 设置ReadOnly | 异常 | 异常 |
11 | 允许读写 | 仅读意向 | 设置ReadOnly | 辅助副本 | 异常 |
12 | 允许读写 | 是 | 设置ReadOnly | 辅助副本 | 异常 |
结论一:客户端配置ApplicationIntent=ReadOnly;启用只读路由功能,所有的请求先交给辅助副本来处理
结论二:客户端不配置ApplicationIntent=ReadOnly;那么读和写请求处理,都是主副本进行处理的,如1、2、3、7、8、9
结论三:在4中,主副本处理只读请求先交给辅助路由,因为所有的辅助副本都是不可写的,所以再由自己来处理只读路由
在10中,所有的辅助副本都是不可写,但是主副本又不处理ReadOnly的请求,所以就异常了
posted on 2021-04-20 09:20 stoneyeung 阅读(339) 评论(0) 编辑 收藏 举报