Overzicht van failovergroepen & best practices - Azure SQL Managed Instance

van toepassing op:Azure SQL Managed Instance

Dit artikel bevat een overzicht van de functie failovergroep met aanbevolen procedures en aanbevelingen voor gebruik met Azure SQL Managed Instance. Met de functie failovergroepen kunt u de replicatie en failover van alle gebruikersdatabases in een met SQL beheerd exemplaar naar een andere Azure-regio beheren.

Raadpleeg Een failovergroep configureren voor Azure SQL Managed Instance om aan de slag te gaan.

Overzicht

Met de functie failovergroepen kunt u de replicatie en failover van gebruikersdatabases van het ene beheerde SQL-exemplaar naar een ander met SQL beheerd exemplaar in een andere Azure-regio beheren. Failovergroepen zijn ontworpen om de implementatie en het beheer van geo-gerepliceerde databases op schaal te vereenvoudigen.

Zie Hoge beschikbaarheid voor Azure SQL Managed Instancevoor meer informatie. Zie overzicht van bedrijfscontinuïteitvoor geografische failover-RPO en RTO.

Eindpunt redirectie

Failovergroepen bieden alleen-lezen-schrijven- en alleen-lezen-listener-eindpunten die ongewijzigd blijven tijdens geo-failovers. U hoeft de verbindingsreeks voor uw toepassing niet te wijzigen na een geo-failover, omdat verbindingen automatisch worden gerouteerd naar de huidige primaire. Met een geo-failover worden alle secundaire databases in de groep overgeschakeld naar de primaire rol. Nadat geo-failover is voltooid, wordt de DNS-record automatisch bijgewerkt om de eindpunten om te leiden naar de nieuwe regio.

Alleen-lezen workloads uitbesteden

Als u het verkeer naar uw primaire databases wilt verminderen, kunt u ook de secundaire databases in een failovergroep gebruiken om leesverkeer af te handelen. Gebruik de alleen lezen-luisteraar om alleen-lezen verkeer naar een leesbare secundaire database te leiden.

Een toepassing herstellen

Voor een volledige bedrijfscontinuïteit maakt het toevoegen van regionale databaseredundantie slechts deel uit van de oplossing. Als u een toepassing (service) end-to-end herstelt na een onherstelbare fout, moet u alle onderdelen herstellen die de service en afhankelijke services vormen. Voorbeelden van deze onderdelen zijn de clientsoftware (bijvoorbeeld een browser met een aangepast JavaScript), webfront-ends, opslag en DNS. Het is essentieel dat alle onderdelen bestand zijn tegen dezelfde fouten en beschikbaar zijn binnen de beoogde hersteltijd (RTO) van uw toepassing. Daarom moet u alle afhankelijke services identificeren en inzicht hebben in de garanties en mogelijkheden die ze bieden. Vervolgens moet u voldoende stappen ondernemen om ervoor te zorgen dat uw service functioneert tijdens de failover van de services waarvan deze afhankelijk is.

Failoverbeleid

Failovergroepen ondersteunen twee failoverbeleidsregels:

• door de klant beheerde (aanbevolen) : klanten kunnen een failover van een groep uitvoeren wanneer ze een onverwachte storing merken die van invloed is op een of meer databases in de failovergroep. Wanneer u opdrachtregelprogramma's zoals PowerShell, de Azure CLI of de Rest API gebruikt, is de waarde voor het failoverbeleid voor door de klant beheerde manual.
• Microsoft managed : in het geval van een wijdverspreide storing die van invloed is op een primaire regio, start Microsoft failover van alle betrokken failovergroepen waarvoor hun failoverbeleid is geconfigureerd om door Microsoft te worden beheerd. Door Microsoft beheerde failover wordt niet geïnitieerd voor afzonderlijke failovergroepen of een subset van failovergroepen in een regio. Wanneer u opdrachtregelprogramma's zoals PowerShell, de Azure CLI of de REST API gebruikt, is de waarde voor het failoverbeleid bij beheer door Microsoft automatic.

Elk failoverbeleid heeft een unieke set gebruiksvoorbeelden en bijbehorende verwachtingen voor het failoverbereik en gegevensverlies, zoals in de volgende tabel wordt samengevat:

Door de klant beheerd

In zeldzame gevallen is de ingebouwde beschikbaarheid of hoge beschikbaarheid niet voldoende om een storing te beperken en zijn uw databases in een failovergroep mogelijk niet beschikbaar gedurende een periode die niet acceptabel is voor de SERVICE Level Agreement (SLA) van de toepassingen die gebruikmaken van de databases. Databases kunnen niet beschikbaar zijn vanwege een gelokaliseerd probleem dat van invloed is op slechts een paar databases, of het kan zich op datacenter-, beschikbaarheidszone- of regioniveau bevinden. In elk van deze gevallen kunt u een geforceerde failover initiëren om bedrijfscontinuïteit te herstellen.

