Delen via

Failovergroep configureren - CLI

  • Artikel

In dit artikel wordt uitgelegd hoe u herstel na noodgevallen configureert voor SQL Managed Instance die is ingeschakeld door Azure Arc met de CLI. Voordat u verdergaat, bekijkt u de informatie en vereisten in SQL Managed Instance die is ingeschakeld door Azure Arc: herstel na noodgevallen.

Vereisten

Aan de volgende vereisten moet worden voldaan voordat u failovergroepen instelt tussen twee exemplaren van SQL Managed Instance waarvoor Azure Arc is ingeschakeld:

  • Een Azure Arc-gegevenscontroller en een met SQL beheerd exemplaar met Arc dat is ingericht op de primaire site met --license-type als een van BasePrice of LicenseIncluded.
  • Een Azure Arc-gegevenscontroller en een met SQL beheerd exemplaar met Arc dat is ingericht op de secundaire site met een identieke configuratie als de primaire in termen van:
    • CPU
    • Geheugen
    • Storage
    • Servicelaag
    • Sortering
    • Andere instantie-instellingen
  • Het exemplaar op de secundaire site vereist --license-type als DisasterRecovery. Dit exemplaar moet nieuw zijn, zonder gebruikersobjecten.

Notitie

  • Het is belangrijk om de --license-type waarde op te geven tijdens het maken van het beheerde exemplaar. Hierdoor kan het DR-exemplaar worden geseed van het primaire exemplaar in het primaire datacenter. Het bijwerken van deze eigenschap na de implementatie heeft niet hetzelfde effect.

Implementatieproces

Voer de volgende stappen uit om een Azure-failovergroep tussen twee exemplaren in te stellen:

  1. Aangepaste resource maken voor gedistribueerde beschikbaarheidsgroep op de primaire site
  2. Aangepaste resource maken voor gedistribueerde beschikbaarheidsgroep op de secundaire site
  3. De binaire gegevens uit de spiegelingscertificaten kopiëren
  4. De gedistribueerde beschikbaarheidsgroep instellen tussen de primaire en secundaire sites in sync de modus of async modus

In de volgende afbeelding ziet u een correct geconfigureerde gedistribueerde beschikbaarheidsgroep:

Diagram met een correct geconfigureerde gedistribueerde beschikbaarheidsgroep.

Synchronisatiemodi

Failovergroepen in Azure Arc-gegevensservices ondersteunen twee synchronisatiemodi: sync en async. De synchronisatiemodus heeft rechtstreeks invloed op de manier waarop de gegevens worden gesynchroniseerd tussen de exemplaren en mogelijk de prestaties op het primaire beheerde exemplaar.

Als primaire en secundaire sites zich binnen een paar kilometer van elkaar bevinden, gebruikt u sync de modus. async Gebruik anders de modus om prestatie-impact op de primaire site te voorkomen.

Azure-failovergroep configureren - directe modus

Volg de onderstaande stappen als de Azure Arc-gegevensservices zijn geïmplementeerd in directly de verbonden modus.

Zodra aan de vereisten is voldaan, voert u de onderstaande opdracht uit om een Azure-failovergroep in te stellen tussen de twee exemplaren:

az sql instance-failover-group-arc create --name <name of failover group> --mi <primary SQL MI> --partner-mi <Partner MI> --resource-group <name of RG> --partner-resource-group <name of partner MI RG>

Voorbeeld:

az sql instance-failover-group-arc create --name sql-fog --mi sql1 --partner-mi sql2 --resource-group rg-name --partner-resource-group rg-name

De bovenstaande opdracht:

  • Hiermee maakt u de vereiste aangepaste resources op zowel primaire als secundaire sites
  • Kopieert de spiegelingscertificaten en configureert de failovergroep tussen de exemplaren

Azure-failovergroep configureren - indirecte modus

