Wysoka dostępność z usługą SQL Managed Instance włączoną przez usługę Azure Arc

Zarządzana instancja SQL włączona dzięki Azure Arc jest wdrażana na Kubernetes jako konteneryzowaną aplikację. Używa konstrukcji Kubernetes, takich jak zestawy stanowe i magazyn trwały, aby zapewnić wbudowane:

Monitorowanie kondycji
Wykrywanie błędów
Automatyczne przełączanie do trybu failover w celu zachowania zdrowia usługi.

W celu zwiększenia niezawodności można również skonfigurować usługę SQL Managed Instance włączoną przez usługę Azure Arc w celu wdrożenia z dodatkowymi replikami w konfiguracji wysokiej dostępności. Kontroler danych usług Arc zarządza:

Monitorowanie
Wykrywanie błędów
Automatyczne przełączanie awaryjne

Usługa danych z obsługą Arc udostępnia tę funkcję bez potrzeby interwencji użytkownika. Usługa:

Konfigurowanie grupy dostępności
Konfiguruje punkty końcowe dla mirroringu baz danych
Dodaje bazy danych do grupy dostępności
Koordynuje tryb failover i uaktualnianie.

W tym dokumencie omówiono oba typy wysokiej dostępności.

Wystąpienie zarządzane SQL włączone przez usługę Azure Arc zapewnia różne poziomy wysokiej dostępności w zależności od tego, czy wystąpienie zarządzane SQL zostało wdrożone jako warstwa usługi ogólnego przeznaczenia, czy Krytyczne dla działania firmy warstwę usługi.

Wysoka dostępność w warstwie usługi ogólnego przeznaczenia

W warstwie usługi o ogólnym przeznaczeniu dostępna jest tylko jedna replika, a wysoka dostępność osiągana jest dzięki orkiestracji Kubernetes. Jeśli na przykład zasobnik lub węzeł zawierający obraz kontenera wystąpienia zarządzanego ulegnie awarii, platforma Kubernetes próbuje uruchomić inny zasobnik lub węzeł i podłączyć do tego samego magazynu trwałego. W tym czasie wystąpienie zarządzane SQL jest niedostępne dla aplikacji. Aplikacje muszą ponownie nawiązać połączenie i ponowić transakcję, gdy nowy pod jest uruchomiony. Jeśli używany jest typ usługi load balancer, aplikacje mogą ponownie nawiązać połączenie z tym samym podstawowym punktem końcowym, a platforma Kubernetes przekieruje połączenie do nowego podstawowego punktu końcowego. Jeśli typ usługi to nodeport wówczas aplikacje będą musiały ponownie nawiązać połączenie z nowym adresem IP.

Sprawdź wbudowaną wysoką dostępność

Aby zweryfikować wbudowaną wysoką dostępność zapewnianą przez platformę Kubernetes, możesz:

Usuń zasobnik istniejącego wystąpienia zarządzanego
Sprawdź, czy platforma Kubernetes odzyskuje dane z tej akcji

W trakcie procesu przywracania platforma Kubernetes tworzy nowy zasobnik i dołącza magazyn trwały.

Wymagania wstępne

Klaster Kubernetes wymaga udostępnionego magazynu zdalnego
Wystąpienie zarządzane SQL w usłudze Azure Arc, wdrożone z jedną repliką (domyślnie)

Wyświetl pody.

kubectl get pods -n <namespace of data controller>

Usuń zasobnik wystąpienia zarządzanego.

kubectl delete pod <name of managed instance>-0 -n <namespace of data controller>

Na przykład

user@pc:/# kubectl delete pod sql1-0 -n arc
pod "sql1-0" deleted

Wyświetl zasobniki, aby sprawdzić, czy wystąpienie zarządzane jest odzyskiwane.

kubectl get pods -n <namespace of data controller>

Na przykład:

user@pc:/# kubectl get pods -n arc
NAME                 READY   STATUS    RESTARTS   AGE
sql1-0               2/3     Running   0          22s

Po odzyskaniu wszystkich kontenerów w module można nawiązać połączenie z wystąpieniem zarządzanym.

Wysoka dostępność w warstwie usługi Krytyczne dla działania firmy

