Dashboard Always On

Dashboard Always On to panel wizualizujący stan grup dostępności w konfiguracji wysokiej dostępności SQL Server.

Panel Always On w SQL Server Management Studio

Dashboard Always On to widok diagnostyczny dostępny w SQL Server Management Studio, służący do obserwowania stanu grup dostępności Always On Availability Groups w aparacie Microsoft SQL Server. Panel przedstawia zależności między grupą dostępności, jej replikami oraz bazami danych należącymi do tej grupy. Dzięki temu można ocenić, czy konfiguracja wysokiej dostępności działa zgodnie z założeniami i czy wszystkie uczestniczące instancje SQL Server komunikują się prawidłowo.

Dashboard nie jest osobnym silnikiem bazy danych ani usługą przechowującą kopie danych. Jest interfejsem administracyjnym, który odczytuje informacje o stanie grupy dostępności z instancji SQL Server. Jego wskazania należy interpretować w kontekście konfiguracji replik, trybu dostępności, trybu failover oraz bieżącego stanu poszczególnych baz danych.

Hierarchia grupy, replik i baz danych

Najważniejszym elementem panelu jest hierarchiczny obraz grupy dostępności. Grupa Always On obejmuje określony zestaw baz danych, które są replikowane między instancjami SQL Server. Każda replika dostępności działa na konkretnej instancji i może pełnić rolę podstawową albo pomocniczą. Replika podstawowa przyjmuje operacje zapisu, natomiast replika pomocnicza otrzymuje zmiany za pośrednictwem mechanizmu transportu dziennika transakcji i odtwarza je lokalnie.

Dashboard pozwala powiązać komunikat dotyczący grupy z konkretną repliką lub bazą. Jest to istotne, ponieważ problem zgłoszony na poziomie całej grupy może wynikać z pojedynczego elementu: zatrzymanego endpointu bazy danych, przerwanej sesji między replikami, niedostępnej instancji albo bazy, która nie została poprawnie dołączona do grupy. Sam fakt, że jedna replika jest dostępna, nie oznacza jeszcze prawidłowej synchronizacji wszystkich baz.

Synchronizacja i sygnały ostrzegawcze

W widoku Always On analizuje się między innymi stan synchronizacji baz danych oraz ogólną kondycję replik. Baza może znajdować się w stanie zsynchronizowanym, synchronizującym, niesynchronizowanym albo niedostępnym. Znaczenie danego stanu zależy od roli repliki i wybranego trybu dostępności. W trybie synchronicznego zatwierdzania transakcja na replice podstawowej jest powiązana z potwierdzeniem zapisu na odpowiedniej replice pomocniczej. W trybie asynchronicznym replika pomocnicza może pozostawać chwilowo za podstawową, ponieważ potwierdzenie nie musi czekać na zakończenie odtwarzania po stronie odbiorcy.

Ostrzeżenie w panelu nie wskazuje automatycznie jednej przyczyny awarii. Należy sprawdzić, czy dotyczy transportu dziennika transakcji, kolejki wysyłania, kolejki odtwarzania, połączenia między replikami, endpointu Database Mirroring lub samej bazy danych. Przydatne są również informacje z widoków dynamicznych Always On, w szczególności sys.dm_hadr_availability_replica_states, sys.dm_hadr_database_replica_states oraz sys.dm_hadr_availability_replica_cluster_states. Dane z tych widoków można zestawić z wpisami w dzienniku błędów SQL Server i dzienniku zdarzeń systemu Windows.

Stan oznaczony jako niesynchronizowany może oznaczać opóźnienie, ale może też sygnalizować trwającą awarię replikacji. Trzeba odróżnić krótkotrwałą różnicę wynikającą z obciążenia od sytuacji, w której kolejka zmian stale rośnie albo odtwarzanie jest zatrzymane. Dopiero analiza czasu wystąpienia problemu, stanu połączenia i komunikatów błędów pozwala ocenić, czy możliwe jest bezpieczne przełączenie ról.

Weryfikacja gotowości do przełączenia

Dashboard Always On pomaga przygotować kontrolę przed planowanym przełączeniem awaryjnym, ale nie zastępuje procedury operacyjnej ani oceny wymagań konkretnej konfiguracji. Przed failover należy ustalić, która replika ma przejąć rolę podstawową, czy odpowiednie bazy są zsynchronizowane oraz czy wybrana replika obsługuje wymagany tryb przełączenia. Wymuszenie przełączenia na replikę niesynchronizowaną może prowadzić do utraty transakcji, które nie zostały jeszcze dostarczone lub odtworzone.

Weryfikacja powinna obejmować także dostępność listenera grupy dostępności, rozwiązywanie jego nazwy, działanie portów używanych przez endpointy oraz poprawność połączeń aplikacyjnych. Po zmianie roli trzeba sprawdzić, czy aplikacja łączy się z listenerem, a nie ze stałą nazwą konkretnej instancji. Należy również potwierdzić stan baz po przełączeniu, ponieważ prawidłowy status repliki nie wyklucza problemu z pojedynczą bazą, uprawnieniami lub konfiguracją klienta.

Jeżeli panel pokazuje niezgodność, właściwym działaniem jest zebranie stanu wszystkich elementów w tym samym momencie i porównanie go z historią zdarzeń. Restart usługi SQL Server, ponowne dołączanie bazy albo wymuszanie failover bez ustalenia przyczyny może zwiększyć zakres problemu. Dashboard jest więc punktem obserwacji i korelacji danych, a nie mechanizmem automatycznej naprawy grupy dostępności.