Vysoká dostupnost se službou SQL Managed Instance povolenou službou Azure Arc

Spravovaná instance SQL povolená službou Azure Arc je nasazená v Kubernetes jako kontejnerizovaná aplikace. Používá konstrukty Kubernetes, jako jsou stavové sady a trvalé úložiště, aby poskytl zabudovanou funkcionalitu.

Monitorování stavu
Detekce poruch
Automatické přepnutí při selhání pro udržení zdraví služby.

Kvůli vyšší spolehlivosti můžete také nakonfigurovat službu SQL Managed Instance povolenou službou Azure Arc tak, aby se nasadila s dalšími replikami v konfiguraci s vysokou dostupností. Kontroler dat datových služeb Arc spravuje:

Sledování
Detekce poruch
Automatické přepnutí při selhání

Datová služba s podporou arc poskytuje tuto službu bez zásahu uživatele. Služba:

Nastaví skupinu dostupnosti.
Konfigurace koncových bodů zrcadlení databáze
Přidá databáze do skupiny dostupnosti.
Koordinuje přepínání při selhání a aktualizaci.

Tento dokument zkoumá oba typy vysoké dostupnosti.

Spravovaná instance SQL povolená službou Azure Arc poskytuje různé úrovně vysoké dostupnosti v závislosti na tom, jestli byla spravovaná instance SQL nasazená jako úroveň služby pro obecné účely nebo Pro důležité obchodní informace úroveň služby.

Vysoká dostupnost na úrovni služby Pro obecné účely

Na úrovni služby Pro obecné účely je k dispozici pouze jedna replika a vysoká dostupnost je zajištěna prostřednictvím orchestrace Kubernetes. Pokud například dojde k chybě podu nebo uzlu obsahujících kontejnerový image spravované instance, Kubernetes se pokusí vytvořit jiný pod nebo uzel a připojit ho ke stejnému trvalému úložišti. Během této doby není spravovaná instance SQL pro aplikace dostupná. Aplikace se musí znovu připojit a opakovat transakci, když je nový pod spuštěný. Pokud se používá typ služby load balancer, můžou se aplikace znovu připojit ke stejnému primárnímu koncovému bodu a Kubernetes přesměruje připojení na nový primární. Pokud je nodeport typ služby, aplikace se budou muset znovu připojit k nové IP adrese.

Ověřte integrovanou vysokou dostupnost

Pokud chcete ověřit vestavěnou vysokou dostupnost poskytovanou Kubernetes, můžete:

Odstranění podu existující spravované instance
Ověřte, že se Kubernetes z této akce obnoví.

Během obnovení kubernetes spustí další pod a připojí trvalé úložiště.

Požadavky

Cluster Kubernetes vyžaduje sdílené vzdálené úložiště.
Spravovaná instance SQL povolená službou Azure Arc nasazenou s jednou replikou (výchozí)

Prohlédněte si pody.

kubectl get pods -n <namespace of data controller>

Odstraňte pod spravované instance.

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

Například

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

Prohlédněte si pody a ověřte, že se spravovaná instance obnovuje.

kubectl get pods -n <namespace of data controller>

Příklad:

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

Po obnovení všech kontejnerů v podu se můžete připojit ke spravované instanci.

Vysoká dostupnost v úrovni služby Kritické pro podnikání

Na úrovni služby Pro důležité obchodní informace, kromě toho, co je nativně poskytováno orchestrací Kubernetes, poskytuje spravovaná instance SQL pro Azure Arc uzavřenou skupinu dostupnosti. Skupina dostupnosti obsažená je založená na technologii SQL Server AlwaysOn. Poskytuje vyšší úroveň dostupnosti. Spravovanou instanci SQL, povolenou službou Azure Arc a nasazenou s vrstvou služby Pro kritické podnikové aplikace, lze nasadit se 2 nebo 3 replikami. Tyto repliky se vždy synchronizují s ostatními.