Het instellen van uw failoverbeleid op klantbeheer wordt ten zeerste aanbevolen, omdat u zelf bepaalt wanneer u een failover start en de bedrijfscontinuïteit herstelt. U kunt een failover initiëren wanneer er een onverwachte storing optreedt die van invloed is op een of meer databases in de failovergroep.

Door Microsoft beheerd

Met een door Microsoft beheerd failoverbeleid wordt de verantwoordelijkheid voor herstel na noodgevallen gedelegeerd aan de Azure SQL-service. Voordat de Azure SQL-service een geforceerde failover kan starten, moet aan de volgende voorwaarden worden voldaan:

• Storing op regioniveau veroorzaakt door een natuurramp, configuratiewijzigingen, softwarefouten of hardwareonderdelenfouten en veel databases in de regio worden beïnvloed.
• Respijtperiode is verlopen. Omdat het beoordelen van de omvang van en het beperken van de storing afhankelijk is van menselijke acties, kan de respijtperiode niet onder één uur worden ingesteld.

Wanneer aan deze voorwaarden wordt voldaan, initieert de Azure SQL-service geforceerde failovers voor alle failovergroepen in de regio waarvoor het failoverbeleid is ingesteld op Door Microsoft beheerd.

Stel het failoverbeleid alleen in op beheerd door Microsoft wanneer:

• U wilt de verantwoordelijkheid voor herstel na noodgevallen delegeren aan de Azure SQL-service.
• De toepassing is tolerant voor het feit dat uw database ten minste één uur of langer niet beschikbaar is.
• Het is acceptabel om geforceerde failovers enige tijd te activeren nadat de respijtperiode is verlopen, omdat de werkelijke tijd voor de geforceerde failover aanzienlijk kan variëren.
• Het is acceptabel dat alle databases binnen de failovergroep een failover-overschakeling uitvoeren, ongeacht hun zoneredundantieconfiguratie of beschikbaarheidsstatus. Hoewel databases die zijn geconfigureerd voor zoneredundantie bestand zijn tegen zonefouten en mogelijk niet worden beïnvloed door een storing, zullen er toch een failover plaatsvinden als ze deel uitmaken van een failovergroep met een door Microsoft beheerd failoverbeleid.
• Het is acceptabel om geforceerde failovers van databases in de failovergroep te hebben zonder rekening te houden met de afhankelijkheid van de toepassing op andere Azure-services of -onderdelen die door de toepassing worden gebruikt, wat kan leiden tot prestatievermindering of niet-beschikbaarheid van de toepassing.
• Het is acceptabel om een onbekende hoeveelheid gegevensverlies te veroorzaken, omdat de exacte tijd van geforceerde failover niet kan worden beheerd en de synchronisatiestatus van de secundaire databases wordt genegeerd.
• De primaire en secundaire replica's in de failovergroep hebben dezelfde servicelaag, rekenlaag en rekenkracht.

Wanneer een failover wordt geactiveerd door Microsoft, wordt een vermelding voor de naam van de bewerking Failover Azure SQL-failovergroep toegevoegd aan het Azure Monitor-activiteitenlogboek. De vermelding bevat de naam van de failovergroep onder Bron, en bij Evenement geïnitieerd door wordt een enkel koppelteken (-) weergegeven om aan te geven dat de failover is gestart door Microsoft. Deze informatie vindt u ook op de Activiteitlog pagina van de nieuwe primaire server of het nieuwe instantie in de Azure-portal.

Terminologie en mogelijkheden

• failovergroep (FOG)

  Met een failovergroep kunnen alle gebruikersdatabases in een beheerd SQL-exemplaar een failover uitvoeren als een eenheid naar een andere Azure-regio als het primaire beheerde SQL-exemplaar niet meer beschikbaar is vanwege een storing in de primaire regio. Omdat failovergroepen voor SQL Managed Instance alle gebruikersdatabases in het exemplaar bevatten, kan slechts één failovergroep worden geconfigureerd op een exemplaar.

  Belangrijk

  De naam van de failovergroep moet wereldwijd uniek zijn binnen het .database.windows.net domein.

• primaire

  Het beheerde SQL-exemplaar dat als host fungeert voor de primaire databases in de failovergroep.