W warstwie usługi Krytyczne dla działania firmy oprócz tego, co jest natywnie udostępniane przez orkiestrację platformy Kubernetes, usługa SQL Managed Instance dla usługi Azure Arc udostępnia zawartą grupę dostępności. Zawarta grupa dostępności jest oparta na technologii Always On programu SQL Server. Zapewnia on wyższy poziom dostępności. Instancja zarządzana SQL włączona w usłudze Azure Arc, wdrożona z wykorzystaniem warstwy usługi Krytyczne dla działania firmy, może być wdrożona z 2 lub 3 replikami. Te repliki są zawsze synchronizowane ze sobą.

W przypadku zamkniętych grup dostępności wszelkie awarie zasobnika lub węzła są niezauważalne dla aplikacji. Zamknięta grupa dostępności udostępnia co najmniej jedną inną instancję, która zawiera wszystkie dane z serwera podstawowego i jest gotowa do obsłużenia połączeń.

Ograniczone grupy dostępności

Grupa dostępności wiąże jedną lub więcej baz danych użytkownika w grupę logiczną, tak aby w przypadku awarii cała grupa baz danych przeszła na replikę pomocniczą jako pojedyncza jednostka. Grupa dostępności replikuje tylko dane w bazach danych użytkowników, ale nie dane w systemowych bazach danych, takich jak identyfikatory logowania, uprawnienia lub zadania agenta. Zawarta grupa dostępności zawiera metadane z systemowych baz danych, takich jak msdb i master. Gdy identyfikatory logowania są tworzone lub modyfikowane w replice podstawowej, są one również automatycznie tworzone w replikach pomocniczych. Podobnie, gdy zadanie agenta zostanie utworzone lub zmodyfikowane w repliki podstawowej, repliki pomocnicze również otrzymają te zmiany.

Usługa SQL Managed Instance włączona przez usługę Azure Arc przyjmuje tę koncepcję zawartej grupy dostępności i dodaje operator Kubernetes, dzięki czemu można je wdrażać i zarządzać na dużą skalę.

Możliwości, które zawierały grupy dostępności, umożliwiają:

Po wdrożeniu z wieloma replikami tworzona jest pojedyncza grupa dostępności o takiej samej nazwie jak zarządzane wystąpienie SQL z obsługą Arc. Domyślnie zawarta grupa dostępności ma trzy repliki, w tym replikę podstawową. Wszystkie operacje CRUD dla grupy dostępności są zarządzane wewnętrznie, w tym tworzenie grupy dostępności lub dołączanie replik do utworzonej grupy dostępności. Nie można utworzyć większej liczby grup dostępności w wystąpieniu.
Wszystkie bazy danych są automatycznie dodawane do grupy dostępności, w tym wszystkich baz danych użytkowników i systemów, takich jak master i msdb. Ta funkcja zapewnia widok jednolitego systemu przez wszystkie repliki grupy dostępności. Zwróć uwagę zarówno na bazy danych containedag_master, jak i containedag_msdb w przypadku bezpośredniego połączenia z instancją. Bazy containedag_* danych reprezentują element master i msdb wewnątrz grupy dostępności.
Zewnętrzny punkt końcowy jest automatycznie aprowizowany do łączenia się z bazami danych w grupie dostępności. Ten punkt końcowy <managed_instance_name>-external-svc odgrywa rolę nasłuchiwacza grupy dostępności.

Wdrażanie instancji SQL Managed Instance obsługiwanej przez Azure Arc z wieloma replikami przy użyciu portalu Azure

Z portalu Azure na stronie tworzenia zarządzanego wystąpienia SQL obsługiwanego przez Azure Arc:

Wybierz pozycję Konfiguruj obliczenia i magazyn w obszarze Obliczenia i magazyn. W portalu są wyświetlane ustawienia zaawansowane.
W obszarze Warstwa usługi wybierz pozycję Krytyczne dla działania firmy.
Sprawdź wartość "Tylko do użytku programistycznego", jeśli jest używana do celów programistycznych.
W obszarze Wysoka dostępność wybierz 2 repliki lub 3 repliki.

Ustawienia wysokiej dostępności

Wdrażanie wielu replik za pomocą Azure CLI

Gdy zarządzane wystąpienie SQL włączone przez Azure Arc jest wdrażane w warstwie usługi Business Critical, wdrożenie tworzy wiele replik. Ustawienie i konfiguracja zawartych grup dostępności między tymi wystąpieniami jest wykonywana automatycznie podczas wdrażania.

