Uaktualnianie replik grup dostępności

Dotyczy:programu SQL Server

Podczas uaktualniania wystąpienia programu SQL Server, które hostuje grupę dostępności Always On do nowej wersji programu SQL Server, do nowej aktualizacji dodatku Service Pack programu SQL Server lub aktualizacji zbiorczej, albo podczas instalowania nowego dodatku Service Pack lub aktualizacji zbiorczej systemu Windows, można zmniejszyć przestój repliki podstawowej tylko do pojedynczego ręcznego przełączenia w tryb failover przez przeprowadzenie uaktualnienia rotacyjnego (lub dwóch ręcznych przełączeń w tryb failover w przypadku powrotu do pierwotnej repliki podstawowej).

W trakcie procesu uaktualniania replika pomocnicza nie będzie dostępna do pracy w trybie failover ani do operacji tylko do odczytu, a po uaktualnieniu replika pomocnicza może potrzebować trochę czasu, aby nadrobić zaległości względem węzła repliki podstawowej, w zależności od ilości działań na tym węźle (należy spodziewać się dużego ruchu sieciowego).

Należy również pamiętać, że po początkowym przełączeniu do repliki pomocniczej z nowszą wersją programu SQL Server, bazy danych w tej grupie dostępności zostaną poddane procesowi uaktualnienia, aby przeprowadzić je do najnowszej wersji. W tym czasie nie będzie żadnych replik do odczytu dla żadnej z tych baz danych. Przestój po początkowym przejściu w tryb failover będzie zależeć od liczby baz danych w AG. Jeśli planujesz powrót po awarii do oryginalnego elementu podstawowego, ten krok nie będzie powtarzany po powrocie po awarii.

Notatka

Ten artykuł ogranicza dyskusję na temat uaktualniania samego programu SQL Server. Nie obejmuje uaktualniania systemu operacyjnego zawierającego klaster trybu failover systemu Windows Server (WSFC). Systemu operacyjnego Windows, który obsługuje klaster trybu failover, nie można zaktualizować do nowszej wersji w systemach operacyjnych wcześniejszych niż Windows Server 2012 R2. Aby uaktualnić węzeł klastra uruchomiony w systemie Windows Server 2012 R2, zobacz Uaktualnianie stopniowe systemu operacyjnego klastra.

Warunki wstępne

Przed rozpoczęciem zapoznaj się z następującymi ważnymi informacjami:

• Obsługiwane uaktualnienia wersji i edycji: sprawdź, czy możesz uaktualnić program SQL Server do najnowszej wersji systemu operacyjnego Windows i wersji programu SQL Server. Na przykład w przypadku uaktualnienia bezpośrednio z wystąpienia SQL Server 2005 poziom zgodności bazy danych zostanie zaktualizowany.

• Wybierz metodę aktualizacji aparatu bazy danych: Aby zaktualizować w odpowiedniej kolejności, wybierz właściwą metodę aktualizacji i kroki na podstawie przeglądu obsługiwanych aktualizacji wersji i edycji oraz w oparciu o inne komponenty zainstalowane w twoim środowisku.

• Zaplanuj i przetestuj plan uaktualnienia silnika bazy danych: Przejrzyj informacje o wersji i znane problemy z uaktualnieniem, listę kontrolną przed uaktualnieniem oraz opracuj i przetestuj plan uaktualnienia.

• wymagania sprzętowe i programowe dotyczące instalowania programu SQL Server: Sprawdź wymagania oprogramowania do instalowania programu SQL Server. Jeśli wymagane jest dodatkowe oprogramowanie, zainstaluj je w każdym węźle przed rozpoczęciem procesu uaktualniania, aby zminimalizować wszelkie przestoje.

• Sprawdź, czy przechwytywanie zmian danych lub replikacja jest stosowana dla dowolnych baz danych w grupie dostępności AG: jeżeli jakiekolwiek bazy danych w AG są włączone do przechwytywania danych zmian (CDC), wykonaj te instrukcje .

Notatka