Pro aplikaci jsou ve skupinách dostupnosti s omezeným obsahem veškeré chyby podů nebo selhání uzlů transparentní. Skupina dostupnosti obsahuje alespoň jeden další pod, který obsahuje všechna data z primárního serveru a je připravená na připojení.

Izolované skupiny dostupnosti

Skupina dostupnosti spojí jednu nebo více uživatelských databází do logické skupiny, aby v případě převzetí služeb při selhání celá skupina databází přesunula na sekundární repliku jako jednotný celek. Skupina dostupnosti replikuje data pouze v uživatelských databázích, ale ne v systémových databázích, jako jsou přihlášení, oprávnění nebo úlohy agenta. Obsahová skupina dostupnosti zahrnuje metadata ze systémových databází, jako jsou databáze msdb a master. Když se v primární replice vytvoří nebo upraví přihlášení, automaticky se vytvoří také v sekundárních replikách. Podobně při vytvoření nebo úpravě úlohy agenta v primární replice obdrží tyto změny také sekundární repliky.

Služba SQL Managed Instance povolená službou Azure Arc využívá tento koncept skupiny dostupnosti a přidává operátora Kubernetes, aby je bylo možné nasadit a spravovat ve velkém měřítku.

Možnosti, které obsahují skupiny dostupnosti, umožňují:

Při nasazení s více replikami se vytvoří jedna skupina dostupnosti se stejným názvem jako spravovaná instance SQL s podporou Arc. Ve výchozím nastavení má uzavřená skupina dostupnosti tři repliky, včetně primární. Všechny operace CRUD pro skupinu dostupnosti se spravují interně, včetně vytvoření skupiny dostupnosti nebo připojení replik k vytvořené skupině dostupnosti. V instanci nemůžete vytvářet další skupiny dostupnosti.
Všechny databáze se automaticky přidají do skupiny dostupnosti, včetně všech uživatelských a systémových databází, jako master a msdb. Tato funkce poskytuje jednotné zobrazení všech replik skupiny dostupnosti. Pokud se připojujete přímo k instanci, všimněte si obou databází containedag_master a containedag_msdb. Databáze containedag_* představují master a msdb uvnitř skupiny dostupnosti.
Externí koncový bod se automaticky zřizuje pro připojení k databázím v rámci skupiny dostupnosti. Tento koncový bod <managed_instance_name>-external-svc plní roli naslouchací služby skupiny dostupnosti.

Nasazení služby SQL Managed Instance povolené službou Azure Arc s více replikami pomocí webu Azure Portal

Na webu Azure Portal na stránce Vytvořit spravovanou instanci SQL povolenou službou Azure Arc:

V části Výpočty a úložiště vyberte Konfigurovat výpočetní prostředky a úložiště . Portál zobrazuje upřesňující nastavení.
V části Úroveň služby vyberte Business Critical.
Zaškrtněte políčko "Pouze pro použití při vývoji", pokud používáte pro účely vývoje.
V části Vysoká dostupnost vyberte buď 2 repliky , nebo 3 repliky.

Nastavení vysoké dostupnosti

Nasazení s několika replikami pomocí Azure CLI

Když je spravovaná instance SQL povolená pomocí Azure Arc nasazená v úrovni služeb Klíčové pro podnikání, nasazení vytvoří více replik. Nastavení a konfigurace skupin dostupnosti obsažených mezi těmito instancemi se během zřizování provádí automaticky.

Například následující příkaz vytvoří spravovanou instanci se 3 replikami.

Nepřímo připojený režim:

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

Příklad:

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

Přímo připojený režim:

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>

Příklad:

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

Ve výchozím nastavení jsou všechny repliky nakonfigurované v synchronním režimu. To znamená, že všechny aktualizace primární instance se synchronně replikují do každé sekundární instance.

Zobrazení a monitorování stavu vysoké dostupnosti

Po dokončení nasazení se z aplikace SQL Server Management Studio připojte k primárnímu koncovému bodu.

