Rozproszone grupy dostępności

Dotyczy:SQL Server

Rozproszona grupa dostępności to specjalny typ grupy dostępności, która obejmuje dwie oddzielne grupy dostępności. Rozproszone grupy dostępności są dostępne od programu SQL Server 2016.

W tym artykule opisano funkcję rozproszonej grupy dostępności. Aby skonfigurować rozproszoną grupę dostępności, zobacz Konfigurowanie rozproszonych grup dostępności.

Przegląd

Rozproszona grupa dostępności jest specjalnym typem grupy dostępności obejmującej dwie oddzielne grupy dostępności. Grupy dostępności, które uczestniczą w rozproszonej grupie dostępności, nie muszą znajdować się w tej samej lokalizacji. Mogą być fizyczne, wirtualne, lokalne, w chmurze publicznej lub w dowolnym miejscu obsługującym wdrożenie grupy dostępności. Obejmuje to międzydomenowe, a nawet międzyplatformowe — na przykład między grupą dostępności hostowaną w systemie Linux i jedną hostowaną w systemie Windows. Tak długo, jak dwie grupy dostępności mogą się komunikować, można skonfigurować rozproszoną grupę dostępności z nimi.

Tradycyjna grupa dostępności ma zasoby skonfigurowane w klastrze trybu failover systemu Windows Server (WSFC) lub w systemie Linux, Pacemaker. Rozproszona grupa dostępności nie konfiguruje żadnych elementów w klastrze bazowym (WSFC lub Pacemaker). Wszystkie informacje o nim są przechowywane w programie SQL Server. Aby dowiedzieć się, jak wyświetlić informacje dla rozproszonej grupy dostępności, zobacz Wyświetlanie informacji o rozproszonej grupie dostępności.

Rozproszona grupa dostępności wymaga odbiornika bazowych grup dostępności. Zamiast podawać podstawową nazwę serwera dla wystąpienia autonomicznego (lub, w przypadku wystąpienia klastra trybu failover programu SQL Server [FCI], wartość skojarzoną z zasobem nazwy sieciowej), jak w przypadku tradycyjnej grupy dostępności, należy zamiast tego określić skonfigurowany listener dla rozproszonej grupy dostępności, używając parametru ENDPOINT_URL podczas jej tworzenia. Mimo że każda podstawowa grupa dostępności rozproszonej grupy dostępności ma odbiornik, rozproszona grupa dostępności nie ma odbiornika.

Na poniższej ilustracji przedstawiono ogólny widok rozproszonej grupy dostępności obejmującej dwie grupy dostępności (AG 1 i AG 2), z których każda została skonfigurowana w ramach własnej usługi WSFC. Rozproszona grupa dostępności ma łącznie cztery repliki, po dwie w każdej grupie dostępności. Każda grupa dostępności może obsługiwać maksymalną liczbę replik, więc rozproszona grupa dostępności może mieć maksymalnie 18 replik.

Przenoszenie danych można skonfigurować w rozproszonych grupach dostępności jako synchroniczne lub asynchroniczne. Jednak przenoszenie danych różni się nieco w rozproszonych grupach dostępności w porównaniu z tradycyjną grupą dostępności. Mimo że każda grupa dostępności ma replikę podstawową, istnieje tylko jedna kopia baz danych uczestniczących w rozproszonej grupie dostępności, która może akceptować operacje wstawiania, aktualizacji i usuwania. Jak pokazano na poniższej ilustracji, AG 1 to główna grupa dostępności. Replika podstawowa wysyła transakcje zarówno do replik pomocniczych grupy dostępności 1, jak i repliki podstawowej grupy dostępności 2. Replika podstawowa grupy dostępności 2 jest również znana jako przekaźnik. Przekaźnik jest podstawową repliką w pomocniczej grupie dostępności w rozproszonej grupie dostępności. Przekaźnik odbiera transakcje z repliki podstawowej w podstawowej grupie dostępności i przekazuje je do replik pomocniczych we własnej grupie dostępności. Następnie moduł przesyłania aktualizuje repliki pomocnicze grupy AG 2.

Jedynym sposobem, aby podstawowa replika grupy dostępności AG 2 akceptowała dodawanie, aktualizację i usuwanie, jest ręczne przeniesienie rozproszonej grupy dostępności z AG 1 na AG 2. Na powyższym rysunku, ponieważ grupa dostępności AG 1 zawiera zapisywalną kopię bazy danych, dokonanie przełączenia awaryjnego sprawia, że grupa dostępności AG 2 może obsługiwać wstawki, aktualizacje i usunięcia. Aby uzyskać informacje na temat przełączania w tryb failover jednej rozproszonej grupy dostępności do innej, zobacz Przechodzenie w tryb failover do pomocniczej grupy dostępności.

Uwaga / Notatka