Na przykład następujące polecenie tworzy wystąpienie zarządzane z 3 replikami.

Pośrednio połączony tryb:

az sql mi-arc create -n <instanceName> --k8s-namespace <namespace> --use-k8s --tier <tier> --replicas <number of replicas>

Przykład:

az sql mi-arc create -n sqldemo --k8s-namespace my-namespace --use-k8s --tier BusinessCritical --replicas 3

Tryb połączenia bezpośredniego:

az sql mi-arc create --name <name> --resource-group <group>  --location <Azure location> –subscription <subscription>  --custom-location <custom-location> --tier <tier> --replicas <number of replicas>

Przykład:

az sql mi-arc create --name sqldemo --resource-group rg  --location uswest2 –subscription xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx  --custom-location private-location --tier BusinessCritical --replcias 3

Domyślnie wszystkie repliki są konfigurowane w trybie synchronicznym. Oznacza to, że wszystkie aktualizacje w wystąpieniu podstawowym są synchronicznie replikowane do każdego z wystąpień pomocniczych.

Wyświetlanie i monitorowanie stanu wysokiej dostępności

Po zakończeniu wdrażania połącz się z podstawowym punktem końcowym z programu SQL Server Management Studio.

Zweryfikuj i pobierz punkt końcowy repliki podstawowej i połącz się z nim z programu SQL Server Management Studio. Jeśli na przykład wystąpienie SQL zostało wdrożone przy użyciu service-type=loadbalancer, uruchom poniższe polecenie, aby pobrać punkt końcowy do połączenia:

az sql mi-arc list --k8s-namespace my-namespace --use-k8s

lub

kubectl get sqlmi -A

Uzyskaj podstawowe i pomocnicze punkty końcowe oraz status AG

kubectl describe sqlmi Użyj poleceń lubaz sql mi-arc show, aby wyświetlić podstawowe i pomocnicze punkty końcowe oraz stan wysokiej dostępności.

Przykład:

kubectl describe sqlmi sqldemo -n my-namespace

lub

az sql mi-arc show --name sqldemo --k8s-namespace my-namespace --use-k8s

Przykładowe wyjście:

 "status": {
    "endpoints": {
      "logSearchDashboard": "https://10.120.230.404:5601/app/kibana#/discover?_a=(query:(language:kuery,query:'custom_resource_name:sqldemo'))",
      "metricsDashboard": "https://10.120.230.46:3000/d/40q72HnGk/sql-managed-instance-metrics?var-hostname=sqldemo-0",
      "mirroring": "10.15.100.150:5022",
      "primary": "10.15.100.150,1433",
      "secondary": "10.15.100.156,1433"
    },
    "highAvailability": {
      "healthState": "OK",
      "mirroringCertificate": "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----"
    },
    "observedGeneration": 1,
    "readyReplicas": "2/2",
    "state": "Ready"
  }

Możesz nawiązać połączenie z podstawowym punktem końcowym za pomocą programu SQL Server Management Studio i zweryfikować dynamiczne widoki zarządzania jako:

SELECT * FROM sys.dm_hadr_availability_replica_states

Grupa dostępności

Panel dostępności

Panel grupy dostępności kontenerów

Scenariusze trybu failover

W przeciwieństwie do zawsze włączonych grup dostępności programu SQL Server zawarta grupa dostępności jest zarządzanym rozwiązaniem o wysokiej dostępności. W związku z tym tryby failover są ograniczone w porównaniu z typowymi trybami dostępnymi w przypadku grup dostępności SQL Server Always On.

Wdróż instancje zarządzane SQL w warstwie usługi Business Critical w konfiguracji z dwiema replikami lub trzema replikami. Skutki awarii i późniejsza możliwość odzyskiwania różnią się w przypadku każdej konfiguracji. Instancja z trzema replikami zapewnia wyższy poziom dostępności i odzyskiwania niż instancja z dwiema replikami.