Volg de onderstaande stappen als Azure Arc-gegevensservices zijn geïmplementeerd in indirectly de verbonden modus.

  1. Richt het beheerde exemplaar in op de primaire site.

    az sql mi-arc create --name <primaryinstance> --tier bc --replicas 3 --k8s-namespace <namespace> --use-k8s

  2. Schakel de context over naar het secundaire cluster door het beheerde exemplaar uit te voeren kubectl config use-context <secondarycluster> en in te richten op de secundaire site. Dit is het noodherstelexemplaren. Op dit moment maken de systeemdatabases geen deel uit van de ingesloten beschikbaarheidsgroep.

    Notitie

    Het is belangrijk om op te geven --license-type DisasterRecovery tijdens het beheerde exemplaar. Hierdoor kan het DR-exemplaar worden geseed van het primaire exemplaar in het primaire datacenter. Het bijwerken van deze eigenschap na de implementatie heeft niet hetzelfde effect.

    az sql mi-arc create --name <secondaryinstance> --tier bc --replicas 3 --license-type DisasterRecovery --k8s-namespace <namespace> --use-k8s

  3. Certificaten spiegelen: de binaire gegevens in de eigenschap Mirroring Certificate van het beheerde exemplaar zijn nodig voor het maken van de instantiefailovergroep CR (aangepaste resource).

    Dit kan op een aantal manieren worden bereikt:

    (a) Als u CLI gebruikt az , genereert u eerst het spiegelingscertificaatbestand en wijst u dit bestand aan tijdens het configureren van de failovergroep van het exemplaar, zodat de binaire gegevens worden gelezen uit het bestand en worden gekopieerd naar de CR. De certificaatbestanden zijn niet nodig nadat de failovergroep is gemaakt.

    (b) Als u kubectlde binaire gegevens van het beheerde exemplaar CR rechtstreeks kopieert en plakt in het yaml-bestand dat wordt gebruikt voor het maken van de exemplaarfailovergroep.

    Gebruik (a) hierboven:

    Maak het certificaatbestand voor spiegeling voor het primaire exemplaar:

    az sql mi-arc get-mirroring-cert --name <primaryinstance> --cert-file </path/name>.pem​ --k8s-namespace <namespace> --use-k8s

    Voorbeeld:

    az sql mi-arc get-mirroring-cert --name sqlprimary --cert-file $HOME/sqlcerts/sqlprimary.pem​ --k8s-namespace my-namespace --use-k8s

    Maak verbinding met het secundaire cluster en maak het mirroring-certificaatbestand voor het secundaire exemplaar:

    az sql mi-arc get-mirroring-cert --name <secondaryinstance> --cert-file </path/name>.pem --k8s-namespace <namespace> --use-k8s

    Voorbeeld:

    az sql mi-arc get-mirroring-cert --name sqlsecondary --cert-file $HOME/sqlcerts/sqlsecondary.pem --k8s-namespace my-namespace --use-k8s

    Zodra de gespiegelde certificaatbestanden zijn gemaakt, kopieert u het certificaat van het secundaire exemplaar naar een gedeeld/lokaal pad op het primaire exemplaarcluster en vice versa.

  4. Maak de resource van de failovergroep op beide sites.

    Notitie

    Zorg ervoor dat de SQL-exemplaren verschillende namen hebben voor zowel primaire als secundaire sites. De shared-name waarde moet identiek zijn op beide sites.

    az sql instance-failover-group-arc create --shared-name <name of failover group> --name <name for primary failover group resource> --mi <local SQL managed instance name> --role primary --partner-mi <partner SQL managed instance name>  --partner-mirroring-url tcp://<secondary IP> --partner-mirroring-cert-file <secondary.pem> --k8s-namespace <namespace> --use-k8s

    Voorbeeld:

    az sql instance-failover-group-arc create --shared-name myfog --name primarycr --mi sqlinstance1 --role primary --partner-mi sqlinstance2  --partner-mirroring-url tcp://10.20.5.20:970 --partner-mirroring-cert-file $HOME/sqlcerts/sqlinstance2.pem --k8s-namespace my-namespace --use-k8s

    Voer op het secundaire exemplaar de volgende opdracht uit om de aangepaste resource van de failovergroep in te stellen. De --partner-mirroring-cert-file in dit geval moet verwijzen naar een pad met het gespiegelde certificaatbestand dat is gegenereerd op basis van het primaire exemplaar, zoals beschreven in 3(a) hierboven.

    az sql instance-failover-group-arc create --shared-name <name of failover group> --name <name for secondary failover group resource> --mi <local SQL managed instance name> --role secondary --partner-mi <partner SQL managed instance name>  --partner-mirroring-url tcp://<primary IP> --partner-mirroring-cert-file <primary.pem> --k8s-namespace <namespace> --use-k8s

    Voorbeeld:

    az sql instance-failover-group-arc create --shared-name myfog --name secondarycr --mi sqlinstance2 --role secondary --partner-mi sqlinstance1  --partner-mirroring-url tcp://10.10.5.20:970 --partner-mirroring-cert-file $HOME/sqlcerts/sqlinstance1.pem --k8s-namespace my-namespace --use-k8s

Status van Azure-failovergroep ophalen

Informatie over de failovergroep, zoals primaire rol, secundaire rol en de huidige status, kan worden weergegeven in de aangepaste resource op de primaire of secundaire site.

Voer de onderstaande opdracht uit op de primaire en/of secundaire site om de aangepaste resource voor failovergroepen weer te geven:

kubectl get fog -n <namespace>

Beschrijf de aangepaste resource om de status van de failovergroep op te halen, als volgt:

kubectl describe fog <failover group cr name> -n <namespace>

