ApplicationIntent=ReadOnly 的 AG 偵聽器問題
在解決特定問題時需要幫助，將 AG 偵聽器與
ApplicationIntent=ReadOnly. 我們有帶 AlwaysOn AG 和同步副本的 3 節點集群。所有 3 節點都在同一個數據中心 (Rackspace Dallas)。我已經證實：
- 我們正在連接到 Listener Name。
- 定義了只讀路由列表 (
READ_ONLY_ROUTING_LIST)。- 每個實例的路由 URL (
READ_ONLY_ROUTING_URL) 具有正確的 FQDN 和埠組合。ApplicationIntent在連接字元串中指定。- 是
Sync_State或SYNCHRONIZED用於SYNCHORNIZING輔助副本。- 次要副本設置為允許連接。
- 初始目錄在連接字元串中提供。
如果我 RDP 進入伺服器並通過 SSMS 從任何一個節點連接到 AG 偵聽器，則具有隻讀意圖連接的 AG 偵聽器工作正常。我們在 Rackspace 中託管我們的伺服器。但是，如果我使用外部網路（從我的辦公室位置）連接到 AG 偵聽器（使用面向公眾的 IP），則正常連接工作正常，但不是只讀意圖。
排除了驅動程序和 SSMS 版本問題，因為我在 SQL Server 2008 R2、2012 和 2016 上使用各自的 SSMS 版本進行了檢查。所有機器上的 .NET 執行時間都是 4.0.3+，所以這不是問題。
所有 3 節點都通過專用交換機連接以進行複制（192.168.5.x 子網），並且所有 3 節點也可以通過面向公眾的 IP（通過防火牆的 192.168.99.x 子網）訪問。可以從我們的辦公地點（Rackspace 外部）通過各自的 IP 訪問所有節點。AG 偵聽器配置為響應 (192.168.5.x 和 (192.168.99.x) 以實現冗餘。也可以通過主機名、IP 和 FQDN 將一個節點 ping 到另一個節點。
唯一缺少的是 AG 偵聽器的 DNS 條目，我將創建它以排除該問題。但是，我使用 IP 地址從我們的辦公地點連接到數據中心。
這在內部Rackspace 位置****之外失敗的原因是 URL Endpoints 設置為無法從本地環境連接的值。
我在這篇博文中從高層次上討論了這個過程，但是為了快速回顧一下需要在這裡提出的觀點：
端點 url 是連接路由的地址，以便連接和執行查詢。
$$ roughly speaking $$
該 URL 是特定於活動目錄的 FQDN，因此我不能從我們的 racksapce 域中使用它。ROR URL 類似於“tcp://1234-db1.abc.intensive.int:1433”
這意味著客戶端驅動程序將重新指向該地址；如果地址無法訪問，那麼驅動程序將無法連接，您將遇到問題 - 您碰巧遇到了這個問題。
在您的範例中，客戶端驅動程序將返回 **“tcp://1234-db1.abc.intensive.int:1433”**並嘗試連接到它，就像它連接任何其他 SQL Server 實例一樣。由於它不能（如您所說），因此您將無法被路由，因此您的連接應該位於主伺服器上。我所做的是我將每個節點的 ROR URL 更改為公共 IP 地址而不是 FQDN/主機名，因此當請求從外部發送到 AG 偵聽器時，它知道在面向公眾的 IP 中的切換位置。看起來，如果我們必須從外部連接，我必須使用公共 IP（例如：72.32.XX.XX），而不是 ROR 中的 tcp://1234-db1.abc.intensive.int:1433。
雖然 IP 可能需要也可能不需要公開（不同公司的不同架構可能需要也可能不需要不同的東西），但在您的情況下似乎確實如此……雖然我不是網路架構大師，所以我可以t 評論如何/為什麼實施或觀察到任何技術挑戰。
此外，當我們將應用程序部署在與 db 伺服器 Active Directory 域“abc.intensive.int”相同的域中時，當應用程序嘗試連接到 db AG 偵聽器時，這是否會造成問題？
域在這裡不應該有所作為，真正的區別在於您的 DNS 是否設置在可以執行獲取資訊所需的查找的位置（IIRC 這將是一個反向查找區域，但不要引用我的話） . 如果您可以解析 DNS 名稱，它會正常工作，如果您不能，它顯然不會……這對於您的 DNS/AD 管理員來說更像是一個問題，因為他們擁有該王國的所有資訊。