• Rozproszone grupy dostępności w programie SQL Server 2016 obsługują tryb failover tylko z jednej grupy dostępności do innej przy użyciu opcji FORCE_FAILOVER_ALLOW_DATA_LOSS.
• W przypadku korzystania z replikacji transakcyjnej z rozproszonymi grupami dostępności replika przekazująca nie może być skonfigurowana jako publikator.

Zmiany programu SQL Server 2025

Program SQL Server 2025 (17.x) wprowadza następujące zmiany:

Ulepszenie synchronizacji rozproszonych grup dostępności

SQL Server 2025 (17.x) wprowadza zmianę w wewnętrznym mechanizmie synchronizacji w rozproszonych grupach dostępności w celu zwiększenia wydajności synchronizacji przez zmniejszenie obciążenia sieci, gdy replika przekazująca jest w trybie zatwierdzania asynchronicznego. Ta zmiana jest domyślnie włączona i nie wymaga żadnej konfiguracji.

Uwaga / Notatka

Skonfigurowanie rozproszonej grupy dostępności z niezgodnością między trybami dostępności dwóch bazowych grup dostępności nie jest zalecane i może wprowadzić opóźnienie synchronizacji. Obie grupy dostępności powinny być skonfigurowane w tym samym trybie dostępności (synchronicznym lub asynchronicznym), aby zapewnić optymalną wydajność i synchronizację.

Obsługa zawartej grupy dostępności

Program SQL Server 2025 (17.x) wprowadza obsługę rozproszonej zawartej grupy dostępności. Jeśli zamierzasz użyć zamkniętej grupy dostępności jako forwardera w rozproszonej grupie dostępności, musisz utworzyć zamkniętą grupę dostępności, używając klauzuli AUTOSEEDING_SYSTEM_DATABASES w opcji WITH | CONTAINED polecenia CREATE AVAILABILITY GROUP.

Wymagania dotyczące wersji i edycji

Rozproszone grupy dostępności w programie SQL Server 2017 lub nowszym mogą łączyć główne wersje programu SQL Server w tej samej rozproszonej grupie dostępności. Grupa dostępności zawierająca podstawową grupę dostępności odczytu/zapisu może być taka sama lub niższa niż inne grupy dostępności uczestniczące w rozproszonej grupy dostępności. Inni prokuratorzy generalni mogą być tej samej wersji lub nowszej. Ten scenariusz jest przeznaczony dla scenariuszy uaktualniania i migracji. Jeśli na przykład grupa dostępności zawierająca replikę podstawową odczytu/zapisu używa SQL Server 2016, ale chcesz uaktualnić/przeprowadzić migrację do SQL Server 2017 lub nowszego, inną grupę dostępności uczestniczącą w rozproszonej grupie dostępności można skonfigurować z SQL Server 2017.

Ponieważ funkcja rozproszonych grup dostępności nie istnieje w programie SQL Server 2012 lub 2014, grupy dostępności utworzone za pomocą tych wersji nie mogą uczestniczyć w rozproszonych grupach dostępności.

Uwaga / Notatka

W zależności od wersji programu SQL Server podczas nawiązywania połączenia z usługami platformy Azure (takimi jak link wystąpienia zarządzanego) można skonfigurować rozproszoną grupę dostępności z wersją Standard lub kombinację wersji Standard i Enterprise. Przejrzyj KB5016729 , aby dowiedzieć się więcej.

Ponieważ istnieją dwie oddzielne grupy dostępności, proces instalowania dodatku Service Pack lub aktualizacji zbiorczej na repliki biorącej udział w rozproszonej grupie dostępności jest nieco inny niż w przypadku tradycyjnej grupy dostępności:

1. Zacznij od zaktualizowania replik drugiej grupy dostępności w rozproszonej grupie dostępności.

2. Zaktualizuj repliki podstawowej grupy dostępności w rozproszonej grupie dostępności.

3. Podobnie jak w przypadku standardowej grupy dostępności, przełącz podstawową grupę dostępności w tryb failover do jednej z własnych replik (nie do podstawowej drugiej grupy dostępności) i popraw ją. Jeśli nie ma repliki innej niż podstawowa, konieczne będzie ręczne przełączenie awaryjne do drugiej grupy dostępności.

Wersje systemu Windows Server i rozproszone grupy dostępności

Rozproszona grupa dostępności obejmuje wiele grup dostępności, z których każda jest własną bazową usługą WSFC, a rozproszona grupa dostępności jest konstrukcją tylko dla programu SQL Server. Oznacza to, że WSFCs, które zawierają poszczególne grupy dostępności, mogą mieć różne główne wersje systemu Windows Server. Wersje główne programu SQL Server muszą być takie same, jak opisano w poprzedniej sekcji. Podobnie jak na rysunku początkowym, na poniższej ilustracji przedstawiono AG 1 i AG 2 biorące udział w rozproszonej grupie dostępności, ale każda z WSFC jest inną wersją systemu Windows Server.