• secundaire

  Het beheerde SQL-exemplaar dat als host fungeert voor de secundaire databases in de failovergroep. De secundaire kan zich niet in dezelfde Azure-regio bevinden als de primaire regio.

  Belangrijk

  Als een database OLTP-objecten in het geheugen bevat, moet het primaire en secundaire geo-replica-exemplaar overeenkomende servicelagen hebben, omdat OLTP-objecten in het geheugen zich bevinden. Een lagere servicelaag op het geo-replica-exemplaar kan leiden tot problemen met onvoldoende geheugen. Als dit gebeurt, kan de secundaire replica de database niet herstellen, waardoor de secundaire database niet beschikbaar is, samen met OLTP-objecten in het geheugen op de geo-secundaire locatie. Dit kan er op zijn beurt toe leiden dat de failover ook niet succesvol is. Om dit te voorkomen, moet u ervoor zorgen dat de servicelaag van het geo-secundaire exemplaar overeenkomt met die van de primaire database. Upgrades van de servicelaag kunnen operaties op basis van de grootte van de data zijn en het kan enige tijd duren om deze te voltooien.

• failover (geen gegevensverlies)

  Failover voert volledige gegevenssynchronisatie uit tussen primaire en secundaire databases voordat de secundaire overschakelt naar de primaire rol. Dit garandeert geen gegevensverlies. Failover is alleen mogelijk als het primaire systeem toegankelijk is. Failover wordt gebruikt in de volgende scenario's:

  • Voer DR-oefeningen uit in productie wanneer gegevensverlies onaanvaardbaar is
  • De workload verplaatsen naar een andere regio
  • Plaats de werklast terug naar de primaire regio nadat de storing is opgelost (failback)

• geforceerde failover (mogelijk gegevensverlies)

  Geforceerde failover schakelt de secundaire rol onmiddellijk over naar de primaire rol zonder te wachten tot recente wijzigingen vanuit de primaire rol zijn gepropageerd. Deze bewerking kan leiden tot mogelijk gegevensverlies. Geforceerde failover wordt gebruikt als herstelmethode tijdens storingen wanneer de primaire niet toegankelijk is. Wanneer de storing wordt verzacht, wordt de oude primaire verbinding automatisch opnieuw gemaakt en wordt het een nieuwe secundaire. Een failover kan worden uitgevoerd om het herstelproces te voltooien, waardoor de replica's terugkeren naar hun oorspronkelijke primaire en secundaire rollen.

• Overgangsperiode met gegevensverlies

  Omdat gegevens worden gerepliceerd naar de secundaire met behulp van asynchrone replicatie, kan geforceerde failover van groepen met door Microsoft beheerde failoverbeleid leiden tot gegevensverlies. U kunt het failoverbeleid aanpassen aan de tolerantie van uw toepassing voor gegevensverlies. Door GracePeriodWithDataLossHourste configureren, kunt u bepalen hoe lang de Azure SQL-service wacht voordat een geforceerde failover wordt gestart, wat kan leiden tot gegevensverlies.

• DNS-zone

  Een unieke ID die automatisch wordt gegenereerd wanneer een nieuwe SQL Managed Instance wordt gemaakt. Een SAN-certificaat (multi-domain) voor dit exemplaar wordt ingericht om de clientverbindingen met elk exemplaar in dezelfde DNS-zone te verifiëren. De twee beheerde SQL-exemplaren in dezelfde failovergroep moeten de DNS-zone delen.

• lees-/schrijflistener voor failovergroepen

  Een DNS CNAME-record die verwijst naar de huidige primaire record. Deze wordt automatisch aangemaakt wanneer de failovergroep wordt gemaakt en stelt de lees-schrijfbelasting in staat om transparant opnieuw verbinding te maken met de primaire server wanneer de primaire server verandert na een failover. Wanneer de failovergroep wordt gemaakt op een met SQL beheerd exemplaar, wordt de DNS CNAME-record voor de listener-URL gevormd als <fog-name>.<zone_id>.database.windows.net.

• alleen-lezen listener voor failovergroepen

  Een DNS CNAME-record die verwijst naar de huidige secundaire record. Deze wordt automatisch aangemaakt wanneer de failovergroep wordt gemaakt en stelt de alleen-lezen SQL-workload in staat om transparant verbinding te maken met de secundaire instantie wanneer deze na een failover verandert. Wanneer de failovergroep wordt gemaakt op een met SQL beheerd exemplaar, wordt de DNS CNAME-record voor de listener-URL gevormd als <fog-name>.secondary.<zone_id>.database.windows.net. Failover van de alleen-lezen-listener is standaard uitgeschakeld omdat dit ervoor zorgt dat de prestaties van de primaire functie niet worden beïnvloed wanneer de secundaire offline is. Dit betekent echter ook dat de alleen-lezensessies pas verbinding kunnen maken als de secundaire sessie is hersteld. Als u geen downtime voor de alleen-lezensessies kunt tolereren en de primaire server kunt gebruiken voor zowel alleen-lezen als lees- en schrijfverkeer ten koste van mogelijk prestatieverlies van de primaire server, kunt u failover inschakelen voor de alleen-lezen listener door de eigenschap AllowReadOnlyFailoverToPrimary te configureren. In dat geval wordt het alleen-lezen verkeer automatisch omgeleid naar de primaire server als de secundaire niet beschikbaar is.

  Notitie

  De eigenschap AllowReadOnlyFailoverToPrimary heeft alleen effect als het door Microsoft beheerde failoverbeleid is ingeschakeld en er een geforceerde failover is geactiveerd. Als de eigenschap in dat geval is ingesteld op Waar, bedient de nieuwe primaire zowel lezen en schrijven als alleen lezen sessies.