Mieszanie wersji wystąpień programu SQL Server w tej samej grupie dostępności nie jest obsługiwane poza uaktualnieniem stopniowym i nie powinno trwać w tym stanie przez dłuższy czas, ponieważ uaktualnienie powinno nastąpić szybko. Drugą opcją uaktualniania programu SQL Server 2016 (13.x) i nowszych wersji jest użycie rozproszonej grupy dostępności.

Notatka

Korzystanie z funkcji Cluster-Aware Aktualizowanie (CAU) systemu Windows do aktualizowania zawsze włączonych grup dostępności nie jest obsługiwane.

Podstawy uaktualniania stopniowego dla grup dostępności

Podczas przeprowadzania uaktualnień lub aktualizacji serwera należy przestrzegać poniższych wytycznych, aby zminimalizować przestoje i utratę danych dla grup dostępności:

• Przed rozpoczęciem uaktualniania stopniowego:

  • Przećwicz ręczne przechodzenie w tryb failover w co najmniej jednym z wystąpień repliki zatwierdzania synchronicznego

  • Chroń swoje dane, wykonując pełną kopię zapasową każdej bazy danych dostępności.

  • Uruchom DBCC CHECKDB na każdej bazie danych dostępności

• Zawsze najpierw zaktualizuj zdalne wystąpienia replik pomocniczych, następnie lokalne wystąpienia replik pomocniczych, a na końcu wystąpienie repliki podstawowej.

• Kopie zapasowe nie mogą występować w bazie danych, która jest w trakcie uaktualniania. Przed uaktualnieniem replik pomocniczych należy skonfigurować preferencję automatycznego tworzenia kopii zapasowej tak, aby uruchamiała kopie zapasowe tylko na repliki podstawowej. Podczas uaktualniania wersji żadne repliki nie są czytelne ani dostępne dla kopii zapasowych. Podczas uaktualniania wersji innej niż wersja można skonfigurować automatyczne kopie zapasowe do uruchamiania na replikach pomocniczych przed uaktualnieniem repliki podstawowej.

• Podczas uaktualniania wersji, czytelne repliki pomocnicze nie są dostępne po uaktualnieniu repliki pomocniczej i przed przełączeniem repliki podstawowej do zaktualizowanej repliki pomocniczej lub uaktualnieniem repliki podstawowej.

• Aby zapobiec niezamierzonemu przełączaniu grupy dostępności podczas procesu uaktualniania, przed rozpoczęciem usuń przełączenie dostępności ze wszystkich synchronicznych replik zatwierdzających.

• Nie uaktualnij wystąpienia repliki podstawowej przed przełączeniem grupy dostępności w tryb failover do uaktualnionego wystąpienia z repliką pomocniczą. W przeciwnym razie aplikacje klienckie mogą doświadczyć dłuższego przestoju podczas uaktualniania na instancji podstawowej repliki.

• Zawsze przełącz grupę dostępności w tryb failover do wystąpienia repliki pomocniczej zatwierdzania synchronicznego. W przypadku przełączenia do pomocniczej repliki z zatwierdzeniem asynchronicznym, bazy danych są narażone na utratę danych, a przenoszenie danych zostaje automatycznie wstrzymane do momentu ręcznego wznowienia.

• Nie aktualizuj głównego wystąpienia repliki, zanim zaktualizujesz jakiekolwiek inne wystąpienie repliki pomocniczej. Uaktualniona replika podstawowa nie może już dostarczać dzienników do żadnej repliki pomocniczej, której wystąpienie SQL Server nie zostało jeszcze uaktualnione do tej samej wersji. W przypadku wstrzymania przenoszenia danych do repliki pomocniczej nie można przeprowadzić automatycznego przejścia w tryb failover dla tej repliki, a bazy danych dostępności są narażone na utratę danych. Dotyczy to również procesu stopniowego uaktualniania, w którym ręcznie przełączysz z trybu failover ze starego podstawowego do nowego podstawowego. W związku z tym, po uaktualnieniu starego serwera głównego, może być konieczne wznowienie synchronizacji.