Poszczególne platformy WSFCs i odpowiadające im grupy dostępności są zgodne z tradycyjnymi regułami. Oznacza to, że mogą być przyłączone do domeny lub nie są przyłączone do domeny (Windows Server 2016 lub nowszy). W przypadku połączenia dwóch różnych grup dostępności w jednej rozproszonej grupie dostępności istnieją cztery scenariusze:

• Oba WSFCs są przyłączone do tej samej domeny.
• Każda usługa WSFC jest przyłączona do innej domeny.
• Jedna usługa WSFC jest przyłączona do domeny, a jedna usługa WSFC nie jest przyłączona do domeny.
• Żaden z WSFC nie jest przyłączony do domeny.

Gdy obie usługi WSFCs są przyłączone do tej samej domeny (nie zaufanych domen), nie trzeba wykonywać żadnych specjalnych czynności podczas tworzenia rozproszonej grupy dostępności. W przypadku grup dostępności i WSFC, które nie są przyłączone do tej samej domeny, użyj certyfikatów, aby rozproszona grupa dostępności działała podobnie do tworzenia grupy dostępności niezależnej od domeny. Aby zobaczyć, jak skonfigurować certyfikaty dla rozproszonej grupy dostępności, wykonaj kroki 3–13 w obszarze Tworzenie niezależnej od domeny grupy dostępności.

W przypadku rozproszonej grupy dostępności podstawowe repliki w każdej grupie dostępności muszą posiadać wzajemnie swoje certyfikaty. Jeśli masz już punkty końcowe, które nie korzystają z certyfikatów, skonfiguruj ponownie te punkty końcowe przy użyciu polecenia ALTER ENDPOINT , aby odzwierciedlić użycie certyfikatów.

Scenariusze użycia

Poniżej przedstawiono trzy główne scenariusze użycia rozproszonej grupy dostępności:

• Odzyskiwanie po awarii i łatwiejsze konfiguracje wielu lokacji
• Migracja do nowego sprzętu lub konfiguracji, które mogą obejmować użycie nowego sprzętu lub zmianę podstawowych systemów operacyjnych
• Zwiększenie liczby replik do odczytu powyżej ośmiu w pojedynczej grupie dostępności poprzez rozciąganie ich na wiele grup dostępności

Scenariusze odzyskiwania po awarii i scenariusze obejmujące wiele lokacji

Tradycyjna grupa dostępności wymaga, aby wszystkie serwery należały do tej samej usługi WSFC, co może stanowić wyzwanie dla wielu centrów danych. Na poniższej ilustracji przedstawiono wygląd tradycyjnej architektury grupy dostępności obejmującej wiele lokacji, w tym przepływ danych. Istnieje jedna replika podstawowa, która wysyła transakcje do wszystkich replik pomocniczych. Ta konfiguracja jest pod pewnymi względami mniej doskonała niż rozproszona grupa dostępności. Na przykład należy zaimplementować takie elementy jak Usługa Active Directory (jeśli ma zastosowanie) i monitor kworum w usłudze WSFC. Może być również konieczne uwzględnienie innych aspektów WSFC, takich jak zmiana głosów węzłów.

Rozproszone grupy dostępności oferują bardziej elastyczny scenariusz wdrażania dla grup dostępności obejmujących wiele centrów danych. Można nawet użyć rozproszonych grup dostępności, w których funkcje, takie jak wysyłanie dzienników , były używane w przeszłości w scenariuszach, takich jak odzyskiwanie po awarii. Jednak w przeciwieństwie do log shipping, rozproszone grupy dostępności nie mogą stosować transakcji z opóźnieniem. Oznacza to, że grupy dostępności lub rozproszone grupy dostępności nie mogą pomóc w przypadku błędu ludzkiego, w którym dane są niepoprawnie aktualizowane lub usuwane.

Rozproszone grupy dostępności są luźno powiązane, co w tym przypadku oznacza, że nie wymagają pojedynczego programu WSFC i są obsługiwane przez program SQL Server. Ponieważ kontrolery WSFCs są utrzymywane indywidualnie, a synchronizacja jest przede wszystkim asynchroniczna między dwiema grupami dostępności, łatwiej jest skonfigurować odzyskiwanie po awarii w innej lokacji. Repliki podstawowe w każdej grupie dostępności synchronizują własne repliki pomocnicze.