Architectuur van failovergroep

De failovergroep moet worden geconfigureerd op het primaire exemplaar en deze verbinden met het secundaire exemplaar in een andere Azure-regio. Alle gebruikersdatabases op het primaire exemplaar worden gerepliceerd naar het secundaire exemplaar. Systeemdatabases zoals master en msdb worden niet gerepliceerd.

In het volgende diagram ziet u een typische configuratie van een geografisch redundante cloudtoepassing met behulp van een met SQL beheerd exemplaar en een failovergroep:

Als uw toepassing SQL Managed Instance als de gegevenslaag gebruikt, volgt u de algemene richtlijnen en aanbevolen procedures die in dit artikel worden beschreven bij het ontwerpen voor bedrijfscontinuïteit.

Het geo-secundaire exemplaar maken

Om ervoor te zorgen dat er een ononderbroken verbinding met het primaire SQL Managed Instance is na een failover, moeten zowel de primaire als secundaire instanties zich in dezelfde DNS-zone bevinden. Het garandeert dat hetzelfde SAN-certificaat (multi-domain) kan worden gebruikt voor het verifiëren van clientverbindingen met een van de twee exemplaren in de failovergroep. Wanneer uw toepassing klaar is voor productie-implementatie, maakt u een secundair SQL Managed Instance in een andere regio en zorgt u ervoor dat deze de DNS-zone deelt met het primaire met SQL beheerde exemplaar. U kunt dit doen door een optionele parameter op te geven wanneer u een instantie maakt. Als u PowerShell of de REST API gebruikt, wordt de naam van de optionele parameter DNSZonePartner. De naam van het overeenkomstige optionele veld in de Azure portal is primair beheerd exemplaar.

Zie Een failovergroep configureren voor Azure SQL Managed Instancevoor meer informatie over het maken van het secundaire SQL Managed Instance in dezelfde DNS-zone als het primaire exemplaar.

Gekoppelde regio's gebruiken

Implementeer voor prestatie redenen beide SQL beheerde instanties in gekoppelde regio's. Failovergroepen van SQL Managed Instance in gekoppelde regio's hebben betere prestaties vergeleken met niet-gereserveerde regio's.

Azure SQL Managed Instance volgt een veilige implementatiepraktijk waarbij gekoppelde Azure-regio's doorgaans niet tegelijkertijd worden geïmplementeerd. Het is echter niet mogelijk om te voorspellen welke regio eerst wordt geüpgraded, dus de volgorde van de implementatie is niet gegarandeerd. Soms wordt uw primaire exemplaar eerst bijgewerkt en soms wordt het secundaire exemplaar eerst bijgewerkt.

In situaties waarin Azure SQL Managed Instance deel uitmaakt van een failovergroepen de exemplaren in de groep zich niet in gekoppelde Azure-regio'sbevinden, selecteert u verschillende onderhoudsvensterschema's voor uw primaire en secundaire database. Selecteer bijvoorbeeld een Weekdag onderhoudsvenster voor uw geo-secundaire database en een Weekend onderhoudsvenster voor uw geo-primaire database.

Verkeer voor geo-replicatie tussen de instanties inschakelen en optimaliseren

Connectiviteit tussen de subnetten van het virtuele netwerk die als host fungeren voor het primaire en secundaire exemplaar, moet tot stand worden gebracht en onderhouden voor een ononderbroken verkeersstroom voor geo-replicatie. Er zijn meerdere manieren om connectiviteit te bieden tussen de exemplaren waaruit u kunt kiezen op basis van uw netwerktopologie en -beleid:

• Globale virtuele netwerkpeering
• VPN-gateways
• Azure ExpressRoute

wereldwijde peering van virtuele netwerken (VNet-peering) is de aanbevolen manier om verbinding te maken tussen twee exemplaren in een failovergroep. Het biedt een privéverbinding met lage latentie en hoge bandbreedte tussen de gekoppelde virtuele netwerken met behulp van de Microsoft-backbone-infrastructuur. Er zijn geen openbare internetverbinding, gateways of bijkomende versleuteling vereist in de communicatie tussen de peering virtuele netwerken.

