Porty dla Database Mirroring

Porty dla Database Mirroring wymagają otwarcia dedykowanego endpointu, domyślnie na porcie 5022.

Porty dla Database Mirroring — czym jest endpoint komunikacji

Porty dla Database Mirroring są elementem konfiguracji odpowiedzialnym za wymianę informacji pomiędzy instancjami Microsoft SQL Server uczestniczącymi w mechanizmie dublowania bazy danych. Nie chodzi o port aplikacji użytkowej ani o port, przez który odbywa się zwykłe logowanie do bazy. Database Mirroring korzysta z osobnego endpointu, czyli punktu komunikacyjnego przypisanego do określonej instancji. Endpoint nasłuchuje na wybranym porcie TCP i przyjmuje połączenia od drugiej instancji uczestniczącej w sesji.

W wielu konfiguracjach jako port dla Database Mirroring spotyka się numer 5022, jednak nie jest to wartość narzucona przez sam mechanizm. Można użyć innego wolnego portu, o ile ta sama wartość zostanie konsekwentnie zastosowana w definicji endpointu, regułach zapory oraz adresie używanym przez partnera. Najważniejsza jest spójność całego układu, a nie sam numer. Port powinien być przypisany jednoznacznie do usługi i nie może kolidować z innym procesem działającym na tym samym adresie IP.

Endpoint może działać w określonym stanie, na przykład jako uruchomiony, zatrzymany albo wyłączony. Samo utworzenie obiektu endpointu nie oznacza jeszcze, że komunikacja będzie możliwa. Konieczne jest jego uruchomienie, prawidłowe wskazanie adresu po stronie partnera oraz dopuszczenie ruchu TCP na drodze pomiędzy obiema instancjami. Błąd w jednym z tych miejsc może wyglądać podobnie do awarii bazy, choć źródło problemu znajduje się w komunikacji sieciowej.

Porty dla Database Mirroring a kontekst techniczny i porównania

Port Database Mirroring należy odróżnić od portu używanego przez typowe połączenia klienta z SQL Server. Aplikacja może łączyć się z instancją przez standardowy port usługi Database Engine, natomiast mechanizm mirroringu wykorzystuje oddzielny endpoint. Dzięki temu ruch związany z przesyłaniem rekordów dziennika transakcji ma własny punkt wejścia i może być kontrolowany niezależnie od połączeń użytkowników, narzędzi administracyjnych oraz aplikacji biznesowych.

W przypadku instancji nazwanej numer portu usługi SQL Server może być dynamiczny albo ustalony ręcznie. Nie należy zakładać, że port Database Mirroring będzie automatycznie taki sam. Są to dwa różne mechanizmy i dwa różne wpisy konfiguracyjne. Podobnie port używany przez SQL Server Browser nie zastępuje portu endpointu. Browser może pomagać w odnalezieniu instancji, lecz nie przenosi danych mirroringu i nie zapewnia właściwej komunikacji pomiędzy partnerami.

Warto także rozróżnić Database Mirroring od innych sposobów utrzymywania kopii bazy. Replikacja, log shipping oraz Always On korzystają z odmiennych elementów konfiguracji, dlatego reguła zapory przygotowana dla jednego rozwiązania nie musi wystarczyć dla drugiego. Przy analizie połączenia należy ustalić, jaki dokładnie mechanizm jest używany, która instancja pełni daną rolę oraz na jakim adresie i porcie nasłuchuje właściwy endpoint.

Numer portu nie zwiększa sam w sobie wydajności ani bezpieczeństwa. O tych właściwościach decydują między innymi opóźnienia sieciowe, stabilność trasy, sposób uwierzytelniania, ograniczenie źródeł ruchu oraz prawidłowe ustawienie zapory. Otwieranie szerokiego zakresu portów nie jest dobrym zamiennikiem dla wskazania konkretnego endpointu. Zalecane jest dopuszczenie wyłącznie potrzebnego ruchu pomiędzy znanymi adresami.

Porty dla Database Mirroring — typowe problemy z połączeniem

Jednym z częstszych problemów jest otwarcie portu na komputerze, na którym działa instancja, bez utworzenia reguły na urządzeniu filtrującym ruch po drugiej stronie. Komunikacja może przechodzić przez zaporę systemową, zaporę sieciową, router z regułami kontroli dostępu albo dodatkową warstwę ochrony. Jeżeli choć jeden z tych elementów odrzuca pakiety, partner nie nawiąże sesji mimo poprawnej składni polecenia konfigurującego endpoint.

Inna przyczyna to pomylenie nazwy hosta, adresu IP oraz portu. Nazwa rozwiązywana lokalnie może wskazywać inny adres niż nazwa rozpoznawana przez partnera. W środowisku z kilkoma kartami sieciowymi trzeba również sprawdzić, czy endpoint jest dostępny przez właściwy interfejs. Wskazanie adresu, który nie jest osiągalny z drugiej instancji, może prowadzić do komunikatów sugerujących problem z autoryzacją lub stanem sesji.