• Obsługiwana jest tylko ręczna praca w trybie failover dla rozproszonej grupy dostępności. W sytuacji odzyskiwania danych po awarii, w której przełączasz centra danych, nie należy konfigurować automatycznego trybu przełączenia awaryjnego (z rzadkimi wyjątkami).
• Najprawdopodobniej nie trzeba będzie ustawiać niektórych z tradycyjnych elementów czy parametrów dla wielostanowiskowych lub podsieciowych WSFC, takich jak CrossSubnetThreshold, ale nadal należy uwzględnić opóźnienie sieci na innej warstwie transportu danych. Różnica polega na tym, że każda grupa WSFC zapewnia własną dostępność; klaster nie jest jednym dużym zespołem czterech węzłów. Istnieją dwa oddzielne dwuwęzłowe klastry WSFC, jak pokazano na poprzedniej ilustracji.
• Zalecamy asynchroniczne przenoszenie danych, ponieważ takie podejście byłoby przeznaczone do odzyskiwania po awarii.
• Jeśli skonfigurujesz synchroniczne przenoszenie danych między repliką podstawową i co najmniej jedną repliką pomocniczą drugiej grupy dostępności, a w rozproszonej grupie dostępności skonfigurujesz synchroniczne przenoszenie, rozproszona grupa dostępności będzie czekać, aż wszystkie synchroniczne kopie uznają, że mają dane. Jeśli wiele rozproszonych grup dostępności jest połączone (AG1 —> AG2 —> AG3) i ustawione na synchroniczne, rozproszona grupa dostępności będzie czekać, aż zostanie zaktualizowana ostatnia replika ostatniej grupy dostępności.

Migracja

Ponieważ rozproszone grupy dostępności obsługują dwie zupełnie różne konfiguracje grup dostępności, umożliwiają nie tylko łatwiejsze odzyskiwanie po awarii i scenariusze obejmujące wiele lokacji, ale także scenariusze migracji. Niezależnie od tego, czy przeprowadzasz migrację do nowego sprzętu, czy maszyn wirtualnych (lokalnych lub IaaS w chmurze publicznej), skonfigurowanie rozproszonej grupy dostępności umożliwia migrację, w której w przeszłości można było używać kopii zapasowych, kopiowania i przywracania lub wysyłania dziennika.

Możliwość migracji jest szczególnie przydatna w scenariuszach, w których zmieniasz lub uaktualniasz bazowy system operacyjny, zachowując tę samą wersję programu SQL Server. Mimo że system Windows Server 2016 umożliwia uaktualnienie stopniowe z systemu Windows Server 2012 R2 na tym samym sprzęcie, większość użytkowników decyduje się wdrożyć nowy sprzęt lub maszyny wirtualne.

Aby ukończyć migrację do nowej konfiguracji, na końcu procesu zatrzymaj cały ruch danych do oryginalnej grupy dostępności i zmień rozproszoną grupę dostępności na synchroniczne przenoszenie danych. Ta akcja gwarantuje, że podstawowa replika drugiej grupy dostępności jest w pełni zsynchronizowana, więc nie będzie utraty danych. Po zweryfikowaniu synchronizacji przełącz rozproszoną grupę dostępności do wtórnej grupy dostępności. Aby uzyskać więcej informacji, zobacz Przełączanie na grupę dostępności pomocniczą.

Po migracji, gdzie druga grupa dostępności jest teraz nową podstawową grupą dostępności, może być konieczne wykonanie jednej z następujących czynności:

• Zmień nazwę odbiornika w pomocniczej grupie dostępności (i ewentualnie usuń lub zmień nazwę starego na oryginalnej podstawowej grupie dostępności) lub utwórz go ponownie z odbiornikiem z oryginalnej podstawowej grupy dostępności, aby aplikacje i użytkownicy mogli uzyskać dostęp do nowej konfiguracji.
• Jeśli zmiana nazwy lub ponowne utworzenie nie jest możliwe, wskaż aplikacjom i użytkownikom odbiornik w drugiej grupie dostępności.

Migrowanie do wyższych wersji programu SQL Server

Podczas scenariusza migracji można skonfigurować rozproszoną grupę dostępności w celu migrowania baz danych do docelowego programu SQL Server, który jest wyższej wersji niż źródło. Jednak istnieje kilka ograniczeń.

Podczas konfigurowania rozproszonej grupy dostępności z celem migracji programu SQL Server w wersji wyższej niż źródłowa, automatyczne przypisywanie nie jest obsługiwane, więc tryb przypisywania musi być ustawiony na MANUAL. Jeśli nie wyłączysz AUTO-SEEDING, migracja zakończy się niepowodzeniem i zostanie wyświetlony błąd 946 "Nie można otworzyć bazy danych 'DistributionAG' w wersji xxx. Uaktualnij bazę danych do najnowszej wersji" w dzienniku błędów. Należy ustawić tryb inicjalizacji na MANUAL i ręcznie wykonać pełną kopię zapasową oraz kopię transakcyjną źródłowej bazy danych z podstawowej Grupy Dostępności. Następnie ręcznie przywróć go wraz z dziennikiem transakcji do wtórnej grupy AG. Aby dowiedzieć się więcej, zapoznaj się z instrukcjami ręcznego rozmieszczania w celu skonfigurowania rozproszonej grupy dostępności AG oraz skryptami do tworzenia kopii zapasowych i przywracania bazy danych z podstawowej grupy dostępności AG do pomocniczej grupy dostępności AG.