• Przed przełączeniem grupy dostępności w tryb failover sprawdź, czy stan synchronizacji docelowego trybu failover jest SYNCHRONIZED.

  Ostrzeżenie

  Zainstalowanie nowego wystąpienia lub nowej wersji programu SQL Server na serwerze, na którym zainstalowano starszą wersję programu SQL Server, może przypadkowo spowodować awarię dowolnej grupy dostępności hostowanej przez starszą wersję programu SQL Server. Jest to spowodowane tym, że podczas instalacji wystąpienia lub wersji programu SQL Server moduł wysokiej dostępności programu SQL Server (RHS.EXE) zostanie uaktualniony. Spowoduje to tymczasową przerwę w działaniu istniejących grup dostępności pełniących rolę podstawową na serwerze. W związku z tym zdecydowanie zaleca się wykonanie jednej z następujących czynności podczas instalowania nowszej wersji programu SQL Server w systemie obsługującym już starszą wersję programu SQL Server z grupą dostępności:

  • Zainstaluj nową wersję programu SQL Server podczas okresu serwisowego.

  • Przełącz grupę dostępności do repliki pomocniczej, aby nie była ona podstawowa podczas instalacji nowej instancji SQL Server.

Proces uaktualniania stopniowego

W praktyce dokładny proces zależy od czynników, takich jak topologia rozmieszczenia grup dostępności (AG) i tryb zatwierdzania każdej repliki. Jednak w najprostszym scenariuszu uaktualnienie stopniowe jest procesem wieloetapowym, który w najprostszej formie obejmuje następujące kroki:

1. Usuwanie automatycznego trybu failover we wszystkich replikach zatwierdzeń synchronicznych
2. Uaktualnij wszystkie wystąpienia repliki pomocniczej zatwierdzania asynchronicznego.
3. Uaktualnij wszystkie zdalne instancje repliki wtórnej zatwierdzania synchronicznego.
4. Uaktualnij wszystkie lokalne instancje drugorzędnych replik z zatwierdzeniem synchronicznym.
5. Ręcznie przełącz AG na (nowo uaktualnioną) lokalną replikę pomocniczą z synchronicznym zatwierdzaniem.
6. Uaktualnij lub zaktualizuj lokalne wystąpienie repliki, które poprzednio hostowało replikę podstawową.
7. Skonfiguruj partnerów automatycznego przełączenia awaryjnego zgodnie z potrzebami.

W razie potrzeby możesz wykonać ręczny failover, aby przywrócić grupę dostępności (AG) do jej oryginalnej konfiguracji.

Notatka

Uaktualnienie repliki zatwierdzenia synchronicznego i przełączenie jej w tryb offline nie spowoduje opóźnienia transakcji na serwerze podstawowym. Po rozłączeniu repliki wtórnej transakcje są zatwierdzane na serwerze podstawowym bez oczekiwania na utrwalenie dzienników na replice wtórnej.

Jeśli REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT jest ustawiona na 1 lub 2, replika podstawowa może być niedostępna dla operacji odczytu/zapisu, gdy odpowiednia liczba replik pomocniczych synchronizacji nie jest dostępna podczas procesu aktualizacji.

Notatka

Gdy wykonujesz uaktualnienie w miejscu repliki pomocniczej do nowszej wersji programu SQL Server, baza danych w grupie dostępności pozostaje w stanie Synchronizacja / W trakcie odzyskiwania lub Zsynchronizowane / W trakcie odzyskiwania dopóki nie zostanie ręcznie przełączona grupa dostępności, co kończy proces odzyskiwania i uaktualnia bazę danych. Uaktualniona replika podstawowa nie może już wysyłać dzienników do pomocniczej repliki o niższej wersji, co powoduje zatrzymanie przemieszczania danych, a automatyczne przejście w tryb failover dla tej repliki nie jest możliwe; bazy danych wysokiej dostępności są przez to narażone na utratę danych. Po uaktualnieniu starego głównego systemu może być konieczne wznowienie synchronizacji. Zaleca się uaktualnienie wszystkich replik pomocniczych przed przełączeniem w tryb failover do repliki przy użyciu nowej wersji. Dzięki temu można przejść w tryb failover po uaktualnieniu bazy danych do nowego formatu.

Grupa dostępności (AG) z jedną zdalną repliką pomocniczą

Jeśli grupa dostępności została wdrożona tylko na potrzeby odzyskiwania po awarii, może być konieczne przełączenie grupy dostępności w tryb failover do repliki pomocniczej zatwierdzanej asynchronicznie. Taka konfiguracja jest pokazana na poniższym rysunku:

W tej sytuacji należy przełączyć AG na replikę pomocniczą w trybie asynchronicznej komitacji podczas uaktualnienia kroczącego. Aby zapobiec utracie danych, zmień tryb zatwierdzania na zatwierdzenie synchroniczne i poczekaj na zsynchronizowanie repliki pomocniczej przed przełączenie grupy dostępności w tryb failover. W związku z tym proces uaktualniania stopniowego może wyglądać następująco:

1. Zaktualizuj replikę pomocniczą w zdalnej lokalizacji
2. Zmienianie trybu zatwierdzania na zatwierdzenie synchroniczne
3. Zaczekaj, aż stan synchronizacji zostanie SYNCHRONIZED
4. Przełącz grupę dostępności na replikę pomocniczą w zdalnej lokalizacji
5. Ulepszanie lub aktualizowanie wystąpienia lokalnej repliki (lokalizacja główna)
6. Przełącz grupę dostępności do lokalizacji pierwotnej
7. Zmienianie trybu zatwierdzania na zatwierdzenie asynchroniczne

Ponieważ tryb zatwierdzania synchronicznego nie jest zalecanym ustawieniem synchronizacji danych z lokacją zdalną, aplikacje klienckie mogą zauważyć natychmiastowy wzrost opóźnienia bazy danych po zmianie ustawienia. Ponadto wykonanie przełączenia awaryjnego powoduje odrzucenie wszystkich niepotwierdzonych komunikatów dziennika. Liczba odrzuconych komunikatów dziennika może być znacząca ze względu na duże opóźnienie sieci między dwiema lokacjami, co powoduje, że klienci doświadczają dużej liczby błędów transakcyjnych. Możesz zminimalizować wpływ na aplikacje klienckie, wykonując następujące czynności:

• Ostrożnie wybierz okno konserwacji podczas niskiego ruchu klientów

• Podczas uaktualniania lub aktualizowania programu SQL Server w witrynie głównej, zmień tryb dostępności z powrotem na komit asynchroniczny, a następnie przywróć komit synchroniczny, kiedy będziesz gotowy, aby ponownie przełączyć się do witryny głównej.

Grupa dostępności z węzłami wystąpienia klastra trybu failover

Jeśli dostępna grupa (AG) zawiera węzły wystąpienia klastra trybu przełączania awaryjnego (FCI), należy najpierw uaktualnić węzły nieaktywne, a dopiero potem węzły aktywne. Na poniższej ilustracji przedstawiono typowy scenariusz grupy dostępności z wystąpieniem klastra trybu failover dla lokalnej wysokiej dostępności i asynchronicznego zatwierdzenia między wystąpieniami klastra trybu failover na potrzeby zdalnego odzyskiwania po awarii i sekwencji uaktualniania.

1. Aktualizacja lub modernizacja REMOTE2
2. Przełącz FCI2 do REMOTE2
3. Uaktualnienie lub aktualizacja REMOTE1
4. Aktualizacja lub uaktualnienie PRIMARY2
5. Przełącz FCI1 do PRIMARY2
6. Ulepszanie lub aktualizowanie PRIMARY1

Uaktualnianie lub aktualizowanie wystąpień programu SQL Server z wieloma grupami dostępności

Jeśli korzystasz z wielu grup AG z replikami podstawowymi w oddzielnych węzłach serwera (konfiguracja aktywna/aktywna), ścieżka uaktualniania obejmuje więcej kroków trybu failover w celu zachowania wysokiej dostępności w procesie. Załóżmy, że korzystasz z trzech grup AG w trzech węzłach serwera ze wszystkimi replikami w trybie zatwierdzania synchronicznego, jak pokazano w poniższej tabeli:

AG	Węzeł1	Węzeł 2	Node3
AG1	Podstawowy
AG2		Podstawowy
AG3			Podstawowy

W twojej sytuacji może być odpowiednie przeprowadzenie aktualizacji stopniowej z równoważeniem obciążenia w następującej kolejności:

1. Przełącz AG2 na Node3 (aby zwolnić Node2)
2. Aktualizacja lub unowocześnienie Node2
3. Przełącz AG1 do Node2 (aby zwolnić Node1)
4. Aktualizowanie lub modernizacja Node1
5. Przeprowadź przełączanie awaryjne zarówno AG2, jak i AG3 do Node1 (aby zwolnić Node3)
6. Uaktualnienie lub aktualizacja Node3
7. Przełącz grupę dostępności AG3 do Node3 w tryb awaryjny.

Ta sekwencja uaktualniania ma średni przestój wynoszący mniej niż dwa przełączenia awaryjne na grupę dostępności. Wynikowa konfiguracja jest pokazana w poniższej tabeli.

AG	Węzeł1	Węzeł 2	Node3
AG1		Podstawowy
AG2	Podstawowy
AG3			Podstawowy

W zależności od konkretnej implementacji ścieżka uaktualniania może się różnić, a przestoje w środowisku aplikacji klienckich również mogą się różnić.

Notatka

W wielu przypadkach, po ukończeniu stopniowego uaktualnienia, nastąpi przywrócenie oryginalnej repliki podstawowej.

Stopniowe uaktualnianie rozproszonej grupy dostępności

Aby przeprowadzić uaktualnienie stopniowe rozproszonej grupy dostępności, najpierw uaktualnij wszystkie repliki pomocnicze. Następnie przełącz usługę przesyłania dalej w tryb failover i uaktualnij ostatnie pozostałe wystąpienie drugiej grupy dostępności. Po uaktualnieniu wszystkich innych replik przeprowadź przełączenie awaryjne globalnego serwera głównego i uaktualnij ostatnie pozostałe wystąpienie pierwszej grupy dostępności. Poniżej przedstawiono szczegółowy diagram z krokami.

W zależności od konkretnej implementacji ścieżka uaktualniania może się różnić, a przestoje w środowisku aplikacji klienckich również mogą się różnić.

Notatka

W wielu przypadkach, po zakończeniu aktualizacji stopniowej, nastąpi cofnięcie do stanu poprzedniego do oryginalnych replik głównych.

Ogólne kroki aktualizacji rozproszonej grupy dostępności

1. Wykonaj kopię zapasową wszystkich baz danych, w tym systemowych baz danych i osób uczestniczących w grupie dostępności.
2. Uaktualnij i uruchom ponownie wszystkie repliki pomocnicze drugiej grupy dostępności (podrzędnej).
3. Uaktualnij i uruchom ponownie wszystkie repliki pomocnicze pierwszej grupy dostępności (nadrzędnej).
4. Przełącz serwer przekazywania na uaktualnioną replikę pomocniczą grupy dostępności w trybie awaryjnym.
5. Poczekaj na synchronizację danych. Bazy danych powinny być wyświetlane jako zsynchronizowane na wszystkich replikach zatwierdzeń synchronicznych, a globalna instancja nadrzędna powinna być zsynchronizowana z przekaźnikiem.
6. Zaktualizuj i uruchom ponownie ostatnią pozostałą instancję pomocniczej grupy dostępności.
7. Przełącz globalny serwer podstawowy w tryb failover do uaktualnionej jednostki pomocniczej pierwszej dostępności grupy.
8. Uaktualnij ostatnie pozostałe wystąpienie podstawowej grupy dostępności.
9. Uruchom ponownie nowo uaktualniony serwer.
10. (opcjonalnie) Przełącz obie grupy dostępności z powrotem na ich oryginalne repliki podstawowe.

Ważny

Zweryfikuj synchronizację między każdym krokiem. Przed przejściem do następnego kroku upewnij się, że repliki zatwierdzenia synchronicznego są synchronizowane w grupie dostępności i że globalna podstawowa grupa dostępności jest zsynchronizowana z usługą przesyłania dalej w rozproszonej grupie dostępności.

Zalecenie: Za każdym razem, gdy weryfikujesz synchronizację, odśwież zarówno węzeł bazy danych, jak i rozproszony węzeł AG w programie SQL Server Management Studio. Po zsynchronizowaniu wszystkich elementów zapisz zrzut ekranu przedstawiający stany każdej repliki. Pomoże to śledzić, na jakim kroku pracujesz, podać dowody na to, że wszystko działa prawidłowo przed następnym krokiem i pomoże Ci rozwiązać problem, jeśli coś pójdzie nie tak.