W konfiguracji dwóch replik, gdy oba stany węzła to SYNCHRONIZED, jeśli replika podstawowa stanie się niedostępna, replika pomocnicza jest automatycznie promowana do podstawowej. Gdy replika, która uległa awarii, stanie się dostępna, zostanie zaktualizowana o wszystkie oczekujące zmiany. Jeśli występują problemy z łącznością między replikami, replika podstawowa może nie zatwierdzać żadnych transakcji, ponieważ każda transakcja musi zostać zatwierdzona w obu replikach, zanim powodzenie zostanie zwrócone z powrotem na serwerze podstawowym.

W konfiguracji z trzema replikami transakcja musi zostać zatwierdzona w co najmniej 2 z 3 replik przed powrotem komunikatu o powodzeniu do aplikacji. W przypadku awarii jedna z replik zapasowych jest automatycznie awansowana do głównego, podczas gdy Kubernetes próbuje odzyskać uszkodzoną replikę. Gdy replika stanie się dostępna, jest automatycznie przyłączona z powrotem do zawartej grupy dostępności i oczekujące zmiany są synchronizowane. Jeśli występują problemy z łącznością między replikami, a więcej niż 2 repliki nie są zsynchronizowane, replika podstawowa nie zatwierdzi żadnych transakcji.

Uwaga

Zaleca się wdrożenie usługi SQL Managed Instance w konfiguracji Business Critical z trzema replikami zamiast dwóch, aby osiągnąć niemal zerową utratę danych.

Aby przełączyć się z repliki podstawowej na jedną z replik zapasowych w przypadku planowanego zdarzenia, uruchom następujące polecenie:

Jeśli nawiążesz połączenie z serwerem podstawowym, możesz użyć następującego skryptu T-SQL, aby przełączyć wystąpienie SQL na jeden z serwerów pomocniczych.

ALTER AVAILABILITY GROUP current SET (ROLE = SECONDARY);

Jeśli łączysz się z repliką pomocniczą, możesz użyć następującej instrukcji T-SQL, aby podwyższyć poziom żądanej repliki pomocniczej do repliki podstawowej.

ALTER AVAILABILITY GROUP current SET (ROLE = PRIMARY);

Preferowana replika podstawowa

Można również ustawić określoną replikę jako replikę podstawową przy użyciu interfejsu wiersza polecenia AZ CLI w sposób przedstawiony poniżej:

az sql mi-arc update --name <sqlinstance name> --k8s-namespace <namespace> --use-k8s --preferred-primary-replica <replica>

Przykład:

az sql mi-arc update --name sqldemo --k8s-namespace my-namespace --use-k8s --preferred-primary-replica sqldemo-3

Uwaga

Kubernetes podejmie próbę ustawienia preferowanej repliki, jednak nie jest to gwarantowane.

Przywracanie bazy danych do wystąpienia z wieloma replikami

Aby przywrócić bazę danych do grupy dostępności, wymagane są dodatkowe kroki. Na poniższych krokach pokazano, jak przywrócić bazę danych w zarządzanej instancji i dodać ją do grupy dostępności.

Uwidocznij zewnętrzny punkt końcowy wystąpienia podstawowego, tworząc nową usługę Kubernetes.

Określ pod, który hostuje replikę główną. Połącz się z wystąpieniem zarządzanym i uruchom:
```
SELECT @@SERVERNAME
```
Zapytanie zwraca pod hostujący replikę podstawową.

Utwórz usługę Kubernetes dla instancji podstawowej, uruchamiając następujące polecenie, jeśli twój klaster Kubernetes korzysta z usług NodePort. Zastąp <podName> nazwą serwera zwróconą w poprzednim kroku oraz <serviceName> preferowaną nazwą utworzonej usługi Kubernetes.
```
kubectl -n <namespaceName> expose pod <podName> --port=1533  --name=<serviceName> --type=NodePort
```
W przypadku usługi LoadBalancer uruchom to samo polecenie, z tą różnicą, że typ utworzonej usługi to LoadBalancer. Na przykład:
```
kubectl -n <namespaceName> expose pod <podName> --port=1533  --name=<serviceName> --type=LoadBalancer
```
Oto przykład tego polecenia uruchamianego w usłudze Azure Kubernetes Service, gdzie pod hostuje primary: sql2-0
```
kubectl -n arc-cluster expose pod sql2-0 --port=1533  --name=sql2-0-p --type=LoadBalancer
```
Pobierz adres IP utworzonej usługi Kubernetes:
```
kubectl get services -n <namespaceName>
```