Zakładając, że drugorzędna grupa dostępności (AG2) jest celem migracji i ma wyższą wersję niż podstawowa grupa dostępności (AG1), należy wziąć pod uwagę następujące ograniczenia:

• Nie będziesz mieć dostępu do odczytu do żadnej z replik baz danych w pomocniczej grupie dostępności, o ile podstawowa grupa dostępności jest w niższej wersji.
• W tym czasie aktualizacje będą nadal przepływać z podstawowej grupy dostępności (AG1) do pomocniczej grupy dostępności (AG2), ale stan pomocniczej grupy dostępności będzie wyświetlany jako Częściowo zdrowa, a bazy danych na replikach pomocniczych pomocniczej grupy dostępności (AG2) będą wyświetlane jako Synchronizowanie/W trakcie odzyskiwania (nawet jeśli grupa dostępności jest w trybie zatwierdzania synchronizacji).
• Po przełączeniu rozproszonej grupy dostępności w tryb failover do nowszej wersji (AG2) grupa AG2 powinna stać się w dobrej kondycji.
• W tym czasie powrót do AG1 nie będzie możliwy, ponieważ jest w niższej wersji.
• Ponieważ AG1 jest w niższej wersji, aktualizacje z AG2 po przełączeniu awaryjnym do AG2 nie będą replikowane do AG1.
• W tym miejscu wybierz, czy chcesz wycofać z eksploatacji oryginalną grupę dostępności (podstawową), czy uaktualnić grupę dostępności AG1 i zachować rozproszoną grupę dostępności.
  • Jeśli zdecydujesz się zlikwidować grupę dostępności 1, usuń oryginalną podstawową grupę dostępności z rozproszonej grupy dostępności, a proces zostanie ukończony.
  • Jeśli zdecydujesz się zachować rozproszoną grupę dostępności, uaktualnij wersję programu SQL Server dla grupy dostępności AG1, aby dopasować ją do grupy dostępności AG2. Po uaktualnieniu AG1, AG1 poprawi swój stan, rozproszona grupa dostępności poprawi swój stan, repliki nadążają za synchronizacją, a możliwe staje się przywrócenie po awarii.

Skalowanie replik do odczytu

W razie potrzeby jedna rozproszona grupa dostępności może mieć maksymalnie 16 replik pomocniczych. W związku z tym może mieć maksymalnie 18 kopii do odczytu, w tym dwie podstawowe repliki należące do różnych grup dostępności. Takie podejście oznacza, że więcej niż jedna witryna może mieć dostęp niemal w czasie rzeczywistym do raportowania do różnych aplikacji.

Rozproszone grupy dostępności mogą pomóc w skalowaniu zespołu serwerów tylko do odczytu bardziej niż w przypadku pojedynczej grupy dostępności. Rozproszona grupa dostępności może zwiększać możliwości replik do odczytu na dwa sposoby:

• Możesz użyć repliki podstawowej drugiej grupy dostępności w rozproszonej grupie dostępności, aby utworzyć inną rozproszoną grupę dostępności, mimo że baza danych nie znajduje się w usłudze RECOVERY.
• Możesz również użyć repliki podstawowej pierwszej grupy dostępności, aby utworzyć inną rozproszoną grupę dostępności.

Innymi słowy replika podstawowa może uczestniczyć w różnych rozproszonych grupach dostępności. Na poniższej ilustracji przedstawiono AG 1 i AG 2 biorące udział w Rozproszonej AG 1, podczas gdy AG 2 i AG 3 uczestniczą w Rozproszonej AG 2. Replika podstawowa (lub forwarder) AG 2 jest zarówno repliką pomocniczą rozproszonej AG 1, jak i repliką podstawową rozproszonej AG 2.

Na poniższej ilustracji przedstawiono AG 1 jako replikę podstawową dla dwóch różnych rozproszonych grup dostępności: Rozproszona AG 1 (składająca się z AG 1 i AG 2) oraz Rozproszona AG 2 (składająca się z AG 1 i AG 3).

W obu powyższych przykładach może istnieć do 27 całkowita liczba replik w trzech grupach dostępności, z których wszystkie mogą być używane w przypadku zapytań tylko do odczytu.

Routing tylko do odczytu nie działa całkowicie z rozproszonymi grupami dostępności. W szczególności,

