Delen via

Overzicht van failovergroepen & best practices - Azure SQL Managed Instance

  • Artikel

van toepassing op:Azure SQL Managed Instance

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

Raadpleeg Een failovergroep configureren voor azure SQL Managed Instanceom aan de slag te gaan met de functie.

Overzicht

Met de functie failovergroepen kunt u de replicatie en failover van gebruikersdatabases in een beheerd exemplaar naar een 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 lees-schrijf- 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.
  • door Microsoft beheerde - 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:

Failoverbeleid Failoverbereik Gebruikssituatie Potentieel gegevensverlies
Door de klant beheerd
(aanbevolen)		 Failovergroep(en) Een of meer databases in een failovergroep(en) worden beïnvloed door een storing en worden niet meer beschikbaar. U kunt ervoor kiezen om een failover uit te voeren. Ja
Door Microsoft beheerd Alle failovergroepen in de regio Een wijdverspreide storing in een datacenter, beschikbaarheidszone of regio zorgt ervoor dat databases niet beschikbaar zijn en het Microsoft Azure SQL-serviceteam besluit om een geforceerde failover te activeren.
Gebruik deze optie alleen als u de verantwoordelijkheid voor herstel na noodgevallen wilt delegeren aan Microsoft en de toepassing tolerant is voor RTO (downtime) van ten minste één uur of meer.		 Ja

Door de klant beheerd

In zeldzame gevallen is de ingebouwde beschikbaarheid of hoge beschikbaarheid niet voldoende is 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 de databases gebruiken. 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 datacenter-, beschikbaarheidszone- of regioniveau veroorzaakt door een natuurramp, configuratiewijzigingen, softwarefouten of storingen in hardwareonderdelen 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.

Belangrijk

