Utrata komunikacji między replikami

Utrata komunikacji między replikami przerywa synchronizację danych w grupie dostępności do czasu jej przywrócenia.

Jak powstaje przerwa w komunikacji replik

Utrata komunikacji między replikami w grupie dostępności SQL Server oznacza, że instancje uczestniczące w mechanizmie Always On Availability Groups nie mogą prawidłowo wymieniać informacji przez skonfigurowane punkty końcowe bazy danych. Przyczyną może być awaria sieci, niedostępność hosta, zatrzymanie usługi SQL Server, blokada portu zapory albo problem z rozpoznawaniem nazw. Znaczenie ma również stan samego punktu końcowego: jeżeli endpoint jest zatrzymany, wyłączony lub nie może przyjmować połączeń, repliki tracą kanał używany do przesyłania bloków dziennika transakcji i komunikatów sterujących.

W grupie dostępności każda replika utrzymuje własną kopię baz danych. Replika podstawowa zapisuje operacje w dzienniku transakcji, a następnie przekazuje odpowiednie rekordy do replik pomocniczych. Gdy kanał komunikacyjny zostanie przerwany, replika pomocnicza przestaje otrzymywać nowe dane. Jej baza może przejść w stan NOT SYNCHRONIZING albo DISCONNECTED, zależnie od bieżącego stanu sesji i roli repliki. Sama awaria komunikacji nie oznacza automatycznie uszkodzenia plików bazy, ale powoduje narastanie różnicy między kopiami.

Skutki dla synchronizacji i przełączenia ról

Podczas przerwy SQL Server nie może potwierdzać dostarczenia kolejnych rekordów dziennika do niedostępnej repliki. W trybie synchronicznego zatwierdzania może to wpływać na czas wykonywania transakcji na replice podstawowej, ponieważ zakończenie zatwierdzenia zależy od potwierdzeń wymaganych przez konfigurację. W trybie asynchronicznym podstawowa replika może kontynuować pracę, lecz opóźnienie synchronizacji rośnie, a pomocnicza kopia pozostaje w tyle. Rozmiar zaległości można oceniać między innymi na podstawie liczby rekordów dziennika oczekujących na wysłanie lub ponowne wykonanie.

Przerwana komunikacja ogranicza również możliwość bezpiecznego automatycznego failoveru. Automatyczne przełączenie wymaga spełnienia warunków określonych dla grupy dostępności, w tym odpowiedniego trybu dostępności oraz stanu synchronizacji. Replika, która nie otrzymała wszystkich wymaganych zmian, może nie być aktualnym kandydatem do przejęcia roli podstawowej. Wymuszenie przełączenia na niezsynchronizowaną replikę może prowadzić do utraty transakcji, które zostały zatwierdzone na dotychczasowej replice podstawowej, lecz nie dotarły do wybranego partnera.

Rozróżnienie awarii sieci od problemu z bazą

Diagnostyka powinna rozdzielić trzy poziomy problemu: dostępność hosta, działanie usługi SQL Server oraz stan punktu końcowego grupy dostępności. Jeżeli serwer odpowiada, ale endpoint nie przyjmuje połączeń, test samej łączności z hostem nie wystarczy. Należy sprawdzić, czy instancje mogą komunikować się po właściwym porcie TCP, czy zapora nie odrzuca ruchu oraz czy nazwy używane przez konfigurację rozwiązują się na prawidłowe adresy. Przy połączeniach szyfrowanych znaczenie może mieć także poprawna konfiguracja certyfikatów i uprawnień endpointu.

Stan replik i baz można analizować w widokach dynamicznego zarządzania SQL Server, zwłaszcza sys.dm_hadr_availability_replica_states, sys.dm_hadr_database_replica_states oraz sys.dm_hadr_availability_replica_cluster_states. Przydatne są również zdarzenia rozszerzone i dziennik SQL Server, ponieważ mogą wskazać rozłączenie endpointu, ponowne nawiązanie sesji, błędy transportu lub przekroczenie limitu czasu. Warto porównać czas wystąpienia komunikatu o rozłączeniu z logami systemu operacyjnego, urządzeń sieciowych i zapory. Sam status bazy nie wskazuje jeszcze, czy źródłem problemu jest sieć, usługa, konfiguracja czy przeciążenie instancji.

Przywrócenie kanału i kontrola zaległości

Po usunięciu przyczyny komunikacja powinna zostać zweryfikowana z obu stron. Sprawdza się dostępność właściwego portu, stan endpointów, logowanie instancji oraz możliwość ponownego nawiązania sesji między replikami. Następnie należy obserwować, czy rekordy dziennika są ponownie wysyłane i wykonywane na replice pomocniczej. Stan SYNCHRONIZING oznacza trwające wyrównywanie danych, natomiast SYNCHRONIZED potwierdza osiągnięcie stanu synchronizacji wymaganej przez konfigurację. Jeżeli baza pozostaje w stanie niesynchronizowanym mimo przywrócenia sieci, trzeba sprawdzić błędy transportu, brak miejsca na dysku, opóźnienia odtwarzania dziennika i możliwość ponownego dołączenia bazy do grupy.

W środowisku produkcyjnym nie należy traktować samego zniknięcia alarmu o rozłączeniu jako dowodu pełnego przywrócenia odporności. Kontroli wymagają wszystkie bazy należące do grupy, bieżąca rola replik, tryb dostępności oraz gotowość do planowanego przełączenia. Jeżeli przerwa trwała długo, zaległy dziennik może wymagać znacznego czasu na przesłanie i odtworzenie. Dopiero po potwierdzeniu zgodności stanów oraz poprawności mechanizmu failover można uznać, że synchronizacja została rzeczywiście przywrócona.