Eerste zaaien

Bij het tot stand brengen van een failovergroep tussen met SQL beheerde exemplaren is er een initiële seedingfase voordat de gegevensreplicatie wordt gestart. De eerste seedingfase is het langste en duurste deel van de bewerking. Zodra de eerste seeding is voltooid, worden gegevens gesynchroniseerd en worden alleen volgende gegevenswijzigingen gerepliceerd. De tijd die nodig is om de eerste seeding te voltooien, is afhankelijk van de grootte van de gegevens, het aantal gerepliceerde databases, de werkbelastingintensiteit voor de primaire databases en de snelheid van de koppeling tussen de virtuele netwerken die als host fungeert voor het primaire en secundaire exemplaar, wat meestal afhankelijk is van de manier waarop de connectiviteit tot stand is gebracht. Onder normale omstandigheden en wanneer connectiviteit tot stand wordt gebracht met behulp van aanbevolen wereldwijde peering voor virtuele netwerken, is seedingsnelheid maximaal 360 GB per uur voor SQL Managed Instance. Seeding wordt uitgevoerd voor een batch gebruikersdatabases parallel, maar niet noodzakelijkerwijs voor alle databases tegelijk. Er kunnen meerdere batches nodig zijn als er veel databases worden gehost op het exemplaar.

Als de snelheid van de koppeling tussen de twee instanties langzamer is dan nodig is, is de tijd om te zaaien waarschijnlijk merkbaar beïnvloed. U kunt de vermelde seedingsnelheid, het aantal databases, de totale gegevensgrootte en de snelheid van de koppeling gebruiken om te schatten hoe lang de initiële seedingfase duurt voordat de gegevensreplicatie begint. Voor een individuele database van 100 GB duurt de eerste seedfase bijvoorbeeld ongeveer 1,2 uur als de koppeling 84 GB per uur kan pushen en als er geen andere databases worden gezaaid. Als de koppeling slechts 10 GB per uur kan overdragen, kan het seeden van een database van 100 GB ongeveer 10 uur duren. Als er meerdere databases moeten worden gerepliceerd, wordt seeding parallel uitgevoerd. In combinatie met een trage koppelingssnelheid kan de eerste seedingfase aanzienlijk langer duren, met name als de parallelle seeding van gegevens uit alle databases de beschikbare koppelingsbandbreedte overschrijdt.

Geo-failover naar een geo-secundair exemplaar beheren

De failovergroep beheert geo-failover van alle databases op de primaire SQL-beheerde instantie. Wanneer een groep wordt gemaakt, wordt elke database op de instantie automatisch geo-gerepliceerd naar de geo-secundaire instantie. U kunt failovergroepen niet gebruiken om een gedeeltelijke failover van een subset van databases te starten.

De listener voor lezen/schrijven gebruiken (primaire MI)

Voor lees-schrijfworkloads gebruikt u <fog-name>.zone_id.database.windows.net als servernaam. Verbindingen worden automatisch omgeleid naar de primaire. Deze naam wordt niet gewijzigd na een failover. De geo-failover omvat het bijwerken van de DNS-record, zodat nieuwe clientverbindingen pas worden doorgestuurd naar de nieuwe primaire nadat de DNS-cache van de client is vernieuwd. Omdat het secundaire exemplaar de DNS-zone deelt met het primaire exemplaar, kan de clienttoepassing opnieuw verbinding maken met behulp van hetzelfde SAN-certificaat aan de serverzijde. De bestaande clientverbindingen moeten worden beëindigd en vervolgens opnieuw worden gemaakt om te worden gerouteerd naar de nieuwe primaire. De lees/schrijf-listener en alleen-lezen-listener kunnen niet worden bereikt via het openbare eindpunt voor het beheerde SQL-exemplaar.

De alleen-lezen listener (secundaire MI) gebruiken

Als u logisch geïsoleerde, alleen lezen-werkbelastingen hebt die bestand zijn tegen datavertraging, kunt u deze uitvoeren op de geo-secundaire instantie. Als u rechtstreeks verbinding wilt maken met de geo-secundaire, gebruikt u <fog-name>.secondary.<zone_id>.database.windows.net als servernaam.

In de Business Critical-laag ondersteunt SQL Managed Instance het gebruik van alleen-lezen replica's om alleen-lezen querywerklasten te offloaden met behulp van de parameter ApplicationIntent=ReadOnly in de connectiestring. Wanneer u een secundaire geo-replicatie hebt geconfigureerd, kunt u deze mogelijkheid gebruiken om verbinding te maken met een alleen-lezen replica op de primaire locatie of op de geo-gerepliceerde locatie:

• Als u verbinding wilt maken met een replica in alleen-lezen modus op de primaire locatie, gebruik ApplicationIntent=ReadOnly en <fog-name>.<zone_id>.database.windows.net.
• Als u verbinding wilt maken met een alleen-lezen replica op de secundaire locatie, gebruikt u ApplicationIntent=ReadOnly en <fog-name>.secondary.<zone_id>.database.windows.net.

De listener voor lezen/schrijven en alleen-lezen-listener kan niet worden bereikt via een openbaar eindpunt voor een met SQL beheerd exemplaar.

Mogelijke prestatievermindering na failover

Een typische Azure-toepassing maakt gebruik van meerdere Azure-services en bestaat uit meerdere onderdelen. Geo-failover van de groep wordt alleen geactiveerd op basis van de status van de Azure SQL-onderdelen. Een storing heeft mogelijk geen invloed op andere Azure-services in de primaire regio en de bijbehorende onderdelen zijn mogelijk nog steeds beschikbaar in die regio. Zodra de primaire databases overschakelen naar de secundaire regio, kan de latentie tussen de afhankelijke onderdelen toenemen. Zorg ervoor dat alle onderdelen van de toepassing redundant zijn in de secundaire regio en zorg voor een gezamenlijke failover van zowel de toepassingsonderdelen als de database, zodat een hogere latentie tussen regio's geen invloed heeft op de prestaties van de toepassing.

Potentieel gegevensverlies na geforceerde failover

Als er een storing optreedt in de primaire regio, zijn recente transacties mogelijk niet gerepliceerd naar de geo-secundaire regio en kunnen er gegevensverlies optreden als er een geforceerde failover wordt uitgevoerd.

DNS-update

De DNS-update van de read-write-listener vindt direct plaats nadat de failover is gestart. Deze bewerking leidt niet tot gegevensverlies. Het proces van het schakelen tussen databaserollen kan echter maximaal vijf minuten duren onder normale omstandigheden. Totdat deze is voltooid, zijn sommige databases in het nieuwe primaire exemplaar nog steeds in de alleen-lezenmodus. Als een failover wordt gestart met behulp van PowerShell, is de bewerking om de primaire replicarol te wijzigen synchroon. Als deze wordt gestart met behulp van Azure Portal, geeft de gebruikersinterface de voltooiingsstatus aan. Als deze wordt gestart met behulp van de REST API, gebruikt u het standaard pollingmechanisme van Azure Resource Manager om te controleren op voltooiing.

Kosten besparen met een licentievrije DR-replica

U kunt besparen op sql Server-licentiekosten door alleen uw secundaire SQL Managed Instance te configureren voor herstel na noodgevallen (DR). Zie Een stand-byreplica zonder licentie configureren voor Azure SQL Managed Instanceom dit in te stellen.

Zolang het secundaire exemplaar niet wordt gebruikt voor leesworkloads, biedt Microsoft u een gratis aantal vCores die overeenkomen met het primaire exemplaar. Er worden nog steeds kosten in rekening gebracht voor rekenkracht en opslag die wordt gebruikt door het secundaire exemplaar. Failovergroepen ondersteunen slechts één replica, en de replica moet een replica die leesbaar is zijn of aangemerkt als een DR-only replica.

Scenario's inschakelen die afhankelijk zijn van objecten uit de systeemdatabases

Systeemdatabases worden niet gerepliceerd naar het secundaire exemplaar in een failovergroep. Als u scenario's wilt inschakelen die afhankelijk zijn van objecten uit de systeemdatabases, moet u dezelfde objecten maken op het secundaire exemplaar. Houd ze gesynchroniseerd met het primaire exemplaar.

Als u bijvoorbeeld van plan bent om dezelfde inloggegevens op het secundaire exemplaar te gebruiken, zorg er dan voor dat u deze met dezelfde SID aanmaakt.

-- Code to create login on the secondary instance
CREATE LOGIN foo WITH PASSWORD = '<enterStrongPasswordHere>', SID = <login_sid>;

Voor meer informatie, zie Replicatie van aanmeldingen en agenttaken.

Exemplaareigenschappen en bewaarbeleidexemplaren synchroniseren

Exemplaren in een failovergroep blijven gescheiden van Azure-resources en er worden geen wijzigingen in de configuratie van het primaire exemplaar automatisch gerepliceerd naar het secundaire exemplaar. Zorg ervoor dat u alle relevante wijzigingen uitvoert op zowel het primaire als het secundaire exemplaar. Als u bijvoorbeeld redundantie van back-upopslag of bewaarbeleid voor langetermijnretentie voor back-ups op het primaire exemplaar wijzigt, moet u dit ook op het secundaire exemplaar wijzigen.

Schalen van instanties

