W tym artykule omówimy kilka problemów, które możesz napotkać podczas tworzenia, konfigurowania lub utrzymywania witryny Always on Availability Group.

Przed przejściem do tego artykułu zaleca się przeczytanie poprzedniego artykułu, Konfigurowanie i konfigurowanie zawsze włączonej grupy dostępności w programie SQL Server, aby zapoznać się z koncepcją zawsze włączonej grupy dostępności i kreatorami nowej grupy dostępności przedstawionymi w tym artykule.

Zawsze włączona funkcja grupy dostępności nie jest włączona

Załóżmy, że podczas próby utworzenia nowej grupy Always On Availability w węźle Always On High Availability w Eksploratorze obiektów programu SQL Server Management Studio napotkałeś następujący komunikat o błędzie:

Funkcja Zawsze włączone grupy dostępności musi być włączona dla wystąpienia serwera „SQL1”, zanim będzie można utworzyć grupę dostępności w tym wystąpieniu. Aby włączyć tę funkcję, otwórz Menedżera konfiguracji programu SQL Server, wybierz Usługi serwera SQL, kliknij prawym przyciskiem myszy nazwę usługi programu SQL Server, wybierz Właściwości i użyj karty Zawsze włączone Grupy dostępności w oknie dialogowym Właściwości serwera. Włączenie zawsze włączonych grup dostępności może wymagać, aby wystąpienie serwera było obsługiwane przez węzeł Windows Server Failover Cluster (WSFC). (Microsoft.SqlServer.Management.HadrTasks)

Z komunikatu o błędzie jasno wynika, że ​​funkcja AlwaysOn Availability Groups powinna być włączona w każdej instancji SQL Server, która uczestniczy w witrynie Always on Availability Group, przed utworzeniem tej witryny.

Możesz łatwo włączyć funkcję Always on Availability Group, otwierając konsolę SQL Server Configuration Manager, przeglądając kartę SQL Server Services, a następnie klikając prawym przyciskiem myszy usługę SQL Server Database Engine i wybierając opcję Properties.

Z otwartego okna Właściwości serwera SQL przejdź na kartę Zawsze włączona wysoka dostępność i zaznacz pole wyboru obok Włącz grupę zawsze włączonej dostępności , biorąc pod uwagę, że zmiana ta wymaga ponownego uruchomienia usługi SQL Server, jak pokazano poniżej:

Problem z walidacją wymagań wstępnych bazy danych

We wcześniejszych krokach kreatora Nowa grupa dostępności zostaniesz poproszony o określenie baz danych, które będą uczestniczyć w grupie zawsze włączonej dostępności. Przed dodaniem bazy danych baza danych powinna przejść kontrolę poprawności wymagań wstępnych. W przeciwnym razie bazy danych nie można wybrać z list baz danych, jak pokazano w poniższym komunikacie o błędzie:

Aby dodać do grupy dostępności, ta baza danych musi być ustawiona na pełny model odzyskiwania. Ustaw właściwość bazy danych Model odzyskiwania na Pełne i wykonaj pełną lub różnicową kopię zapasową bazy danych w bazie danych. Będziesz wtedy musiał zaplanować tworzenie kopii zapasowych dziennika w bazie danych.

Przesłanie jest jasne. Baza danych powinna być skonfigurowana z modelem pełnego odzyskiwania, a pełna lub różnicowa kopia zapasowa powinna być wykonana na tej bazie danych.

Ponadto kreator ostrzega, aby zaplanować tworzenie kopii zapasowej dziennika transakcji dla tej bazy danych po zmianie modelu odzyskiwania na Pełny, aby automatycznie obciąć plik dziennika transakcji i zapobiec uruchomieniu tego pliku dziennika transakcji z wolnego miejsca.

Aby rozwiązać ten problem, zmień model odzyskiwania bazy danych z Prosty na Pełny, na karcie Opcje w oknie właściwości bazy danych, a następnie wykonaj pełną kopię zapasową z tej bazy danych, jak pokazano poniżej:

Odświeżając okno Wybierz bazy danych, stan bazy danych zmieni się na Spełnienie wymagań wstępnych, jak pokazano poniżej:

Problem z uprawnieniami do lokalizacji w sieci współdzielonej

Podczas próby skonfigurowania witryny Always on Availability Group krok sprawdzania poprawności kreatora nowej grupy dostępności nie powiódł się i pojawił się następujący komunikat o błędzie:

Serwer główny „SQL1” nie może zapisywać w „\\SQL1\AlwaysON\BackupLocDb_dbb55cb4-af89-4ed3-b189-1fcaad42358c.bak”. (Microsoft.SqlServer.Management.HadrModel)

Utworzenie kopii zapasowej nie powiodło się dla serwera „SQL1”. (Microsoft.SqlServer.SmoExtended)