Przykład diagramu dotyczącego stopniowego uaktualniania rozproszonej grupy dostępności

Grupa dostępności	Replika podstawowa	Replika pomocnicza
AG1	NODE1\SQLAG	NODE2\SQLAG
AG2	NODE3\SQLAG	NODE4\SQLAG
DistributedAG	AG1 (global)	AG2 (usługa przesyłania dalej)

Kroki uaktualniania wystąpień na tym diagramie:

1. Wykonaj kopię zapasową wszystkich baz danych, w tym systemowych baz danych i osób uczestniczących w grupie dostępności.
2. Zaktualizuj NODE4\SQLAG (druga grupa dostępności AG2) i uruchom ponownie serwer.
3. Zaktualizuj NODE2\SQLAG (drugorzędny AG1) i uruchom ponownie serwer.
4. Przełącz awaryjnie AG2 z NODE3\SQLAG do NODE4\SQLAG.
5. Uaktualnij NODE3\SQLAG i uruchom ponownie serwer.
6. Przełącz AG1 w tryb failover z NODE1\SQLAG do NODE2\SQLAG.
7. Uaktualnij NODE1\SQLAG i uruchom ponownie serwer.
8. (opcjonalnie) Powrót po awarii do oryginalnych replik podstawowych.
   1. Niezawodnie przełącz AG2 z NODE4\SQLAG z powrotem do NODE3\SQLAG.
   2. Przełącz w tryb awaryjny AG1 z NODE2\SQLAG z powrotem do NODE1\SQLAG.

Jeśli w każdej grupie dostępności istniałaby trzecia replika, byłaby ona uaktualniona przed NODE3\SQLAG i NODE1\SQLAG.

Ważny

Zweryfikuj synchronizację między każdym krokiem. Przed przejściem do następnego kroku upewnij się, że repliki zatwierdzenia synchronicznego są zsynchronizowane w grupie dostępności i że globalne centrum główne jest zsynchronizowane z przekaźnikiem w rozproszonej grupie dostępności.

Zalecenie: Za każdym razem, gdy weryfikujesz synchronizację, odśwież zarówno węzeł bazy danych, jak i węzeł rozproszonej grupy dostępności w programie SQL Server Management Studio. Jeśli wszystko jest zsynchronizowane, zrób zrzut ekranu i zapisz go. Pomoże to śledzić, na jakim kroku pracujesz, podać dowody na to, że wszystko działa prawidłowo przed następnym krokiem i pomoże Ci rozwiązać problem, jeśli coś pójdzie nie tak.

Specjalne kroki przechwytywania lub replikacji zmian danych

W zależności od stosowanej aktualizacji mogą być wymagane dodatkowe kroki w przypadku baz danych replik w Grupach Dostępności, które są przeznaczone do przechwytywania danych o zmianach lub replikacji. Zapoznaj się z informacjami o wersji aktualizacji, aby ustalić, czy są wymagane następujące kroki:

1. Uaktualnij każdą replikę wtórną.

2. Po uaktualnieniu wszystkich replik drugorzędnych, przeprowadź operację failover na grupie dostępności do uaktualnionego wystąpienia.

3. Uruchom następujące Transact-SQL w wystąpieniu hostującym podstawową replikę.

   EXECUTE [master].[sys].[sp_vupgrade_replication];
   

   Notatka

   Uruchomienie tego polecenia może potrwać kilka minut. Pomiń ten krok, jeśli korzystasz z programu SQL Server 2019 CU1 lub nowszego. Aby dowiedzieć się więcej, zapoznaj się z KB4530283

4. Uaktualnij wystąpienie, które pierwotnie było repliką podstawową.

Aby uzyskać informacje w tle, zobacz . Funkcja CDC może ulec awarii po uaktualnieniu do najnowszej aktualizacji CU.

Zobacz też

• Uaktualnianie SQL Servera za pomocą kreatora instalacji (instalatora)
• zainstaluj program SQL Server z poziomu wiersza polecenia