Mirroring Endpoint to dedykowany port komunikacji wykorzystywany przez wycofaną już technologię Database Mirroring.
Rola endpointu w mechanizmie SQL Server Database Mirroring
SQL Server Mirroring Endpoint jest obiektem utworzonym na poziomie instancji aparatu Microsoft SQL Server, który zapewnia komunikację dla funkcji Database Mirroring. Nie jest to port używany przez aplikacje łączące się z bazą danych za pomocą standardowego protokołu klienta SQL Server. Połączenia aplikacyjne z principalem, czyli podstawową kopią bazy, korzystają z własnego punktu dostępu Database Engine, natomiast endpoint mirroringu służy do wymiany komunikatów między instancjami uczestniczącymi w sesji dublowania.
Komunikacja odbywa się przez protokół TCP. Adres sieciowy endpointu ma postać adresu URL, na przykład TCP://SQLHOST02.example.local:7022. Nazwa hosta identyfikuje komputer, a numer portu wskazuje konkretną instancję SQL Server. Dzięki temu na jednym komputerze mogą funkcjonować różne instancje, pod warunkiem że używają odrębnych portów dla swoich endpointów. W jednej instancji SQL Server może istnieć tylko jeden endpoint przeznaczony do Database Mirroring, dlatego jego konfiguracja musi uwzględniać wszystkie sesje, w których dana instancja uczestniczy.
Port TCP, role endpointu i stan nasłuchiwania
Endpoint jest tworzony poleceniem CREATE ENDPOINT z sekcją FOR DATABASE_MIRRORING. Parametr LISTENER_PORT określa numer portu TCP, na którym endpoint oczekuje na połączenia. Parametr ROLE wskazuje dopuszczalną rolę instancji: PARTNER dla serwera uczestniczącego jako partner mirroringu, WITNESS dla świadka albo ALL, gdy ta sama instancja ma obsługiwać obie role w różnych sesjach. Świadek uczestniczy w ustalaniu dostępności partnerów i może być używany w trybie wysokiej dostępności, ale nie przechowuje kopii dublowanej bazy tak jak partner.
Stan endpointu decyduje o tym, czy port jest aktywnie obsługiwany. Stan STARTED oznacza uruchomienie nasłuchiwania, STOPPED zatrzymuje obsługę połączeń, a DISABLED wyłącza endpoint. Podstawowe informacje można sprawdzić w widoku katalogowym sys.database_mirroring_endpoints, używając zapytania:
SELECT name, role_desc, state_desc FROM sys.database_mirroring_endpoints; Wynik pokazuje nazwę endpointu, przypisaną rolę oraz jego bieżący stan. Samo istnienie obiektu nie oznacza jeszcze poprawnej komunikacji. Konieczne jest także sprawdzenie, czy wybrany port jest dostępny na hoście, czy nie koliduje z inną usługą oraz czy zapora sieciowa dopuszcza ruch przychodzący i wychodzący.
Uwierzytelnianie, uprawnienia i diagnostyka połączenia
Endpoint Database Mirroring jest również miejscem konfiguracji zabezpieczeń transportu. Połączenie partnera lub świadka musi zostać uwierzytelnione. SQL Server może wykorzystywać uwierzytelnianie Windows, w tym mechanizm negocjacji odpowiedni dla środowiska domenowego, albo uwierzytelnianie oparte na certyfikatach. Konfiguracja endpointu określa także sposób negocjowania szyfrowania komunikatów. Uprawnienia do połączenia nie wynikają automatycznie z samego utworzenia endpointu: odpowiedni login lub konto usługi musi otrzymać uprawnienie CONNECT na konkretnym endpointcie.
Przykładowa definicja endpointu może wyglądać następująco: CREATE ENDPOINT Endpoint_Mirroring STATE = STARTED AS TCP (LISTENER_PORT = 7022) FOR DATABASE_MIRRORING (ROLE = ALL); Do wykonania instrukcji potrzebne jest uprawnienie CREATE ENDPOINT albo członkostwo w roli serwerowej sysadmin. Później stosuje się między innymi polecenie GRANT CONNECT ON ENDPOINT::Endpoint_Mirroring TO [login_name]. Brak tego uprawnienia może powodować odrzucenie połączenia mimo prawidłowego numeru portu i uruchomionego endpointu.
Diagnostyka powinna obejmować oba końce komunikacji. Należy porównać adresy użyte w instrukcjach ALTER DATABASE ... SET PARTNER lub SET WITNESS z rzeczywistymi nazwami hostów i portami, sprawdzić stan endpointu na każdej instancji, zweryfikować rozwiązywanie nazw DNS oraz reguły zapory. Nie należy zmieniać konfiguracji używanego endpointu bez analizy skutków, ponieważ partnerzy wykorzystują go do wymiany informacji o stanie sesji. Zatrzymanie albo usunięcie endpointu może przerwać działającą sesję i doprowadzić do utraty wymaganej dostępności świadka.
Znaczenie historyczne i ocena konfiguracji
Database Mirroring jest technologią wycofywaną z użycia. Microsoft oznacza ją jako funkcję przeznaczoną do usunięcia w przyszłej wersji SQL Server i zaleca, aby w nowych wdrożeniach rozważać Always On availability groups. Nie zmienia to znaczenia endpointu w istniejących instalacjach: jeżeli starsza sesja mirroringu nadal działa, endpoint pozostaje jej podstawowym kanałem komunikacji między partnerami i ewentualnym świadkiem. W dokumentacji technicznej trzeba więc odróżnić opis działającej konfiguracji historycznej od rekomendacji dla nowego projektu.
Podczas przeglądu konkretnej instancji warto ustalić, czy endpoint jest faktycznie używany, jaka jest jego rola, na którym porcie nasłuchuje i którym kontom przyznano uprawnienie CONNECT. Należy także sprawdzić zgodność ustawień uwierzytelniania i szyfrowania po obu stronach oraz dostępność portu w zaporze. Sama obecność wpisu w sys.database_mirroring_endpoints nie potwierdza poprawnego działania sesji. Ocena wymaga powiązania konfiguracji endpointu ze stanem baz, rolami principal i mirror oraz stanem całej sesji Database Mirroring.
Przy analizie problemu warto korzystać z dokumentacji Microsoft opisującej endpoint Database Mirroring, widok sys.database_mirroring_endpoints, konfigurację zabezpieczeń transportu i składnię CREATE ENDPOINT. Pozwala to odróżnić błąd sieciowy, brak uprawnienia, niezgodną rolę endpointu oraz zatrzymany stan nasłuchiwania, które mogą prowadzić do podobnych objawów w dziennikach SQL Server.