Bewerkingen voor failovergroep

Zodra de failovergroep is ingesteld tussen de beheerde exemplaren, kunnen verschillende failoverbewerkingen worden uitgevoerd, afhankelijk van de omstandigheden.

Mogelijke failoverscenario's zijn:

  • De exemplaren op beide sites hebben de status In orde en er moet een failover worden uitgevoerd:

    • voer een handmatige failover uit van primair naar secundair zonder gegevensverlies door de instelling op de primaire SQL MI in te stellen role=secondary .

  • Primaire site is beschadigd/onbereikbaar en er moet een failover worden uitgevoerd:

    • het primaire met SQL beheerde exemplaar dat is ingeschakeld door Azure Arc, is niet in orde/niet bereikbaar
    • het secundaire met SQL beheerde exemplaar dat door Azure Arc is ingeschakeld, moet worden gepromoveerd naar primair met mogelijk gegevensverlies
    • wanneer het oorspronkelijke primaire SQL Managed Instance dat is ingeschakeld door Azure Arc weer online komt, wordt deze als rol- en beschadigde status weergegeven Primary en moet deze worden gedwongen tot een secondary rol, zodat deze lid kan worden van de failovergroep en gegevens kunnen worden gesynchroniseerd.

Handmatige failover (zonder gegevensverlies)

Gebruik az sql instance-failover-group-arc update ... de opdrachtgroep om een failover van primair naar secundair te initiëren. Alle transacties die in behandeling zijn op het geo-primaire exemplaar, worden gerepliceerd naar het geo-secundaire exemplaar vóór de failover.

Direct verbonden modus

Voer de volgende opdracht uit om een handmatige failover te starten in direct de verbonden modus met behulp van ARM-API's:

az sql instance-failover-group-arc update --name <shared name of failover group> --mi <primary instance> --role secondary --resource-group <resource group>

Voorbeeld:

az sql instance-failover-group-arc update --name myfog --mi sqlmi1 --role secondary --resource-group myresourcegroup

Indirect verbonden modus

Voer de volgende opdracht uit om een handmatige failover te starten in indirect de verbonden modus met behulp van kubernetes-API's:

az sql instance-failover-group-arc update --name <name of failover group resource> --role secondary --k8s-namespace <namespace> --use-k8s

Voorbeeld:

az sql instance-failover-group-arc update --name myfog --role secondary --k8s-namespace my-namespace --use-k8s

Geforceerde failover met gegevensverlies

In het geval dat het geo-primaire exemplaar niet beschikbaar is, kunnen de volgende opdrachten worden uitgevoerd op het geo-secundaire DR-exemplaar om te promoveren naar primair met een geforceerde failover die mogelijk gegevensverlies veroorzaakt.

Voer op het geo-secundaire DR-exemplaar de volgende opdracht uit om deze te promoveren naar de primaire rol, met gegevensverlies.

Notitie

Als de --partner-sync-mode configuratie als zodanig is geconfigureerd, moet deze opnieuw worden ingesteld op async het moment dat de secundaire wordt gepromoveerd syncnaar primair.

Direct verbonden modus

az sql instance-failover-group-arc update --name <shared name of failover group> --mi <instance> --role force-primary-allow-data-loss --resource-group <resource group> --partner-sync-mode async

Voorbeeld:

az sql instance-failover-group-arc update --name myfog --mi sqlmi2 --role force-primary-allow-data-loss --resource-group myresourcegroup --partner-sync-mode async

Indirect verbonden modus

az sql instance-failover-group-arc update --k8s-namespace my-namespace --name secondarycr --use-k8s --role force-primary-allow-data-loss --partner-sync-mode async

Wanneer het geo-primaire exemplaar beschikbaar is, voert u de onderstaande opdracht uit om deze in de failovergroep te zetten en de gegevens te synchroniseren:

Direct verbonden modus

az sql instance-failover-group-arc update --name <shared name of failover group> --mi <old primary instance> --role force-secondary --resource-group <resource group>

Indirect verbonden modus

az sql instance-failover-group-arc update --k8s-namespace my-namespace --name secondarycr --use-k8s --role force-secondary

Desgewenst kunt u de --partner-sync-mode modus weer sync configureren.

Bewerkingen na failover

Zodra u een failover uitvoert van de primaire site naar de secundaire site, met of zonder gegevensverlies, moet u mogelijk het volgende doen:

  • Werk de verbindingsreeks voor uw toepassingen bij om verbinding te maken met het zojuist gepromoveerde primaire beheerde Arc SQL-exemplaar
  • Als u van plan bent om de productieworkload van de secundaire site te blijven uitvoeren, werkt u de --license-type workload bij naar BasePrice of LicenseIncluded start u de facturering voor de verbruikte vCores.

Gerelateerde inhoud