Sql-Server

AlwaysOn AG 有和沒有聽眾

  • March 10, 2017

我在 AWS 上使用 AlwaysOn AG 繼承了一些 SQL Server (2014)。我對此完全陌生,我們正在談論現場生產環境。2 種不同的設置。兩者都有 2 個伺服器,每個伺服器都有一個 AG,非常簡單。但是,一組創建了一個偵聽器,而另一組則沒有。

沒有監聽器的工作正常。帶有偵聽器的那個在故障轉移時有問題。

訪問此伺服器的 GIS 應用程序在故障轉移後無法連接到它。一旦我們故障切換回原來的主節點,它又可以正常工作了。它不使用偵聽器進行連接,而是使用集群名稱。

我試圖讓他們使用監聽器,但他們說他們甚至無法連接到那個。我假設沒有正確設置監聽器。

我可以刪除偵聽器,因為它無論如何都沒有使用嗎?

但是我讀到的所有內容都說您需要使用偵聽器,但是沒有偵聽器的伺服器工作正常。我很混亂。

有人可以指出我正確的方向嗎?

但是,一組創建了一個偵聽器,而另一組則沒有。

好吧,這無助於您的應用程序保持可用!您絕對可以擁有一個沒有偵聽器的可用性組,但這種設置的用處很低。

(來自評論)監聽器是正確的方法,但它的真正功能是能夠將意圖只讀連接定向到正確的輔助節點。

這不太正確。偵聽器始終指向主副本,它的主要目的是促進透明的故障轉移,以便連接字元串不需要更改。如您所說,另一種用途是只讀路由,但主要用途實際上是透明故障轉移。

(來自評論)…但是集群名稱提供了與偵聽器相同的無縫重定向到主節點。

CNO 不知道可用性組是什麼,應該是主副本等。CNO 絕對總是指向主副本。只有當核心集群資源(包含 CNO)恰好由與 AG 主節點相同的節點擁有時,您才能使用它進行連接,但如果不是 - 並且 CNO 不跟隨 AG - 那麼它’會失敗。這是一個例子: SQL2016AGN3 上的 CNO 和 SQL2016AGN1 上的 AG

沒有監聽器的工作正常。帶有偵聽器的那個在故障轉移時有問題。

沒有偵聽器的那個可能工作正常……它在故障轉移時仍然工作正常嗎?他們是否使用其他一些 DNS 別名來像聽眾一樣“行動”。

有監聽者的那一個,他們的連接字元串是什麼樣子的?如果它沒有在連接字元串中使用監聽器名稱,那麼它當然不會工作……他們需要將它指向正確的位置,這就是監聽器存在的原因!

如果有多個子網、使用較舊的客戶端庫或某些關鍵字不在連接字元串中,則與偵聽器的連接也可能失敗。如果有多個子網,客戶端驅動程序應該支持MultiSubnetFailover關鍵字,並且應該設置為TRUE

它不使用偵聽器進行連接,而是使用集群名稱。

嗯,這就是問題的 50%。

訪問此伺服器的 GIS 應用程序在故障轉移後無法連接到它。

如果他們更新他們的連接字元串以使用監聽器並設置 MultiSubnetFailover = True 那麼我打賭它會工作……假設用於連接的客戶端庫支持它。

我試圖讓他們使用監聽器,但他們說他們甚至無法連接到那個。我假設沒有正確設置監聽器。

如果 SQL Server 為您創建了偵聽器,我非常懷疑它的設置不正確……不過我不會排除邊緣情況。

我可以刪除偵聽器,因為它無論如何都沒有使用嗎?

我會做相反的事情。讓 GIS 團隊將其連接字元串更改為偵聽器並設置 multisubnetfailover。那麼,它應該……再次與前面所說的假設一起工作。

但是我讀到的所有內容都說您需要使用偵聽器,但是沒有偵聽器的伺服器工作正常。我很混亂。

是的,您確實想使用偵聽器。它工作的事實要麼是因為有一些文件說“總是在 node3 上擁有這個”,要麼你很幸運它一直在工作。他們可能也直接在連接字元串中使用了副本名稱……這將允許它連接。根據次要角色的設置,它可能仍會或可能不會連接並正常工作……僅取決於所述設置。

引用自:https://dba.stackexchange.com/questions/166723