一、開篇 在進行配置只讀路由的時候，需要進行配置可用性組中的可用性副本，如下如所示： 每一項都是啥意思可以看看這個鏈接 https://msdn.microsoft.com/zh-cn/library/hh213002(v=sql.120).aspx 在“可用性副本屬性”對話框中，可以更改主角色和輔 ...
一、開篇
在進行配置只讀路由的時候，需要進行配置可用性組中的可用性副本，如下如所示：
每一項都是啥意思可以看看這個鏈接
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的請求，所以就異常了