De configuratie van uw primaire en secundaire exemplaar moet hetzelfde zijn. Dit omvat de rekenkracht, de opslaggrootte en de servicelaag. Als u de configuratie van uw failovergroep wilt wijzigen, kunt u dit doen door elk exemplaar dienovereenkomstig te schalen naar dezelfde configuratie. Raadpleeg Schalen in een failovergroep voor meer informatie.

Verlies van kritieke gegevens voorkomen

Vanwege de hoge latentie van wide area networks maakt geo-replicatie gebruik van een asynchroon replicatiemechanisme. Asynchrone replicatie maakt de mogelijkheid van gegevensverlies onvermijdelijk als de primaire mislukt. Als u wilt weten hoe u uw gegevens kunt beveiligen, raadpleegt u Gegevensverlies voorkomen.

Status van failovergroep

Failovergroep rapporteert de status van de huidige status van gegevensreplicatie:

• Seeding: Eerste seeding vindt plaats nadat de failovergroep is gemaakt, totdat alle gebruikersdatabases op het secundaire exemplaar worden geïnitialiseerd. Failover kan niet worden gestart terwijl de failovergroep de status Seeding heeft, omdat gebruikersdatabases nog niet naar het secundaire exemplaar worden gekopieerd.
• Synchroniseren: de gebruikelijke status van een failovergroep. Dit betekent dat gegevenswijzigingen op het primaire exemplaar asynchroon worden gerepliceerd naar het secundaire exemplaar. Deze status garandeert niet dat de gegevens op elk moment volledig worden gesynchroniseerd. Er kunnen gegevenswijzigingen van de primaire nog steeds naar de secundaire worden gerepliceerd vanwege de asynchrone aard van het replicatieproces tussen exemplaren in een failovergroep. Zowel automatische als handmatige failovers kunnen worden gestart terwijl de failovergroep de status Synchronisatie heeft.
• Failover wordt uitgevoerd: deze status geeft aan dat er automatisch of handmatig geïnitieerde failover wordt uitgevoerd. Er kunnen geen wijzigingen in de failovergroep of extra failovers worden gestart terwijl de failovergroep deze status heeft.

Terugval

Wanneer failovergroepen zijn geconfigureerd met een door Microsoft beheerd failoverbeleid, wordt geforceerde failover naar de geo-secundaire server gestart tijdens een noodscenario volgens de gedefinieerde respijtperiode. Failback naar de oude primaire server moet handmatig worden gestart.

Functie-interoperabiliteit

Reservekopieën

In de volgende scenario's wordt een volledige back-up gemaakt:

• Voordat de initiële seeding begint wanneer u een failovergroep maakt.
• Na een failover.

Een volledige back-up is een gegevensbewerking die niet kan worden overgeslagen of uitgesteld, en het voltooiingsproces kan enige tijd in beslag nemen. De tijd die nodig is om te voltooien, is afhankelijk van de grootte van gegevens, het aantal databases en de workloadintensiteit voor de primaire databases. Een volledige back-up kan merkbaar vertraging veroorzaken in de initiële seeding en kan een failoveroperatie op een nieuw exemplaar kort na een failover vertragen of verhinderen.

Houd rekening met het volgende:

• Er wordt pas een back-up gemaakt van databases die worden gehost op het secundaire exemplaar van een failovergroep totdat dit exemplaar primair wordt na een failover of totdat de failovergroep wordt verwijderd.
• Nadat een database na een failover verandert in de primaire rol, of standalone wordt nadat een failovergroep is verwijderd, wordt automatisch een volledige databaseback-up gestart om herstel naar een bepaald tijdstip te vergemakkelijken.
• Een database kan niet worden hersteld van een exemplaar naar een tijdstip waarop dat exemplaar een secundaire replica in een failovergroep was. Als u wilt herstellen naar een bepaald tijdstip, moet u de database herstellen van het exemplaar dat op dat moment primair was.
• Als u een verwijderde failovergroep opnieuw wilt maken op hetzelfde paar beheerde SQL-exemplaren, moeten alle gebruikersdatabases worden verwijderd uit de beoogde secundaire groep nadat de failovergroep is verwijderd. Een database wordt pas volledig verwijderd nadat alle onafgemaakte back-upbewerkingen zijn voltooid, inclusief een volledige back-up indien er nog geen volledige back-up is gemaakt (wat een operatie op basis van de grootte van de gegevens betreft). Sta tijd toe voor het opschonen van het secundaire exemplaar na het verwijderen van een failovergroep met zeer omvangrijke databases, omdat elke database een volledige back-upbewerking in behandeling kan hebben.

Een volledige back-up is een gegevensbewerking die niet kan worden overgeslagen of uitgesteld en enige tijd kan duren om te voltooien. De tijd die nodig is om te voltooien, is afhankelijk van de grootte van gegevens, het aantal databases en de workloadintensiteit voor de primaire databases. Een volledige back-up kan de eerste seeding aanzienlijk vertragen en kan een failoverbewerking op een nieuw exemplaar kort na een failover vertragen of voorkomen.

