Serwisanci dostępni teraz · czynne całą dobę, także w weekendy i świętaWarszawa i okolice · dojazd bezpłatny
Darmowa diagnoza laptopa
Darmowa diagnoza laptopa
Dojazd do klienta bezpłatnie
Dojazd do klienta bezpłatnie
Laptopy zastępcze bezpłatnie
Laptopy zastępcze bezpłatnie
Odbiór i zwrot sprzętu bezpłatnie
Odbiór i zwrot sprzętu bezpłatnie

Listener

Termin Definicja
Listener

Listener to wirtualna nazwa sieciowa grupy dostępności, pod którą klienci łączą się z aktualną repliką podstawową.

Listener w grupie dostępności Always On

W środowisku Microsoft SQL Server Always On Availability Groups listener jest logicznym punktem dostępu do grupy dostępności. Ma własną nazwę sieciową, na przykład AGListener, oraz przypisany adres IP lub zestaw adresów IP. Aplikacja korzystająca z bazy nie musi wskazywać nazwy konkretnej instancji SQL Server, która w danej chwili pełni rolę repliki podstawowej. Zamiast tego łączy się z nazwą listenera, a mechanizmy klastra kierują połączenie do aktualnie aktywnej repliki.

Listener nie jest osobnym silnikiem bazy danych ani dodatkową kopią danych. Jest zasobem sieciowym powiązanym z grupą dostępności i zależnym od usług klastra Windows Server Failover Clustering. W jego skład wchodzą między innymi nazwa sieciowa, adres IP oraz punkt końcowy TCP, czyli numer portu, na którym SQL Server przyjmuje połączenia. Najczęściej używany jest port TCP 1433, ale w konkretnej instalacji może być skonfigurowany inny port. Numer portu musi odpowiadać konfiguracji instancji oraz ustawieniom używanym przez klientów.

Rozwiązanie nazwy i kierowanie połączenia

Gdy klient rozpoczyna połączenie, najpierw rozwiązuje nazwę listenera za pomocą DNS lub lokalnych mechanizmów rozpoznawania nazw. Otrzymany adres IP prowadzi do aktywnego zasobu sieciowego grupy dostępności. Listener przekazuje żądanie do repliki, która w danym momencie ma rolę podstawową dla wskazanej bazy. Sama nazwa listenera pozostaje stała, nawet jeśli po awarii lub planowanym przełączeniu zmieni się serwer obsługujący zapisy.

Połączenie powinno zawierać nazwę listenera oraz, jeśli jest to wymagane przez konfigurację, numer portu, na przykład w formie AGListener,1433. Użycie nazwy hosta konkretnej repliki zamiast listenera omija mechanizm automatycznego kierowania połączeń i może spowodować, że aplikacja po przełączeniu nadal będzie próbowała korzystać z poprzedniego serwera. Listener rozwiązuje problem wyboru punktu dostępu, ale nie zastępuje poprawnej konfiguracji uwierzytelniania, uprawnień ani dostępności sieciowej.

Przełączenie repliki a zachowanie klienta

Podczas failoveru rola podstawowa zostaje przeniesiona na inną replikę, a zasoby listenera są ponownie aktywowane w odpowiedniej lokalizacji. Istniejące sesje TCP nie są przenoszone między serwerami. Połączenia otwarte w chwili przełączenia mogą zostać przerwane, dlatego aplikacja musi obsługiwać błędy połączenia i ponawiać próbę na nazwie listenera. Ponowne użycie tej samej nazwy pozwala klientowi odnaleźć nową replikę podstawową bez zmiany konfiguracji aplikacji.

W grupach rozłożonych między różnymi podsieciami listener może mieć kilka adresów IP. Po przełączeniu nie każdy adres musi być natychmiast osiągalny z danej lokalizacji, ponieważ aktywna replika może znajdować się w innej podsieci. Sterownik klienta SQL Server powinien wtedy obsługiwać szybkie próby połączenia z kolejnymi adresami. W przypadku zgodnych sterowników stosuje się opcję MultiSubnetFailover=True w parametrach połączenia. Nie naprawia ona błędów DNS, zapory ani niepoprawnego routingu, lecz skraca czas wyboru osiągalnego adresu listenera w konfiguracji wielopodsieciowej.

Diagnostyka listenera w SQL Server

Sprawdzenie problemu z listenerem zaczyna się od ustalenia, czy nazwa jest poprawnie rozwiązywana i jaki adres IP zwraca klient. Następnie należy zweryfikować osiągalność tego adresu oraz portu TCP, na którym nasłuchuje właściwa instancja SQL Server. Jeżeli nazwa rozwiązuje się do nieaktualnego adresu, przyczyną może być stan zasobu klastra, opóźnienie replikacji wpisu DNS albo nieprawidłowa konfiguracja adresów w różnych podsieciach. Jeżeli adres jest prawidłowy, ale port pozostaje niedostępny, trzeba sprawdzić usługę SQL Server, reguły zapory i konfigurację punktu końcowego listenera.

Warto także porównać rolę repliki widoczną w SQL Server Management Studio lub w widokach dynamicznego zarządzania Always On z nazwą serwera używaną przez aplikację. Błąd może wynikać z połączenia bezpośrednio do repliki pomocniczej, z użycia niewłaściwego portu albo z braku obsługi ponawiania połączeń po failoverze. Listener dotyczy dostępu do grupy dostępności i zastosowania SQL Server na poziomie serwerowym, dlatego jego diagnostyka wymaga analizy jednocześnie konfiguracji grupy, klastra, DNS, sieci oraz parametrów sterownika klienta.

+48 22 100 48 29Zadzwoń teraz · serwisant w 1 godzinę