Delen via

Overzicht van failovergroepen en 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.

Als u aan de slag wilt gaan met de functie, raadpleegt u Een failovergroep configureren voor Azure SQL Managed Instance.

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 Instance voor meer informatie. Zie het overzicht van bedrijfscontinuïteit voor geo-failover RPO en RTO.

Eindpuntomleiding

Failovergroepen bieden alleen-lezen- 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 offloaden

Als u het verkeer naar uw primaire databases wilt verminderen, kunt u ook de secundaire databases in een failovergroep gebruiken om alleen-lezen workloads te offloaden. Gebruik de alleen-lezen-listener om alleen-lezenverkeer 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 failover beleidsregels:

  • Door de klant beheerd (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 manualde waarde van het failoverbeleid voor door de klant beheerd.
  • Door Microsoft beheerd - 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 automaticde waarde voor het failoverbeleid voor door Microsoft beheerd.

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

Failoverbeleid Failoverbereik Gebruiksscenario 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 geven. 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 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 door de klant beheerd wordt ten zeerste aanbevolen, omdat u hiermee de controle hebt over wanneer u een failover start en 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 controleren van de schaal 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 Door Microsoft beheerd 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, worden ze nog steeds een failover-overschakeling uitgevoerd 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 hebben dezelfde servicelaag, rekenlaag (ingericht of serverloos) en rekenkracht (DTU's of vCores). Als de serviceniveaudoelstelling (SLO) van alle databases in een failovergroep 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 er een vermelding voor de bewerkingsnaam Failover Azure SQL-failovergroep toegevoegd aan het activiteitenlogboek van Azure Monitor. De vermelding bevat de naam van de failovergroep onder Resource en gebeurtenis geïnitieerd door één afbreekstreepje (-) om aan te geven dat de failover is gestart door Microsoft. Deze informatie vindt u ook op de pagina Activiteitenlogboek van de nieuwe primaire server of het nieuwe exemplaar in 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 globaal uniek zijn binnen het domein .database.windows.net.

  • Primair

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

  • Secundair

    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 op zijn beurt ertoe leiden dat failover ook mislukt. 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 de grootte van gegevensbewerkingen zijn en het kan even duren voordat de servicelaag is voltooid.

  • 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 de primaire toegankelijk is. Failover wordt gebruikt in de volgende scenario's:

    • Noodherstelanalyses uitvoeren in productie wanneer gegevensverlies niet acceptabel is
    • De workload verplaatsen naar een andere regio
    • De workload terugsturen naar de primaire regio nadat de storing is verzacht (failback)

  • Geforceerde failover (mogelijk gegevensverlies)

    Geforceerde failover schakelt onmiddellijk over naar de primaire rol zonder te wachten tot recente wijzigingen van de primaire rol zijn doorgegeven. 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 een failback uit te voeren, zodat de replica's worden geretourneerd naar de oorspronkelijke primaire en secundaire rollen.

  • Respijtperiode 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 deze te GracePeriodWithDataLossHoursconfigureren, 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 nieuw met SQL beheerd exemplaar 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.

  • Listener voor lezen/schrijven van failovergroep

    Een DNS CNAME-record die verwijst naar de huidige primaire record. Deze wordt automatisch gemaakt wanneer de failovergroep wordt gemaakt en de workload lezen/schrijven toestaat om transparant opnieuw verbinding te maken met de primaire server wanneer de primaire wijzigingen na een failover worden gewijzigd. 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.

  • Listener voor alleen-lezen van failovergroep

    Een DNS CNAME-record die verwijst naar de huidige secundaire record. Deze wordt automatisch gemaakt wanneer de failovergroep wordt gemaakt en maakt het mogelijk dat de alleen-lezen SQL-workload transparant verbinding maakt met de secundaire workload wanneer de secundaire wijzigingen na een failover worden gewijzigd. 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 downtime voor de alleen-lezensessies niet kunt tolereren en de primaire functie voor zowel alleen-lezen als lezen-schrijven-verkeer kunt gebruiken ten koste van de mogelijke prestatievermindering van de primaire sessie, kunt u failover inschakelen voor de alleen-lezen-listener door de AllowReadOnlyFailoverToPrimary eigenschap te configureren. In dat geval wordt het alleen-lezenverkeer automatisch omgeleid naar de primaire als de secundaire niet beschikbaar is.

    Notitie

    De AllowReadOnlyFailoverToPrimary eigenschap 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 of a failover group for 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 de niet-onderbroken verbinding met het primaire MET SQL Managed Instance na een failover wordt uitgevoerd, moeten zowel de primaire als de secundaire exemplaren 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, is DNSZonePartnerde naam van de optionele parameter. De naam van het bijbehorende optionele veld in Azure Portal is Primary Managed Instance.

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 voor Azure SQL Managed Instance configureren voor Azure SQL Managed Instance voor 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, om prestatieredenen. SQL Managed Instance failovergroepen in gekoppelde regio's hebben betere prestaties in vergelijking met niet-gekoppelde 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 failovergroep en de exemplaren in de groep zich niet in gekoppelde Azure-regio's bevinden, selecteert u verschillende onderhoudsvensterschema's voor uw primaire en secundaire database. Selecteer bijvoorbeeld een onderhoudsvenster op weekdag voor uw geo-secundaire database en een onderhoudsvenster weekend voor uw geo-primaire database.

Verkeersstroom voor geo-replicatie tussen de exemplaren inschakelen en optimaliseren

Verbinding maken iviteit tussen de subnetten van het virtuele netwerk die als host fungeren voor het primaire en secundaire exemplaar, moeten worden ingesteld 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 connectiviteit tussen twee exemplaren in een failovergroep tot stand te brengen. Dit biedt een privéverbinding met lage latentie, een 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 seeding

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 lage of drukke koppeling waardoor de eerste seedingfase dagen duurt, kan er een time-out optreedt 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 geo-failover van alle databases op het primaire beheerde exemplaar. Wanneer een groep wordt gemaakt, wordt elke database in het exemplaar automatisch geo-gerepliceerd naar het geo-secundaire exemplaar. 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 <fog-name>.zone_id.database.windows.net u deze als servernaam. Verbinding maken ionen 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 listener voor lezen/schrijven en alleen-lezen-listener kan niet worden bereikt via het openbare eindpunt voor het beheerde exemplaar.

De alleen-lezen listener (secundaire MI) gebruiken

Als u logisch geïsoleerde alleen-lezenworkloads hebt die tolerant zijn voor gegevenslatentie, kunt u deze uitvoeren op de geo-secundaire database. Als u rechtstreeks verbinding wilt maken met de geo-secundaire server, gebruikt <fog-name>.secondary.<zone_id>.database.windows.net u deze als servernaam.

In de Bedrijfskritiek laag ondersteunt SQL Managed Instance het gebruik van alleen-lezen replica's om alleen-lezen queryworkloads te offloaden met behulp van de ApplicationIntent=ReadOnly parameter in de verbindingsreeks. 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 alleen-lezen replica op de primaire locatie, gebruikt ApplicationIntent=ReadOnly u en <fog-name>.<zone_id>.database.windows.net.
  • Als u verbinding wilt maken met een alleen-lezen replica op de secundaire locatie, gebruikt ApplicationIntent=ReadOnly u 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 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. 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 en failover van toepassingsonderdelen samen met de database wordt uitgevoerd, zodat de prestaties van de toepassing niet worden beïnvloed door een hogere latentie tussen regio's.

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 kan 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 alleen-lezen. 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 terug te verplaatsen naar de oorspronkelijke locatie zodra de storing die de geo-failover heeft veroorzaakt, is verzacht.

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 licentievrije stand-byreplica configureren voor Azure SQL Managed Instance om 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 ervoor zorgen dat u dezelfde objecten op het secundaire exemplaar maakt, en dat deze gesynchroniseerd blijven 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>;

Zie Replicatie van aanmeldingen en agenttaken voor meer informatie.

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 het primaire als het secundaire exemplaar. 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.

Exemplaren schalen

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 exemplaar naar een andere servicelaag schaalt, wordt deze aanbeveling afgedwongen. De volgorde van bewerkingen wordt afgedwongen bij het schalen van de servicelaag en vCores, evenals opslag.

De volgorde wordt aangeraden om te voorkomen dat het geo-secundaire exemplaar bij een lagere SKU overbelast raakt en opnieuw moet worden geseed tijdens een upgrade- of downgradeproces.

Notitie

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 onmiddellijk na het doorvoeren van de transactie aanroepen om kritieke transacties te beschermen tegen gegevensverlies. Het aanroepen sp_wait_for_database_copy_sync blokkeert de aanroepende thread totdat de laatste doorgevoerde transactie is verzonden en beperkt in het transactielogboek van de secundaire database. Er wordt echter niet gewacht totdat de verzonden transacties opnieuw worden afgespeeld (opnieuw worden afgespeeld) op de secundaire. 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 tijdens door de gebruiker geïnitieerde, geplande geo-failover, replicatie automatisch en tijdelijk te wijzigen in synchrone replicatie, voert u vervolgens een failover uit. Replicatie keert vervolgens terug naar de asynchrone modus nadat de geo-failover is voltooid.

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 de status van de huidige status van de gegevensreplicatie:

  • Seeding: eerste seeding vindt plaats na het maken van de failovergroep, totdat alle gebruikersdatabases op het secundaire exemplaar worden geïnitialiseerd. 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.

Failback

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.

Failovergroepen met 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 wordt in de replicatiemonitor de status weergegeven Replicated transactions are waiting for the next log backup or for mirroring partner to catch up. Replicatie wordt hervat zodra de failovergroep is gemaakt.

Als een uitgever of distributeur van sql managed instance zich in een failovergroep bevindt, moet de beheerder van het beheerde SQL-exemplaar alle publicaties op de oude primaire server opschonen en deze opnieuw configureren op de nieuwe primaire server nadat er een failover is opgetreden. Raadpleeg de transactionele replicatiehandleiding voor de stap van activiteiten die nodig zijn in dit scenario.

Machtigingen, beperkingen en vereisten

Raadpleeg de handleiding failovergroep configureren voor een lijst met machtigingen, beperkingen en vereisten voordat u doorgaat met het configureren van de failovergroep.

Failovergroepen programmatisch beheren

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

Gerelateerde inhoud