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的请求，所以就异常了