Problemy pojawiają się także po zmianie portu bez aktualizacji wszystkich zależności. Jeżeli endpoint nasłuchuje na nowym numerze, lecz definicja partnera nadal odwołuje się do poprzedniego, połączenie będzie kierowane w niewłaściwe miejsce. Podobny skutek daje uruchomienie dwóch usług korzystających z tej samej wartości albo wybranie portu zajętego przez inny proces. Weryfikacja powinna obejmować faktyczny nasłuch, a nie tylko zapis w dokumentacji.

Do diagnostyki przydaje się sprawdzenie stanu endpointu w katalogu systemowym SQL Server, analiza dziennika błędów oraz test połączenia TCP z hosta partnera. Test powinien być wykonywany z właściwej maszyny źródłowej, ponieważ dostęp lokalny na komputerze docelowym nie potwierdza drożności całej trasy. Warto odnotować czas wystąpienia błędu, adres docelowy, numer portu i komunikat zwrócony przez usługę. Takie dane ułatwiają odróżnienie blokady sieciowej od błędu uprawnień, certyfikatu lub konfiguracji sesji.

Porty dla Database Mirroring — praktyczne wskazówki konfiguracji

Przed wyborem numeru należy sporządzić prostą mapę komunikacji: instancja A, adres osiągalny dla instancji B, port endpointu oraz kierunek połączenia. Następnie trzeba potwierdzić, że wybrany port nie jest zajęty i że reguła zapory obejmuje właściwy protokół TCP. W regule warto ograniczyć źródło do adresu drugiej instancji, zamiast zezwalać na ruch z całej sieci. Zmniejsza to zakres niepotrzebnego dostępu i ułatwia późniejszą kontrolę.

Dobrą praktyką jest używanie stałego portu, szczególnie gdy konfiguracja ma być utrzymywana przez dłuższy czas albo odtwarzana po awarii. Port dynamiczny może utrudniać dokumentowanie i monitorowanie połączenia, ponieważ jego wartość może zmienić się wraz z konfiguracją usługi. Stała wartość, opisana w procedurze i oznaczona w regułach zapory, upraszcza przeglądy oraz diagnostykę.

Po utworzeniu lub zmianie endpointu należy wykonać test w kilku etapach. Najpierw sprawdza się, czy usługa nasłuchuje lokalnie. Potem kontroluje się możliwość połączenia z hosta partnera. Na końcu analizuje się stan sesji mirroringu oraz dzienniki obu instancji. Dopiero zgodność wszystkich trzech poziomów daje wiarygodną podstawę do uznania, że port działa prawidłowo. Sam pozytywny test lokalny nie potwierdza komunikacji zdalnej.

Zmiany powinny być wprowadzane w oknie, w którym można obserwować zachowanie usługi i szybko przywrócić poprzednią regułę. Należy zapisać poprzedni numer portu, nazwę endpointu, adresy partnerów oraz zakres modyfikacji w zaporze. Przydatne jest również sprawdzenie, czy system nie używa profilu sieciowego, dla którego obowiązuje inny zestaw reguł. Po zakończeniu prac warto usunąć tymczasowe wyjątki utworzone wyłącznie na czas testu.

Porty dla Database Mirroring — kiedy zgłosić się do serwisu

Zgłoszenie do serwisu jest uzasadnione, gdy po zmianie portu sesja nadal pozostaje rozłączona, endpoint przechodzi w nieoczekiwany stan albo komunikaty z obu instancji wskazują różne przyczyny. Szczególnej uwagi wymaga sytuacja, w której lokalny nasłuch jest prawidłowy, lecz połączenie z drugiego hosta nie dochodzi do skutku. Wtedy potrzebne jest sprawdzenie zapór, tras, rozpoznawania nazw, adresów interfejsów i ustawień samej usługi.

Warszawskie Pogotowie Komputerowe 24/7 może przeanalizować konfigurację komunikacji, uporządkować reguły dostępu i wskazać, czy problem dotyczy portu, endpointu, uprawnień czy warstwy sieciowej. Przed przekazaniem zgłoszenia warto przygotować nazwę instancji, używany adres, numer portu, opis ostatniej zmiany oraz fragmenty komunikatów z dziennika. Pozwala to rozpocząć pracę od weryfikowalnych informacji i ograniczyć ryzyko przypadkowych zmian w działającej konfiguracji.

Jeżeli Database Mirroring jest częścią ważnego procesu przetwarzania danych, nie powinno się otwierać kolejnych portów metodą prób i błędów. Najpierw należy ustalić wymagany kierunek ruchu i rolę każdego endpointu, a dopiero potem wprowadzić minimalną regułę dostępu. Port 5022 może być odpowiedni, lecz jego zastosowanie powinno wynikać z rzeczywistej konfiguracji, dostępności numeru i zasad obowiązujących w danej sieci. Najważniejsza pozostaje zgodność ustawień po obu stronach oraz możliwość potwierdzenia działania za pomocą testu TCP i stanu sesji.