1. Read-Only Routing można skonfigurować i będzie działać dla podstawowej grupy dostępności w ramach rozproszonej grupy dostępności.
2. Read-Only Routing można skonfigurować, ale nie będzie działać w przypadku pomocniczej grupy dostępności w rozproszonej grupie dostępności. Wszystkie zapytania, jeśli używają nasłuchującego do nawiązania połączenia z grupą dostępności pomocniczej, przechodzą do podstawowej repliki tej grupy dostępności. W przeciwnym razie należy skonfigurować każdą replikę tak, aby zezwalała na wszystkie połączenia jako replikę pomocniczą i uzyskiwać do nich bezpośredni dostęp. Jednak routing tylko do odczytu będzie działać, jeśli pomocnicza grupa dostępności stanie się podstawowa po przejściu w tryb failover. To zachowanie może zostać zmienione w aktualizacji programu SQL Server 2016 lub w przyszłej wersji programu SQL Server.

Inicjowanie pomocniczych grup dostępności

Rozproszone grupy dostępności zostały zaprojektowane z automatycznym zasiewem jako główną metodą stosowaną do inicjowania repliki podstawowej w drugiej grupie dostępności. Pełne przywrócenie bazy danych na podstawowej replice drugiej dostępnej grupy jest możliwe, jeśli wykonasz następujące czynności:

1. Przywróć kopię zapasową bazy danych z opcją NORECOVERY.
2. W razie potrzeby przywróć odpowiednie kopie zapasowe dziennika transakcji z opcją NORECOVERY.
3. Utwórz drugą grupę dostępności bez określania nazwy bazy danych i z SEEDING_MODE ustawioną na wartość AUTOMATIC.
4. Utwórz rozproszoną grupę dostępności przy użyciu automatycznego rozmieszczania.

Po dodaniu podstawowej repliki drugiej grupy dostępności do rozproszonej grupy dostępności replika jest sprawdzana względem podstawowych baz danych pierwszej grupy dostępności, a automatyczne rozmieszczanie synchronizuje bazę danych ze źródłem. Istnieje kilka zastrzeżeń:

• Dane wyjściowe wyświetlane na podstawowej replice drugiej grupy dostępności wykażą status sys.dm_hadr_automatic_seeding jako FAILED z powodem "Seeding Check Message Timeout" (Przekroczenie limitu czasu komunikatu sprawdzania rozmieszczania).

• Bieżący dziennik błędów programu SQL Server w replice podstawowej drugiej grupy dostępności pokaże, że automatyczne rozmieszczanie działało i czy sieci LSN zostały zsynchronizowane.

• Dane wyjściowe wyświetlone w sys.dm_hadr_automatic_seeding na podstawowej replice pierwszej grupy dostępności pokażą obecny_stan UKOŃCZONO.

• Automatyczne rozmieszczanie działa inaczej w przypadku rozproszonych grup dostępności. Aby automatyczne rozmieszczanie rozpoczęło się w drugiej replice, należy wydać polecenie ALTER AVAILABILITY GROUP [AGName] GRANT CREATE ANY DATABASE na tej replice. Mimo że ten warunek jest nadal spełniony w przypadku każdej repliki pomocniczej, która uczestniczy w bazowej grupie dostępności, replika podstawowa drugiej grupy dostępności ma już odpowiednie uprawnienia, aby umożliwić automatyczne rozmieszczanie początkowe po dodaniu jej do rozproszonej grupy dostępności.

Uwaga / Notatka

• Grupa dostępności zapasowej musi używać tego samego punktu końcowego odzwierciedlenia bazy danych. W przeciwnym razie proces replikacji zostaje zatrzymany po lokalnym awaryjnym przełączeniu.
• Bazowe grupy dostępności powinny znajdować się w tym samym trybie dostępności — obie grupy dostępności powinny być w trybie zatwierdzania synchronicznego lub oba te grupy powinny być w trybie zatwierdzania asynchronicznego. Jeśli nie masz pewności, którego chcesz użyć, ustaw zarówno tryb zatwierdzania asynchronicznego, jak i do momentu, gdy wszystko będzie gotowe do pracy w trybie failover.

Monitorowanie kondycji

Rozproszona grupa dostępności jest konstrukcją tylko dla programu SQL Server i nie jest widoczna w bazowej usłudze WSFC. Poniższy przykładowy kod przedstawia dwa różne WSFCs (CLUSTER_A i CLUSTER_B), z których każda ma własne grupy dostępności. Omówiono tylko AG1 w CLUSTER_A i AG2 w CLUSTER_B.

PS C:\> Get-ClusterGroup -Cluster CLUSTER_A

Name                            OwnerNode             State
----                            ---------             -----
AG1                             DENNIS                Online
Available Storage               GLEN                  Offline
Cluster Group                   JY                    Online
New_RoR                         DENNIS                Online
Old_RoR                         DENNIS                Online
SeedingAG                       DENNIS                Online

PS C:\> Get-ClusterGroup -Cluster CLUSTER_B

Name                            OwnerNode             State
----                            ---------             -----
AG2                             TOMMY                 Online
Available Storage               JC                    Offline
Cluster Group                   JC                    Online