Przywróć bazę danych do punktu końcowego wystąpienia podstawowego.

Dodaj plik kopii zapasowej bazy danych do kontenera wystąpienia podstawowego.

kubectl cp <source file location> <pod name>:var/opt/mssql/data/<file name> -c <serviceName> -n <namespaceName>

Przykład

kubectl cp /home/WideWorldImporters-Full.bak sql2-1:var/opt/mssql/data/WideWorldImporters-Full.bak -c arc-sqlmi -n arc

Przywróć plik kopii zapasowej bazy danych, uruchamiając poniższe polecenie.

RESTORE DATABASE test FROM DISK = '/var/opt/mssql/data/<file name>.bak'
WITH MOVE '<database name>' to '/var/opt/mssql/data/<file name>.mdf'  
,MOVE '<database name>' to '/var/opt/mssql/data/<file name>_log.ldf'  
,RECOVERY, REPLACE, STATS = 5;  
GO

Przykład

RESTORE Database WideWorldImporters
FROM DISK = '/var/opt/mssql/data/WideWorldImporters-Full.BAK'
WITH
MOVE 'WWI_Primary' TO '/var/opt/mssql/data/WideWorldImporters.mdf',
MOVE 'WWI_UserData' TO '/var/opt/mssql/data/WideWorldImporters_UserData.ndf',
MOVE 'WWI_Log' TO '/var/opt/mssql/data/WideWorldImporters.ldf',
MOVE 'WWI_InMemory_Data_1' TO '/var/opt/mssql/data/WideWorldImporters_InMemory_Data_1',
RECOVERY, REPLACE, STATS = 5;  
GO

Dodaj bazę danych do grupy dostępności.

Aby baza danych została dodana do grupy dostępności, musi działać w trybie pełnego odzyskiwania i należy wykonać kopię zapasową dziennika. Uruchom poniższe instrukcje TSQL, aby dodać przywróconą bazę danych do grupy dostępności.
```
ALTER DATABASE <databaseName> SET RECOVERY FULL;
BACKUP DATABASE <databaseName> TO DISK='<filePath>'
ALTER AVAILABILITY GROUP containedag ADD DATABASE <databaseName>
```
Poniższy przykład dodaje bazę danych o nazwie WideWorldImporters , która została przywrócona w wystąpieniu:
```
ALTER DATABASE WideWorldImporters SET RECOVERY FULL;
BACKUP DATABASE WideWorldImporters TO DISK='/var/opt/mssql/data/WideWorldImporters.bak'
ALTER AVAILABILITY GROUP containedag ADD DATABASE WideWorldImporters
```

Ważne

Najlepszym rozwiązaniem jest usunięcie usługi Kubernetes utworzonej powyżej, uruchamiając następujące polecenie:

kubectl delete svc sql2-0-p -n arc

Ograniczenia

Instancja zarządzana SQL włączona przez grupy dostępności Azure Arc ma takie same ograniczenia jak grupy dostępności klastra Big Data. Aby uzyskać więcej informacji, zobacz Wdrażanie klastra danych big data programu SQL Server o wysokiej dostępności.

Dowiedz się więcej o funkcjach i możliwościach usługi SQL Managed Instance włączonej przez usługę Azure Arc

Sprzężenie zwrotne

Czy ta strona była pomocna?

Last updated on 2025-04-08

Udostępnij przez

Wysoka dostępność z usługą SQL Managed Instance włączoną przez usługę Azure Arc

Wysoka dostępność w warstwie usługi ogólnego przeznaczenia

Sprawdź wbudowaną wysoką dostępność

Wymagania wstępne

Wysoka dostępność w warstwie usługi Krytyczne dla działania firmy

Ograniczone grupy dostępności

Wdrażanie instancji SQL Managed Instance obsługiwanej przez Azure Arc z wieloma replikami przy użyciu portalu Azure

Wdrażanie wielu replik za pomocą Azure CLI

Wyświetlanie i monitorowanie stanu wysokiej dostępności

Uzyskaj podstawowe i pomocnicze punkty końcowe oraz status AG

Scenariusze trybu failover

Preferowana replika podstawowa

Przywracanie bazy danych do wystąpienia z wieloma replikami

Ograniczenia

Powiązana zawartość

Sprzężenie zwrotne

Dodatkowe źródła