Logboekherhalingsservice

Databases die zijn gemigreerd naar Azure SQL Managed Instance met behulp van de Log Replay Service (LRS) kunnen pas worden toegevoegd aan een failovergroep nadat de cutover-stap is uitgevoerd. Een database die met LRS is gemigreerd, heeft een herstelstatus totdat cutover wordt uitgevoerd en databases met een herstelstatus kunnen niet worden toegevoegd aan een failovergroep. Als u een failovergroep probeert te maken met een database met een herstelstatus, wordt het maken van de failovergroep vertraagd totdat het herstellen van de database is voltooid.

Transactionele replicatie

Het gebruik van transactionele replicatie met exemplaren in een failovergroep wordt ondersteund. Als u echter replicatie configureert voordat u uw met SQL beheerde exemplaar toevoegt aan een failovergroep, wordt de replicatie onderbroken wanneer u begint met het maken van uw failovergroep. Replicatiemonitor toont een status van Replicated transactions are waiting for the next log backup or for mirroring partner to catch up. Replicatie wordt hervat zodra de failovergroep succesvol is gemaakt.

Als een uitgever of distributeur SQL Managed Instance zich in een failovergroep bevindt, moet de beheerder van de SQL-instantie alle publicaties opschonen op de oude primaire server en ze opnieuw configureren op de nieuwe primaire server nadat er een failover heeft plaatsgevonden. Raadpleeg de transactionele replicatiehandleiding voor de stap van activiteiten die nodig zijn in dit scenario.

Machtigingen en beperkingen

Bekijk een lijst met machtigingen en beperkingen voordat u een failovergroep configureert.

Failovergroepen programmatisch beheren

Failovergroepen kunnen ook programmatisch worden beheerd met behulp van Azure PowerShell, Azure CLI en REST API. Raadpleeg Failovergroep configureren voor meer informatie.

Rampenhersteloefeningen

De aanbevolen manier om een DR-oefening uit te voeren, is door het gebruik van handmatige geplande failover, zoals beschreven in de volgende handleiding: Failover testen.

Het uitvoeren van een oefening met geforceerde failover wordt niet aanbevolen, omdat deze bewerking geen kaders biedt tegen gegevensverlies. Toch is het mogelijk om gegevensverliesloze geforceerde failover te bereiken door ervoor te zorgen dat aan de volgende voorwaarden wordt voldaan voordat de geforceerde failover wordt gestart:

• De werkbelasting wordt gestopt op het primaire met SQL beheerde exemplaar.
• Alle langlopende transacties zijn voltooid.
• Alle clientverbindingen met het primaire beheerde SQL-exemplaar zijn verbroken.
• status van failovergroep 'Synchroniseren' is.

Zorg ervoor dat de twee met SQL beheerde exemplaren zijn overgeschakeld van rol. Ook is de status van de failovergroep overgeschakeld van Failover in uitvoering naar 'Synchroniseren' voordat er optioneel verbindingen worden gemaakt met het nieuwe primaire beheerde SQL-exemplaar en het starten van de lees-/schrijfworkload.

Als u een failback zonder gegevensverlies wilt uitvoeren naar de oorspronkelijke SQL Managed Instance-rollen, wordt het gebruik van handmatige geplande failover in plaats van geforceerde failover sterk aanbevolen. Als geforceerde failback gebruikt wordt:

• Volg dezelfde stappen als voor de failover zonder gegevensverlies.
• Langere uitvoeringstijd van failback wordt verwacht als de geforceerde failback wordt uitgevoerd kort nadat de initiële geforceerde failover is voltooid, omdat deze moet wachten op voltooiing van openstaande automatische back-upbewerkingen op het voormalige primaire SQL-beheerde exemplaar.
• Eventuele openstaande automatische back-upbewerkingen voor een instantie die van de primaire naar de secundaire rol overgaat, kunnen van invloed zijn op de beschikbaarheid van de database op deze instantie.
• Gebruik de status van de failovergroep om te bepalen of beide instanties hun rollen succesvol hebben gewijzigd en klaar zijn om clientverbindingen te accepteren.

Verwante inhoud

• Een failovergroep configureren voor Azure SQL Managed Instance
• PowerShell gebruiken om een met SQL beheerd exemplaar toe te voegen aan een failovergroep
• Configureer een licentievrije standby-replica voor Azure SQL Managed Instance
• Overzicht van bedrijfscontinuïteit met Azure SQL Managed Instance
• Automatische back-ups in Azure SQL Managed Instance
• een database herstellen vanuit een back-up in azure SQL Managed Instance