Ověřte a načtěte koncový bod primární repliky a připojte se k němu ze sady SQL Server Management Studio. Například pokud byla instance SQL nasazena pomocí service-type=loadbalancer, spusťte následující příkaz k načtení koncového bodu, ke kterému se chcete připojit:

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

nebo

kubectl get sqlmi -A

Získejte primární a sekundární koncové body a stav AG

kubectl describe sqlmi Pomocí příkazů az sql mi-arc show můžete zobrazit primární a sekundární koncové body a stav vysoké dostupnosti.

Příklad:

kubectl describe sqlmi sqldemo -n my-namespace

nebo

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

Příklad výstupu bude jiný:

 "status": {
    "endpoints": {...
      "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"
  }

Pomocí SQL Server Management Studio se můžete připojit k primárnímu koncovému bodu a ověřit dynamické pohledy správy, jako jsou:

SELECT * FROM sys.dm_hadr_availability_replica_states

Skupina dostupnosti

Řídicí panel omezené dostupnosti

Řídicí panel skupiny dostupnosti kontejneru

Scénáře havarijního převzetí služeb

Na rozdíl od skupin dostupnosti Always On SQL Serveru je samostatná skupina dostupnosti spravovaným řešením s vysokou dostupností. Režimy převzetí služeb při selhání jsou proto omezené v porovnání s typickými režimy dostupnými u skupin dostupnosti AlwaysOn SQL Serveru.

Nasaďte spravované instance SQL úrovně služby Business Critical v konfiguraci dvou nebo tří replik. Účinky selhání a následná obnovitelnost se u každé konfigurace liší. Tři instance repliky poskytují vyšší úroveň dostupnosti a obnovení než dvě instance repliky.

V konfiguraci dvou replik, pokud jsou oba uzly SYNCHRONIZED, a primární replika přestane být k dispozici, sekundární replika je automaticky povýšena na primární. Jakmile bude replika, která selhala, k dispozici, bude aktualizována o všechny čekající změny. Pokud mezi replikami dojde k problémům s připojením, nemusí primární replika potvrdit žádné transakce, protože každá transakce musí být potvrzena na obou replikách, než se vrátí úspěch na primárním serveru.

V konfiguraci tří replik musí transakce potvrdit alespoň ve 2 ze 3 replik před vrácením zprávy o úspěchu zpět do aplikace. V případě selhání je jedna ze sekundárních replik automaticky povýšena na primární, zatímco Kubernetes se pokusí obnovit selhalou repliku. Jakmile bude replika dostupná, automaticky se připojí zpět k obsažené skupině dostupnosti a čekající změny se synchronizují. Pokud dochází k problémům s připojením mezi replikami a více než 2 repliky nejsou synchronizované, primární replika nebude provádět žádné transakce.

Poznámka:

Doporučuje se nasadit SQL Managed Instance s obchodní důležitostí ve konfiguraci se třemi replikami než ve dvou replikách, aby se dosáhlo téměř nulové ztráty dat.

Pokud chcete převzít služby při selhání z primární repliky na jeden z sekundárních objektů, spusťte pro plánovanou událost následující příkaz:

Pokud se připojujete k primárnímu serveru, můžete pomocí následujícího jazyka T-SQL převzít služby při selhání instance SQL na jeden z sekundárních souborů:

ALTER AVAILABILITY GROUP current SET (ROLE = SECONDARY);

Pokud se připojíte k sekundární, můžete pomocí následujícího příkazu T-SQL zvýšit úroveň požadované sekundární na primární repliku.

ALTER AVAILABILITY GROUP current SET (ROLE = PRIMARY);

Upřednostňovaná primární replika

Konkrétní repliku můžete také nastavit jako primární repliku pomocí AZ CLI následujícím způsobem:

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

Příklad:

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

Poznámka:

Kubernetes se pokusí nastavit preferovanou repliku, ale nelze to zaručit.

Obnovení databáze do instance s více replikou

Další kroky jsou potřeba k obnovení databáze do skupiny dostupnosti. Následující kroky ukazují, jak obnovit databázi do spravované instance a přidat ji do skupiny dostupnosti.

Zveřejněte externí koncový bod primární instance vytvořením nové služby Kubernetes.

Určete pod, který hostí primární repliku. Připojte se ke spravované instanci a spusťte:
```
SELECT @@SERVERNAME
```
Dotaz vrátí pod, který je hostitelem primární repliky.

Službu Kubernetes vytvořte do primární instance spuštěním následujícího příkazu, pokud váš cluster Kubernetes používá NodePort služby. Nahraďte <podName> názvem serveru vráceným v předchozím kroku <serviceName> upřednostňovaným názvem pro vytvořenou službu Kubernetes.
```
kubectl -n <namespaceName> expose pod <podName> --port=1533  --name=<serviceName> --type=NodePort
```
Pro službu LoadBalancer spusťte stejný příkaz s tím rozdílem, že typ vytvořené služby je LoadBalancer. Příklad:
```
kubectl -n <namespaceName> expose pod <podName> --port=1533  --name=<serviceName> --type=LoadBalancer
```
Tady je příklad spuštění tohoto příkazu ve službě Azure Kubernetes Service, kde pod sql2-0 hostuje primární pod.
```
kubectl -n arc-cluster expose pod sql2-0 --port=1533  --name=sql2-0-p --type=LoadBalancer
```
Získejte IP adresu vytvořené služby Kubernetes:
```
kubectl get services -n <namespaceName>
```

Obnovte databázi do koncového bodu primární instance.

Přidejte záložní soubor databáze do kontejneru primární instance.

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

Příklad

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

Obnovte záložní soubor databáze spuštěním následujícího příkazu.

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

Příklad

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

Přidejte databázi do skupiny dostupnosti.

Aby se databáze přidala do skupiny dostupnosti, musí běžet v režimu úplného obnovení a musí být provedena záloha protokolu. Spuštěním níže uvedených příkazů TSQL přidejte obnovenou databázi do skupiny dostupnosti.
```
ALTER DATABASE <databaseName> SET RECOVERY FULL;
BACKUP DATABASE <databaseName> TO DISK='<filePath>'
ALTER AVAILABILITY GROUP containedag ADD DATABASE <databaseName>
```
Následující příklad přidá databázi s názvem WideWorldImporters , která byla obnovena v instanci:
```
ALTER DATABASE WideWorldImporters SET RECOVERY FULL;
BACKUP DATABASE WideWorldImporters TO DISK='/var/opt/mssql/data/WideWorldImporters.bak'
ALTER AVAILABILITY GROUP containedag ADD DATABASE WideWorldImporters
```

Důležité

Osvědčeným postupem je odstranit službu Kubernetes vytvořenou výše spuštěním tohoto příkazu:

kubectl delete svc sql2-0-p -n arc

Omezení

Spravovaná instance SQL povolená skupinami dostupnosti Azure Arc má stejná omezení jako skupiny dostupnosti clusteru s velkými objemy dat. Další informace najdete v tématu Nasazení clusteru s velkými objemy dat SQL Serveru s vysokou dostupností.

Další informace o funkcích a možnostech služby SQL Managed Instance povolené službou Azure Arc

Váš názor

Byla tato stránka užitečná?

Last updated on 2025-04-11

Vysoká dostupnost se službou SQL Managed Instance povolenou službou Azure Arc

Vysoká dostupnost na úrovni služby Pro obecné účely

Ověřte integrovanou vysokou dostupnost

Požadavky

Vysoká dostupnost v úrovni služby Kritické pro podnikání

Izolované skupiny dostupnosti

Nasazení služby SQL Managed Instance povolené službou Azure Arc s více replikami pomocí webu Azure Portal

Nasazení s několika replikami pomocí Azure CLI

Zobrazení a monitorování stavu vysoké dostupnosti

Získejte primární a sekundární koncové body a stav AG

Scénáře havarijního převzetí služeb

Upřednostňovaná primární replika

Obnovení databáze do instance s více replikou

Omezení

Související obsah

Váš názor

Další materiály