Wszystkie szczegółowe informacje o rozproszonej grupie dostępności są dostępne w programie SQL Server, w szczególności w dynamicznych widokach zarządzania grupy dostępności. Obecnie jedyna informacja wyświetlana w programie SQL Server Management Studio dotycząca rozproszonej grupy dostępności jest związana z repliką podstawową dla tych grup dostępności. Jak pokazano na poniższej ilustracji, w folderze Grupy dostępności program SQL Server Management Studio pokazuje, że istnieje rozproszona grupa dostępności. Na rysunku pokazano grupę dostępności AG1 jako replikę podstawową dla pojedynczej lokalnej grupy dostępności tej instancji, a nie dla rozproszonej grupy dostępności.

Jednakże jeśli klikniesz prawym przyciskiem myszy na distribuowaną grupę dostępności, żadne opcje nie są dostępne (zobacz poniższą ilustrację), a rozwinięte foldery Bazy Danych Dostępności, Odbiorniki Grupy Dostępności i Repliki Dostępności są wszystkie puste. Program SQL Server Management Studio 16 wyświetla ten wynik, ale może ulec zmianie w przyszłej wersji programu SQL Server Management Studio.

Jak pokazano na poniższym rysunku, repliki wtórne nie wyświetlają nic w środowisku SQL Server Management Studio związanego z rozproszoną grupą dostępności. Te nazwy grup dostępności są mapowane na role przedstawione w poprzednim obrazie WSFC typu CLUSTER_A.

Wyświetlenie listy wszystkich nazw replik dostępności przez DMV

Te same pojęcia dotyczą podczas korzystania z dynamicznych widoków zarządzania. Korzystając z poniższego zapytania, można zobaczyć wszystkie grupy dostępności (regularne i rozproszone) oraz węzły, które je uczestniczą. Ten wynik jest wyświetlany tylko wtedy, gdy wysyłasz zapytanie do repliki podstawowej w jednym z klastrów WSFC uczestniczących w rozproszonej grupie dostępności. W widoku sys.availability_groups dynamicznego zarządzania istnieje nowa kolumna o nazwie is_distributed, która jest 1, gdy grupa dostępności jest rozproszoną grupą dostępności. Aby wyświetlić tę kolumnę:

-- shows replicas associated with availability groups
SELECT
   ag.[name] AS [AG Name],
   ag.Is_Distributed,
   ar.replica_server_name AS [Replica Name]
FROM sys.availability_groups AS ag
INNER JOIN sys.availability_replicas AS ar
   ON ag.group_id = ar.group_id;
GO

Na poniższym rysunku przedstawiono przykład wyniku z drugiego klastra WSFC, który uczestniczy w rozproszonej grupie dostępności. SPAG1 składa się z dwóch replik: DENNIS i JY. Jednak rozproszona grupa dostępności o nazwie SPDistAG ma nazwy dwóch uczestniczących grup dostępności (SPAG1 i SPAG2), a nie nazw wystąpień, tak jak w przypadku tradycyjnej grupy dostępności.

DMV do listowania rozproszonego zdrowia AG

W programie SQL Server Management Studio wszystkie stany wyświetlane na pulpicie nawigacyjnym i innych obszarach są przeznaczone do synchronizacji lokalnej tylko w ramach tej grupy dostępności. Aby wyświetlić kondycję rozproszonej grupy dostępności, wykonaj zapytanie dotyczące dynamicznych widoków zarządzania. Następujące przykładowe zapytanie rozszerza i uściśli poprzednie zapytanie:

-- shows sync status of distributed AG
SELECT
   ag.[name] AS [AG Name],
   ag.is_distributed,
   ar.replica_server_name AS [Underlying AG],
   ars.role_desc AS [Role],
   ars.synchronization_health_desc AS [Sync Status]
FROM  sys.availability_groups AS ag
INNER JOIN sys.availability_replicas AS ar
   ON  ag.group_id = ar.group_id
INNER JOIN sys.dm_hadr_availability_replica_states AS ars
   ON  ar.replica_id = ars.replica_id
WHERE ag.is_distributed = 1;
GO

DMV do przeglądu podstawowej wydajności

Aby jeszcze bardziej rozszerzyć poprzednie zapytanie, możesz również zobaczyć podstawową wydajność za pośrednictwem dynamicznych widoków zarządzania, dodając element .sys.dm_hadr_database_replicas_states Dynamiczny widok zarządzania przechowuje obecnie informacje o drugiej grupie dostępności. Następujące przykładowe zapytanie, uruchamiane w podstawowej grupie dostępności, generuje przykładowe dane wyjściowe pokazane poniżej:

-- shows underlying performance of distributed AG
SELECT
   ag.[name] AS [Distributed AG Name],
   ar.replica_server_name AS [Underlying AG],
   dbs.[name] AS [Database],
   ars.role_desc AS [Role],
   drs.synchronization_health_desc AS [Sync Status],
   drs.log_send_queue_size,
   drs.log_send_rate,
   drs.redo_queue_size,
   drs.redo_rate