Gebruik door de klant beheerd failoverbeleid om uw noodherstelplan te testen en te implementeren. Vertrouw niet op door Microsoft beheerde failover, die alleen in extreme omstandigheden door Microsoft kan worden uitgevoerd. Een door Microsoft beheerde failover wordt geïnitieerd voor alle failovergroepen in de regio waarvoor failoverbeleid is ingesteld op Door Microsoft beheerd. Het kan niet worden gestart voor een enkele failovergroep. Als u de mogelijkheid nodig hebt om selectief een failover van uw failovergroep uit te voeren, gebruikt u het door de klant beheerde failoverbeleid.

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.
  • Alle primaire en secundaire databases in de failovergroep en geo-replicatierelaties hebben dezelfde servicelaag, rekenlaag (ingericht of serverloos) & rekenkracht (DTU's of vCores). Als de serviceniveaudoelstelling (SLO) van alle databases niet overeenkomt, wordt het failoverbeleid uiteindelijk bijgewerkt van Microsoft Managed to Customer Managed by Azure SQL Service.

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 exemplaar een failover uitvoeren als een eenheid naar een andere Azure-regio als het primaire beheerde 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 exemplaar dat als host fungeert voor de primaire databases in de failovergroep.

  • secundaire

    Het beheerde 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 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 SQL Managed Instance, wordt het DNS CNAME-record voor de listener-URL gevormd tot <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, zal de nieuwe primaire server zowel lezen-schrijven als alleen-lezensessies verwerken.

Architectuur van failovergroep

De failovergroep moet worden geconfigureerd op het primaire exemplaar en verbindt deze met het secundaire exemplaar in een andere Azure-regio. Alle gebruikersdatabases in het 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 beheerd exemplaar en een failovergroep:

diagram van een failovergroep voor Azure SQL Managed Instance.

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 niet-onderbroken verbinding is met de primaire SQL Managed Instance na een failover, moeten zowel de primaire als de 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 tijdens het maken een optionele parameter op te geven. 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.

Belangrijk

Het eerste beheerde exemplaar dat in het subnet is gemaakt, bepaalt de DNS-zone voor alle volgende exemplaren in hetzelfde subnet. Dit betekent dat twee exemplaren van hetzelfde subnet niet tot verschillende DNS-zones kunnen behoren.

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 beide beheerde exemplaren in gekoppelde regio's voor betere prestaties. 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 wordt 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 ononderbroken verkeersstroom voor geo-replicatie. Er zijn meerdere manieren om connectiviteit te bieden tussen de exemplaren die u kunt kiezen op basis van uw netwerktopologie en beleid:

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 is geen openbaar internet, gateways of extra versleuteling vereist in de communicatie tussen de gekoppelde virtuele netwerken.

Eerste zaaien

Bij het tot stand brengen van een failovergroep tussen beheerde exemplaren is er een eerste seedingfase voordat de gegevensreplicatie wordt gestart. De eerste seedingfase is het langste en duurste deel van de bewerking. Zodra de initiële 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 gegevens, het aantal gerepliceerde databases, de werkbelastingsintensiteit voor de primaire databases en de snelheid van de koppeling tussen de virtuele netwerken die als host fungeren voor het primaire en secundaire exemplaar, dat 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, 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 en, 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.

Belangrijk

In het geval van een extreem langzame of drukke verbinding waardoor de eerste seedingfase dagen duurt, kan er een time-out optreden bij het maken van een failovergroep. Het aanmaakproces wordt na 6 dagen automatisch geannuleerd.

Geo-failover naar een geo-secundair exemplaar beheren

De failovergroep beheert de geografische failover van alle databases op het primaire beheerde exemplaar. Wanneer een groep wordt gemaakt, wordt elke database in 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.

Belangrijk

Als een database wordt verwijderd op het primaire beheerde exemplaar, wordt deze ook automatisch verwijderd op het beheerde geo-secundaire beheerde exemplaar.

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 de nieuwe clientverbindingen alleen naar de nieuwe primaire worden gerouteerd 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 lezen/schrijven-listener en de alleen-lezen-listener kunnen niet worden bereikt via het openbare eindpunt voor het beheerde 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 lezen/schrijven-listener en alleen-lezen-listener kunnen niet worden bereikt via het publieke eindpunt voor de beheerde instantie.

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. Andere Azure-services in de primaire regio worden mogelijk niet beïnvloed door de storing 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 de redundantie van alle onderdelen van de toepassing in de secundaire regio is gegarandeerd en schakel toepassingsonderdelen samen met de database over, zodat de prestaties van de toepassing niet door hogere latentie tussen verschillende regio's worden beïnvloed.

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 tot 5 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.

Belangrijk

Gebruik handmatige geplande failover om de primaire locatie terug te verplaatsen naar de oorspronkelijke locatie zodra de storing die de geo-failover heeft veroorzaakt, is opgelost.

Kosten besparen met een licentievrije DR-replica

U kunt besparen op sql Server-licentiekosten door uw secundaire beheerde exemplaar alleen 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. De replica moet een leesbare replica zijn of worden aangewezen als een alleen-noodherstelreplica.

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 en deze gesynchroniseerd houden met het primaire exemplaar.

Als u bijvoorbeeld van plan bent om dezelfde aanmeldingen op het secundaire exemplaar te gebruiken, moet u deze maken met de identieke SID.

-- 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 afzonderlijke 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 de primaire als secundaire instantie. Als u bijvoorbeeld redundantie van back-upopslag of bewaarbeleid voor langetermijnretentie voor back-ups op een primair exemplaar wijzigt, moet u deze ook wijzigen op het secundaire exemplaar.

Schalen van instanties

U kunt het primaire en secundaire exemplaar omhoog of omlaag schalen naar een andere rekenkracht binnen dezelfde servicelaag of naar een andere servicelaag. Wanneer u omhoog schaalt binnen dezelfde servicelaag, raden we u aan eerst de geo-secundaire laag omhoog te schalen en vervolgens de primaire laag omhoog te schalen. Wanneer u omlaag schaalt binnen dezelfde servicelaag, keert u de volgorde om: schaal eerst de primaire laag omlaag en schaal vervolgens de secundaire laag omlaag. Wanneer u een instantie schaalt naar een andere servicelaag, wordt deze aanbeveling toegepast. De volgorde van bewerkingen wordt afgedwongen bij het schalen van de servicelaag en vCores, evenals opslag.

De reeks wordt specifiek aanbevolen om het probleem te voorkomen waarbij de geo-secundaire bij een lagere SKU overbelast raakt en opnieuw moet worden verzonden tijdens een upgrade- of downgradeproces.

Belangrijk

  • Voor exemplaren in een failovergroep wordt het wijzigen van het serviceniveau naar of van de Next-gen Algemeen gebruik categorie niet ondersteund. U moet eerst de failovergroep verwijderen voordat u een van beide replica's wijzigt en vervolgens de failovergroep opnieuw maken nadat de wijziging is doorgevoerd.
  • Er is een bekend probleem dat van invloed kan zijn op de toegankelijkheid van het exemplaar dat wordt geschaald met behulp van de bijbehorende listener voor failovergroepen.

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. Een toepassingsontwikkelaar kan de sp_wait_for_database_copy_sync opgeslagen procedure direct na het doorvoeren van de transactie aanroepen om kritieke transacties te beschermen tegen gegevensverlies. Het aanroepen van sp_wait_for_database_copy_sync blokkeert de aanroepende thread totdat de laatste doorgevoerde transactie is verzonden en gehard in het transactielogboek van de secundaire database. Er wordt echter niet gewacht totdat de verzonden transacties op de secundaire opnieuw worden afgespeeld. sp_wait_for_database_copy_sync is gericht op een specifieke geo-replicatiekoppeling. Elke gebruiker met de verbindingsrechten voor de primaire database kan deze procedure aanroepen.

Om gegevensverlies te voorkomen tijdens door de gebruiker geïnitieerde, geplande geo-failover, verandert replicatie automatisch en tijdelijk in synchrone replicatie, en wordt er vervolgens een failover uitgevoerd. Nadat de geo-failover is voltooid, keert de replicatie vervolgens terug naar de asynchrone modus.

Notitie

sp_wait_for_database_copy_sync voorkomt gegevensverlies na geo-failover voor specifieke transacties, maar garandeert geen volledige synchronisatie voor leestoegang. De vertraging die wordt veroorzaakt door een sp_wait_for_database_copy_sync procedure-aanroep kan aanzienlijk zijn en is afhankelijk van de grootte van het nog niet verzonden transactielogboek op de primaire op het moment van de oproep.

Status van failovergroep

Failovergroep rapporteert zijn status door de huidige staat van de gegevensreplicatie te beschrijven.

  • Seeding: initiële seeding voltrekt zich na de creatie van de failovergroep, totdat alle gebruikersdatabases zijn geïnitialiseerd op de secundaire instantie. Failoverproces kan niet worden gestart terwijl de failovergroep de seeding-status heeft, omdat gebruikersdatabases nog niet naar het secundaire exemplaar worden gekopieerd.
  • Synchroniseren - de gebruikelijke status van de 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 instanties in de failovergroep. Zowel automatische als handmatige failovers kunnen worden gestart terwijl de failovergroep de synchronisatiestatus heeft.
  • Failover wordt uitgevoerd: deze status geeft aan dat er automatisch of handmatig een failoverproces 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

Backups

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.

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 en de replicatiemonitor geeft een status van Replicated transactions are waiting for the next log backup or for mirroring partner to catch upweer. 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 werklast wordt stopgezet op de primaire beheerinstance.
  • Alle langlopende transacties zijn voltooid.
  • Alle clientverbindingen met het primaire beheerde exemplaar zijn verbroken.
  • status van failovergroep 'Synchroniseren' is.

Zorg ervoor dat de twee beheerde exemplaren zijn overgeschakeld van rol en dat de status van de failovergroep is overgeschakeld van 'Failover wordt uitgevoerd' naar 'Synchroniseren' voordat u optioneel verbindingen tot stand kunt brengen met het nieuwe primaire beheerde exemplaar en de lees-/schrijfworkload start.

Als u een failback zonder gegevensverlies wilt uitvoeren naar de oorspronkelijke rollen van het beheerde exemplaar, 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 eerste geforceerde failover is voltooid, omdat deze moet wachten op voltooiing van openstaande automatische back-upbewerkingen op het voormalige primaire beheerde exemplaar.
  • Eventuele openstaande automatische back-upbewerkingen op het beheerde exemplaar dat van de primaire naar de secundaire rol overgaat, hebben invloed op de beschikbaarheid van de database op dit exemplaar.
  • 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