Sql-Server
永遠線上的只讀路由與外部負載均衡器
我們正在將帶有鏡像和事務複製功能的 SQL Server 2008R2 遷移到帶有 AlwaysOn 的 SQL Server 2016。到目前為止，一切都很好，但我們還有一個問題。
總是使用“只讀路由”功能還是使用外部負載平衡器來平衡副本之間的連接更好？
我讀了很多，但我沒有找到任何回饋。我發現如下：
- 我們已經在目前平台上使用了外部負載均衡器，並且執行良好
- 從 Sql server 2016 開始，我們可以在 sql server ror 中進行輪詢。
- 我們必須記住，在持久連接（或連接池）的情況下，連接將被重用，因此它將指向同一個伺服器。換句話說，連接是平衡的，而不是工作負載。這對於兩種解決方案都是一樣的。
ApplicationIntent=ReadOnly並且MultiSubnetFailover=True對這兩種解決方案都很有用。據我了解，每種解決方案的優缺點：
- Always On ROR ：可以“分組”實例，易於配置的故障轉移，很容易知道實例是主實例和實例狀態。最新（未經測試？）功能。
- 外部負載平衡：更易於管理（不需要 dba 來做網路工作），經過驗證，可以做其他負載平衡方法而不是循環（加權循環，最少連接……）。
我錯過了什麼？有人對始終使用 ROR 有任何見解或回饋嗎？
總是使用“只讀路由”功能還是使用外部負載平衡器來平衡副本之間的連接更好？
這將 100% 取決於您的需求。例如，如果您只是想讓可讀的工作負載達到輔助功能，那麼 SQL Server 內部應該沒問題。現在，如果您想根據內部使用者的位置來訪問（地理上）最接近內部使用者的輔助節點……那麼您將需要一些奇特的規則和外部負載平衡。
無論您選擇哪個，除非創建自己的執行狀況檢查或探測外部負載均衡器，否則將不知道哪些輔助伺服器是健康的或不健康的。
不需要dba來做網路工作
這兩種方式都不需要 DBA 來完成“網路”工作，您設置了 URL (SQL) 和列表 (SQL)，魔術開始發生。
有人對始終使用 ROR 有任何見解或回饋嗎？
在您需要的地方使用它，它只是集合中的另一個工具。您可能會發現直接連接到輔助伺服器更適合使用 ROR 的案例和場景……或者您可以為外部負載均衡器（如果支持）編寫自己的執行狀況檢查，以僅路由到需要佔用的輔助伺服器考慮到使用者的位置。