FROM sys.databases AS dbs
INNER JOIN sys.dm_hadr_database_replica_states AS drs
   ON dbs.database_id = drs.database_id
INNER JOIN sys.availability_groups AS ag
   ON drs.group_id = ag.group_id
INNER JOIN sys.dm_hadr_availability_replica_states AS ars
   ON ars.replica_id = drs.replica_id
INNER JOIN sys.availability_replicas AS ar
   ON ar.replica_id = ars.replica_id
WHERE ag.is_distributed = 1;
GO

Widok DMV do wyświetlania liczników wydajności dla rozproszonej grupy dostępności

Poniższe zapytanie wyświetla liczniki wydajności skojarzone z określoną rozproszoną grupą dostępności.

-- displays OS performance counters related to the distributed ag named 'distributedag'
SELECT * FROM sys.dm_os_performance_counters WHERE instance_name LIKE '%distributed%'

Uwaga / Notatka

Filtr LIKE powinien mieć nazwę rozproszonej grupy dostępności. W tym przykładzie nazwa rozproszonej grupy dostępności to "distributedag". Zmień modyfikator, LIKE aby odzwierciedlał nazwę rozproszonej grupy dostępności.

Stan DMV do wyświetlania kondycji zarówno grupy dostępności AG, jak i rozproszonej grupy dostępności AG.

Poniższe zapytanie zawiera wiele informacji o kondycji zarówno grupy dostępności, jak i rozproszonej grupy dostępności. (Odtworzony z uprawnieniem Tracy Boggiano).)

-- displays sync status, send rate, and redo rate of availability groups,
-- including distributed AG
SELECT ag.name AS [AG Name],
    ag.is_distributed,
    ar.replica_server_name AS [AG],
    dbs.name AS [Database],
    ars.role_desc,
    drs.synchronization_health_desc,
    drs.log_send_queue_size,
    drs.log_send_rate,
    drs.redo_queue_size,
    drs.redo_rate,
    drs.suspend_reason_desc,
    drs.last_sent_time,
    drs.last_received_time,
    drs.last_hardened_time,
    drs.last_redone_time,
    drs.last_commit_time,
    drs.secondary_lag_seconds
FROM sys.databases dbs
INNER JOIN sys.dm_hadr_database_replica_states drs
    ON dbs.database_id = drs.database_id
INNER JOIN sys.availability_groups ag
    ON drs.group_id = ag.group_id
INNER JOIN sys.dm_hadr_availability_replica_states ars
    ON ars.replica_id = drs.replica_id
INNER JOIN sys.availability_replicas ar
    ON ar.replica_id = ars.replica_id
--WHERE ag.is_distributed = 1
GO

Dynamiczne widoki zarządzania do wyświetlania metadanych rozproszonej grupy dostępności

Poniższe zapytania będą wyświetlać informacje o adresach URL punktów końcowych używanych przez grupy dostępności, w tym rozproszonej grupie dostępności. (Odtworzony z pozwoleniem Davida Barbarina).

-- shows endpoint url and sync state for ag, and dag
SELECT
   ag.name AS group_name,
   ag.is_distributed,
   ar.replica_server_name AS replica_name,
   ar.endpoint_url,
   ar.availability_mode_desc,
   ar.failover_mode_desc,
   ar.primary_role_allow_connections_desc AS allow_connections_primary,
   ar.secondary_role_allow_connections_desc AS allow_connections_secondary,
   ar.seeding_mode_desc AS seeding_mode
FROM sys.availability_replicas AS ar
JOIN sys.availability_groups AS ag
   ON ar.group_id = ag.group_id;
GO

DMV pokazuje bieżący stan wysiewu

Poniższe zapytanie wyświetla informacje o bieżącym stanie wysiewu. Jest to przydatne w przypadku rozwiązywania problemów z błędami synchronizacji między replikami. (Odtworzony z pozwoleniem Davida Barbarina).

-- shows current_state of seeding
SELECT ag.name AS aag_name,
    ar.replica_server_name,
    d.name AS database_name,
    has.current_state,
    has.failure_state_desc AS failure_state,
    has.error_code,
    has.performed_seeding,
    has.start_time,
    has.completion_time,
    has.number_of_attempts
FROM sys.dm_hadr_automatic_seeding AS has
INNER JOIN sys.availability_groups AS ag
    ON ag.group_id = has.ag_id
INNER JOIN sys.availability_replicas AS ar
    ON ar.replica_id = has.ag_remote_replica_id
INNER JOIN sys.databases AS d
    ON d.group_database_id = has.ag_db_id;
GO

Treści powiązane

• Korzystanie z kreatora grupy dostępności (SQL Server Management Studio)
• Skorzystaj z okna dialogowego nowej grupy dostępności (SQL Server Management Studio)
• Tworzenie grupy dostępności przy użyciu języka Transact-SQL