Nie można otworzyć urządzenia kopii zapasowej „\\SQL1\AlwaysON\BackupLocDb_dbb55cb4-af89-4ed3-b189-1fcaad42358c.bak”. Błąd systemu operacyjnego 5 (odmowa dostępu).

BACKUP DATABASE kończy się nieprawidłowo. (Dostawca danych .Net SqlClient)

W metodzie początkowej synchronizacji pełnej kopii zapasowej bazy danych i dziennika folder udostępniony jest wymagany do tymczasowego przechowywania plików kopii zapasowej pełnej kopii zapasowej i dziennika transakcji w celu przywrócenia ich we wszystkich replikach pomocniczych. Jeśli replika główna nie jest w stanie zapisać w niej plików kopii zapasowej lub repliki pomocnicze nie mogą odczytać z niej plików kopii zapasowej, proces sprawdzania poprawności nowej grupy dostępności zakończy się niepowodzeniem, jak poniżej:

Aby rozwiązać ten problem, musimy przyznać kontu SQL Server Service replikom podstawowym i pomocniczym uprawnienia do odczytu i zapisu w folderze współdzielonym pokazanym w komunikacie o błędzie, a następnie ponownie uruchomić proces sprawdzania poprawności, aby upewnić się, że wszystkie testy się powiodły , jak pokazano poniżej:

Problem z klastrem Windows Failover

Załóżmy, że sprawdzasz stan istniejącej witryny grupy Always on Availability Group i zobacz, że:

• Rola podstawowa została przeniesiona z instancji SQL1 do SQL2.
• W SQL2 bazy danych są w stanie zsynchronizowanym.
• W SQL1 bazy danych nie są synchronizowane.
• SQL1 jest w stanie rozwiązywania.

Jak widać wyraźnie w Eksploratorze obiektów SSMS poniżej:

Sprawdzając dzienniki błędów SQL Server w problematycznym węźle, możemy zauważyć, że replika grupy dostępności przechodzi w tryb offline, a grupa dostępności przestała działać z powodu problemu w klastrze Windows Server Failover, jak pokazano w poniższych błędach:

• Zawsze włączone grupy dostępności:Lokalny węzeł Windows Server Failover Clustering nie jest już w trybie online . To jest tylko wiadomość informacyjna. Nie jest wymagane żadne działanie użytkownika.
• Zawsze włączone:Menedżer replik dostępności przechodzi w tryb offline, ponieważ lokalny węzeł Windows Server Failover Clustering (WSFC) utracił kworum. To jest tylko wiadomość informacyjna. Nie jest wymagane żadne działanie użytkownika.
• Zawsze włączone:Lokalna replika grupy dostępności „DemoGroup” jest zatrzymywana. To jest tylko wiadomość informacyjna. Nie jest wymagane żadne działanie użytkownika.

To samo można wykryć w Podglądzie zdarzeń systemu Windows Server, który pokazuje stopniowo, jak replika zmienia swój stan na stan Rozwiązywania, jak poniżej:

• Zawsze włączone:lokalna replika grupy dostępności „DemoGroup” przygotowuje się do przejścia do roli rozstrzygania . To jest tylko wiadomość informacyjna. Nie jest wymagane żadne działanie użytkownika.
• Grupa dostępności „DemoGroup” jest proszona o przerwanie odnawiania dzierżawy, ponieważ grupa dostępności przechodzi w tryb offline . To jest tylko wiadomość informacyjna. Nie jest wymagane żadne działanie użytkownika.
• Stan lokalnej repliki dostępności w grupie dostępności „DemoGroup” zmienił się z „PRIMARY_NORMAL” na „RESOLVING_NORMAL”. Stan zmienił się, ponieważ grupa dostępności przechodzi w tryb offline. Replika przechodzi w tryb offline, ponieważ skojarzona grupa dostępności została usunięta lub użytkownik przełączył skojarzoną grupę dostępności w tryb offline w konsoli zarządzania Windows Server Failover Clustering (WSFC) lub grupa dostępności przechodzi w tryb failover do innego wystąpienia programu SQL Server. Aby uzyskać więcej informacji, zobacz dziennik błędów programu SQL Server lub dziennik klastra. Jeśli jest to grupa dostępności Windows Server Failover Clustering (WSFC), możesz również zobaczyć konsolę zarządzania WSFC.

Aby sprawdzić stan witryny klastra Windows, użyjemy Menedżera klastra pracy awaryjnej, aby zobaczyć, która część klastra Windows nie działa.

Ale Menedżer klastra pracy awaryjnej pokazuje, że cały klaster nie działa, jak pokazano poniżej:

Pierwszą rzeczą do sprawdzenia tutaj po stronie Windows Failover Cluster jest Cluster Service, którą można sprawdzić w konsoli Windows Services, jak poniżej:

Z konsoli usług jasno wynika, że ​​usługa klastrowania nie jest uruchomiona. Aby rozwiązać ten problem, uruchom usługę z tej konsoli, a następnie odśwież konsolę Failover Cluster Manager, aby upewnić się, że witryna Windows Cluster jest uruchomiona i działa, jak pokazano poniżej:

Sprawdzając ponownie grupę Always on Availability Group, zobaczysz, że bazy danych są ponownie zsynchronizowane, a witryna Always on Availability Group jest ponownie w stanie kondycji, jak pokazano poniżej:

Plik dziennika transakcji jest pełny po stronie podstawowej

Załóżmy, że otrzymujesz poniższy komunikat o błędzie podczas próby wykonania nowego zapytania w jednej z baz danych Always on Availability Group:

Sprawdzając, co blokuje plik dzienników transakcji i zapobiega jego obcięciu, zobaczysz, że plik dziennika transakcji tej bazy danych oczekuje na obcięcie operacji tworzenia kopii zapasowej dziennika, jak pokazano poniżej:

Wykonanie kopii zapasowej dziennika transakcji dla tej bazy danych w przypadku zapomnienia o zaplanowaniu zadania kopii zapasowej dziennika transakcji w następujący sposób:

I ponownie sprawdź, co blokuje dziennik transakcji tej bazy danych, pokazuje w moim scenariuszu, że czeka na Availability_Replica. Oznacza to, że dzienniki oczekują na zapisanie w replice pomocniczej, ale nie są w stanie wysłać tych dzienników transakcji do replik pomocniczych z powodu problemu w witrynie Always on Availability Group, jak poniżej:

Najlepszą lokalizacją do sprawdzania i rozwiązywania problemów z witryną Always on Availability Group jest Always on Dashboard, którą można otworzyć, klikając prawym przyciskiem myszy nazwę grupy dostępności i wybierając opcję Show Dashboard.

Z pulpitu nawigacyjnego widać, że dodatkowa replika SQL2 nie jest zsynchronizowana z repliką podstawową z powodu problemu z łącznością, jak pokazano poniżej:

Sprawdzenie repliki pomocniczej i upewnienie się, że usługa SQL Server jest uruchomiona i uruchomiona po stronie wtórnej, w następujący sposób:

Po ponownym odświeżeniu pulpitu nawigacyjnego grupy dostępności zobaczysz, że witryna Always on Availability Group jest znowu w dobrej kondycji. Sprawdzając, czy plik dzienników transakcji jest zablokowany przez jakąkolwiek operację, zobaczymy, że oczekuje na OLDEST_PAGE, co oznacza, że ​​najstarsza strona bazy danych jest starsza niż LSN punktu kontrolnego. Ten problem można łatwo rozwiązać, wykonując kolejną kopię zapasową dziennika transakcji, a plik dziennika transakcji nie zostanie przez nic zablokowany, jak pokazano poniżej:

Zawsze włączona błędna konfiguracja przełączania awaryjnego grupy dostępności

Załóżmy, że replika podstawowa przechodzi w tryb offline z powodu nieplanowanego problemu. Zgodnie z oczekiwaniami system nie zostanie naruszony, ponieważ zostanie wykonana automatyczna operacja przełączania awaryjnego, a replika pomocnicza będzie działać jako nowa replika główna.

Ale w naszym przypadku ten szczęśliwy scenariusz nie jest prawidłowy, w którym replika pomocnicza zmieniła się w stan rozwiązywania, a system nie działa!

Sprawdzając dziennik błędów repliki pomocniczej i sprawdzając, dlaczego nie działa ona jako nowa podstawowa zgodnie z oczekiwaniami, zobaczysz, że nie działa ona z powodu problemu z synchronizacją ról, jak pokazano poniżej:

Baza danych grupy dostępności „AdventureWorks2017” zmienia role z „DODATKOWE” na „ROZWIĄZANE”, ponieważ sesja dublowania lub grupa dostępności uległa awarii z powodu synchronizacji ról. To jest tylko wiadomość informacyjna. Nie jest wymagane żadne działanie użytkownika.

Oznacza to, że występuje problem z trybem synchronizacji używanym w tej grupie dostępności. Używany tryb synchronizacji można sprawdzić na stronie właściwości Zawsze włączona grupa dostępności.

Z poniższej strony właściwości jasno wynika, że ​​tryb przełączania awaryjnego w tej grupie dostępności jest skonfigurowany do wykonywania tylko ręcznie. W takim przypadku musisz ręcznie wykonać operację przełączania awaryjnego przed ponownym uruchomieniem lub zamknięciem serwera:

Można to łatwo naprawić, zmieniając tryb awaryjny na automatyczny, w którym w przypadku nieplanowanego wyłączenia lub ponownego uruchomienia zostanie wykonana automatyczna operacja przełączania awaryjnego:

Ten sam problem może wystąpić, gdy kworum Windows Failover Cluster jest skonfigurowane z większością węzłów dla parzystej liczby replik, gdzie jakakolwiek awaria jednego z serwerów spowoduje wyłączenie witryny Windows Failover Cluster. Aby uzyskać więcej informacji, sprawdź Tryby kworum klastra trybu failover systemu Windows w zawsze włączonych grupach dostępności programu SQL Server:

Przełączanie awaryjne z utratą danych

Załóżmy, że próbujesz wykonać ręczne przełączenie awaryjne między repliką podstawową a jedną z replik drugorzędnych, ale w oknie Wybierz nową replikę podstawową widzisz komunikat ostrzegawczy, że operacja przełączania awaryjnego może zakończyć się utratą danych jako podstawowej i wybranej Replika pomocnicza nie jest zsynchronizowana, jak pokazano poniżej:

Aby zidentyfikować przyczynę tego problemu, przejrzymy zdarzenia Always on Health za pomocą pulpitu Always on Availability Group, który pokazuje, że replika podstawowa nie jest w stanie otworzyć połączenia z repliką pomocniczą, pokazany poniżej:

Po naprawieniu problemu z łącznością między głównym i dodatkowym, odśwież listę replik, a zobaczysz, że problem z utratą danych został naprawiony, jak pokazano poniżej. Aby uzyskać więcej informacji na temat rozwiązywania problemów z łącznością, sprawdź Rozwiązywanie problemów z połączeniem z silnikiem bazy danych SQL Server.

Monitorowanie opóźnień grupy dostępności zawsze włączone

Pulpit nawigacyjny grupy dostępności można zmodyfikować, aby zawierał dodatkowe kolumny, które dostarczają informacji o opóźnieniach synchronizacji między replikami podstawowymi i pomocniczymi, w tym wartości Commit LSN, Sent LSN i harden LSN, bez pokazywania, dlaczego występuje opóźnienie, jak pokazano poniżej:

Aby uzyskać więcej informacji na temat pomiaru opóźnienia, sprawdź opóźnienie synchronizacji grupy dostępności pomiaru.

Począwszy od SSMS 17.4, pulpit nawigacyjny Always on Availability Group został rozszerzony o dwie nowe opcje, które są używane do obliczania, analizy i raportowania informacji o opóźnieniach, co pomaga w identyfikowaniu wąskich gardeł w przepływie dzienników transakcji między replikami podstawowymi i pomocniczymi oraz zawężania przyczynę tego opóźnienia.
Aby uzyskać więcej informacji o nowych funkcjach i raportach, przejdź do sekcji Używaj pulpitu nawigacyjnego Always on Availability Group.

Aby uruchomić przy użyciu tej nowej opcji, kliknij Zbierz dane o opóźnieniu opcja z pulpitu nawigacyjnego Always on Availability Group, która utworzy nowe zadanie SQL Agent w replikach podstawowych i pomocniczych w celu zebrania danych o opóźnieniach, jak pokazano poniżej:

Po zakończeniu wykonywania utworzonego zadania na wszystkich replikach grupy dostępności będzie można wyświetlić statystyki opóźnień z raportów o opóźnieniu, klikając prawym przyciskiem myszy nazwę grupy dostępności i wybierając raport o opóźnieniu podstawowej repliki lub wtórny raport o opóźnieniu repliki, na podstawie rolę repliki w grupie dostępności.

Po dostarczeniu informacji o replikach grupy dostępności, raport o opóźnieniu pokaże graficzny widok czasu zatwierdzenia dziennika transakcji w replice podstawowej i zdalnego czasu umocnienia dla replik pomocniczych, zagregowane jako wartości średnie. Ponadto raport zawiera wartości statystyczne dla dzienników transakcji wysyłania, odbierania, zatwierdzania, kompresowania, dekompresji i inne wartości liczbowe w oparciu o rolę repliki w grupie dostępności.

Aby uzyskać więcej informacji na temat raportu o opóźnieniu, sprawdź Nowość w SSMS – Raporty o opóźnieniu zawsze włączonej grupy dostępności.

Poniższy raport jest przykładem raportów o opóźnieniach generowanych z repliki pomocniczej, pokazujących normalne operacje transportu dzienników:

Ponadto Opóźnienie blokowania dziennika raport pokazuje ilość czasu w ms, przez który dziennik transakcji w replice podstawowej czeka na zatwierdzenie transakcji przez repliki drugorzędne. Po włączeniu go z pulpitu nawigacyjnego grupy dostępności możesz przeglądać go z poziomu programu SSMS, podobnie jak w poprzednich raportach o opóźnieniach. Weź pod uwagę, że duży czas opóźnienia wskazuje, że replika główna długo czeka na zatwierdzenie wysłanych transakcji przez repliki drugorzędne, jak pokazano poniżej: