Overzicht van aanbevolen & procedures voor groepen voor automatische failover (Azure SQL Database)

VAN TOEPASSING OP: Azure SQL Database

Met de functie voor groepen voor automatische failover kunt u de replicatie en failover van sommige of alle databases op een logische server naar een andere regio beheren. Dit artikel is gericht op het gebruik van de functie voor automatische failovergroepen met Azure SQL Database en enkele aanbevolen procedures.

Raadpleeg de groep Automatische failover configureren om aan de slag te gaan. Voor een end-to-end-ervaring raadpleegt u de zelfstudie voor de groep voor automatische failover.

Notitie

Overzicht

Met de functie voor groepen voor automatische failover kunt u de replicatie en failover van een groep databases op een server of alle gebruikersdatabases in een beheerd exemplaar naar een andere Azure-regio beheren. Het is een declaratieve abstractie boven op de actieve functie voor geo-replicatie , ontworpen om de implementatie en het beheer van geo-gerepliceerde databases op schaal te vereenvoudigen.

Automatische failover

U kunt een geo-failover handmatig initiëren of u kunt deze delegeren aan de Azure-service op basis van een door de gebruiker gedefinieerd beleid. Met de laatste optie kunt u automatisch meerdere gerelateerde databases in een secundaire regio herstellen na een catastrofale fout of andere ongeplande gebeurtenis die resulteert in volledig of gedeeltelijk verlies van de SQL Database of SQL Managed Instance beschikbaarheid in de primaire regio. Dit zijn doorgaans storingen die niet automatisch kunnen worden verzacht door de ingebouwde infrastructuur voor hoge beschikbaarheid. Voorbeelden van geofailovertriggers zijn natuurrampen of incidenten die worden veroorzaakt door een tenant of besturingsring die wordt veroorzaakt door een lek in het geheugen van het besturingssysteem op rekenknooppunten. Zie Azure SQL hoge beschikbaarheid voor meer informatie.

Alleen-lezen workloads offloaden

Als u het verkeer naar uw primaire databases wilt beperken, 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.

Eindpuntomleiding

Groepen voor automatische failover bieden listener-eindpunten met mogelijkheden voor lezen/schrijven en alleen-lezen die ongewijzigd blijven tijdens geo-failovers. Dit betekent dat u de connection string voor uw toepassing niet hoeft te wijzigen na een geo-failover, omdat verbindingen automatisch naar de huidige primaire worden gerouteerd. Ongeacht of u handmatige of automatische failoveractivering gebruikt, schakelt een geo-failover alle secundaire databases in de groep over naar de primaire rol. Nadat de geo-failover is voltooid, wordt de DNS-record automatisch bijgewerkt om de eindpunten om te leiden naar de nieuwe regio. Zie Overzicht van bedrijfscontinuïteit voor geo-failover RPO en RTO.

Een toepassing herstellen

Om volledige bedrijfscontinuïteit te bereiken, maakt het toevoegen van regionale databaseredundantie slechts deel uit van de oplossing. Voor het herstellen van een toepassing (service) end-to-end na een catastrofale fout is herstel vereist van alle onderdelen die de service en eventuele 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 de garanties en mogelijkheden begrijpen die ze bieden. Vervolgens moet u adequate stappen uitvoeren om ervoor te zorgen dat uw servicefuncties tijdens de failover van de services waarvan deze afhankelijk is, worden uitgevoerd.

Terminologie en mogelijkheden

  • Failovergroep (FOG)

    Een failovergroep is een benoemde groep databases die worden beheerd door één server die een failover kan uitvoeren als een eenheid naar een andere Azure-regio voor het geval alle of sommige primaire databases niet beschikbaar zijn vanwege een storing in de primaire regio.

    Belangrijk

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

  • Servers

    Sommige of alle gebruikersdatabases op een logische server kunnen in een failovergroep worden geplaatst. Een server ondersteunt ook meerdere failovergroepen op één server.

  • Primair

    De server die als host fungeert voor de primaire databases in de failovergroep.

  • Secundair

    De server die als host fungeert voor de secundaire databases in de failovergroep. De secundaire kan zich niet in dezelfde Azure-regio bevinden als de primaire regio.

  • Individuele databases toevoegen aan failovergroep

    U kunt meerdere individuele databases op dezelfde server in dezelfde failovergroep plaatsen. Als u één database toevoegt aan de failovergroep, wordt automatisch een secundaire database gemaakt met dezelfde editie en rekengrootte op de secundaire server. U hebt die server opgegeven toen de failovergroep werd gemaakt. Als u een database toevoegt die al een secundaire database op de secundaire server heeft, wordt die geo-replicatiekoppeling overgenomen door de groep. Wanneer u een database toevoegt die al een secundaire database heeft op een server die geen deel uitmaakt van de failovergroep, wordt er een nieuwe secundaire database gemaakt op de secundaire server.

    Belangrijk

    Zorg ervoor dat de secundaire server geen database met dezelfde naam heeft, tenzij het een bestaande secundaire database is.

  • Databases toevoegen aan een elastische pool aan een failovergroep

    U kunt alle of meerdere databases in een elastische pool in dezelfde failovergroep plaatsen. Als de primaire database zich in een elastische pool bevindt, wordt de secundaire automatisch gemaakt in de elastische pool met dezelfde naam (secundaire pool). U moet ervoor zorgen dat de secundaire server een elastische pool bevat met dezelfde exacte naam en voldoende vrije capaciteit om de secundaire databases te hosten die worden gemaakt door de failovergroep. Als u een database toevoegt in de pool die al een secundaire database in de secundaire pool heeft, wordt die geo-replicatiekoppeling overgenomen door de groep. Wanneer u een database toevoegt die al een secundaire database heeft op een server die geen deel uitmaakt van de failovergroep, wordt er een nieuwe secundaire database gemaakt in de secundaire pool.

  • Lees-/schrijflistener voor 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 workload wanneer de primaire wijzigingen na een failover worden gewijzigd. Wanneer de failovergroep op een server wordt gemaakt, wordt de DNS CNAME-record voor de listener-URL gevormd als <fog-name>.database.windows.net.

  • Failovergroep alleen-lezen listener

    Een DNS CNAME-record die verwijst naar de huidige secundaire record. Deze wordt automatisch gemaakt wanneer de failovergroep wordt gemaakt en de workload alleen-lezen SQL op transparante wijze verbinding kan maken met de secundaire workload wanneer de secundaire wijzigingen na een failover worden gewijzigd. Wanneer de failovergroep op een server wordt gemaakt, wordt de DNS CNAME-record voor de listener-URL gevormd als <fog-name>.secondary.database.windows.net.

  • Meerdere failovergroepen

    U kunt meerdere failovergroepen configureren voor hetzelfde paar servers om het bereik van geo-failovers te beheren. Elke groep voert een failover uit onafhankelijk van elkaar uit. Als uw tenant-per-databasetoepassing wordt geïmplementeerd in meerdere regio's en elastische pools gebruikt, kunt u deze mogelijkheid gebruiken om primaire en secundaire databases in elke pool te combineren. Op deze manier kunt u mogelijk de gevolgen van een storing beperken tot slechts enkele tenantdatabases.

  • Beleid voor automatische failover

    Standaard wordt een failovergroep geconfigureerd met een automatisch failoverbeleid. Het systeem activeert een geo-failover nadat de fout is gedetecteerd en de respijtperiode is verlopen. Het systeem moet controleren of de storing niet kan worden verzacht door de ingebouwde infrastructuur voor hoge beschikbaarheid, bijvoorbeeld vanwege de schaal van de impact. Als u de werkstroom voor geofailover vanuit de toepassing of handmatig wilt beheren, kunt u het beleid voor automatische failover uitschakelen.

    Notitie

    Omdat de verificatie van de schaal van de storing en hoe snel deze kan worden beperkt, menselijke acties omvat, kan de respijtperiode niet onder één uur worden ingesteld. Deze beperking is van toepassing op alle databases in de failovergroep, ongeacht de status van de gegevenssynchronisatie.

  • Alleen-lezen failoverbeleid

    Standaard is de failover van de alleen-lezenlistener uitgeschakeld. Het zorgt ervoor dat de prestaties van de primaire server niet worden beïnvloed wanneer de secundaire offline is. Het 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 potentiële 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 automatisch failoverbeleid is ingeschakeld en er een automatische geo-failover is geactiveerd. Als de eigenschap in dat geval is ingesteld op Waar, wordt de nieuwe primaire sessie zowel lezen-schrijven als alleen-lezensessies gebruikt.

  • Geplande failover

    Geplande failover voert volledige gegevenssynchronisatie uit tussen primaire en secundaire databases voordat de secundaire overschakelt naar de primaire rol. Dit garandeert geen gegevensverlies. Geplande failover wordt gebruikt in de volgende scenario's:

    • Noodherstelanalyses (DR) uitvoeren in productie wanneer gegevensverlies niet acceptabel is
    • De databases verplaatsen naar een andere regio
    • De databases retourneren naar de primaire regio nadat de storing is verzacht (failback)
  • Niet-geplande failover

    Niet-geplande of geforceerde failover schakelt onmiddellijk de secundaire naar de primaire rol over zonder te wachten op recente wijzigingen die van de primaire worden doorgegeven. Deze bewerking kan leiden tot gegevensverlies. Niet-geplande failover wordt gebruikt als herstelmethode tijdens storingen wanneer de primaire niet toegankelijk is. Wanneer de storing wordt verzacht, wordt de oude primaire automatisch opnieuw verbonden en wordt deze een nieuwe secundaire. Er kan een geplande failover worden uitgevoerd om failback uit te voeren, zodat de replica's worden geretourneerd naar de oorspronkelijke primaire en secundaire rollen.

  • Handmatige failover

    U kunt op elk gewenst moment handmatig een geo-failover initiëren, ongeacht de automatische failoverconfiguratie. Tijdens een storing die van invloed is op het primaire failoverbeleid, als het beleid voor automatische failover niet is geconfigureerd, is een handmatige failover vereist om de secundaire naar de primaire rol te promoveren. U kunt een geforceerde (ongeplande) of een vriendelijke (geplande) failover initiëren. Een beschrijvende failover is alleen mogelijk wanneer de oude primaire is toegankelijk en kan worden gebruikt om de primaire naar de secundaire regio te verplaatsen zonder gegevensverlies. Wanneer een failover is voltooid, worden de DNS-records automatisch bijgewerkt om ervoor te zorgen dat er verbinding wordt gemaakt met de nieuwe primaire server.

  • Respijtperiode met gegevensverlies

    Omdat de gegevens worden gerepliceerd naar de secundaire database met behulp van asynchrone replicatie, kan een automatische geo-failover leiden tot gegevensverlies. U kunt het beleid voor automatische failover aanpassen aan de tolerantie van uw toepassing voor gegevensverlies. Door te GracePeriodWithDataLossHoursconfigureren, kunt u bepalen hoe lang het systeem wacht voordat een geforceerde failover wordt gestart, wat kan leiden tot gegevensverlies.

Architectuur van failovergroep

Een failovergroep in Azure SQL Database kan een of meer databases bevatten, die doorgaans door dezelfde toepassing worden gebruikt. Wanneer u groepen voor automatische failover gebruikt met beleid voor automatische failover, resulteert een storing die van invloed is op een of meer van de databases in de groep tot een automatische geo-failover.

De groep voor automatische failover moet worden geconfigureerd op de primaire server en verbindt deze met de secundaire server in een andere Azure-regio. De groepen kunnen alle of sommige databases op deze servers bevatten. In het volgende diagram ziet u een typische configuratie van een geografisch redundante cloudtoepassing die gebruikmaakt van meerdere databases en een groep voor automatische failover.

Diagram shows a typical configuration of a geo-redundant cloud application using multiple databases and auto-failover group.

Als u een service ontwerpt met bedrijfscontinuïteit, volgt u de algemene richtlijnen en aanbevolen procedures die in dit artikel worden beschreven. Wanneer u een failovergroep configureert, moet u ervoor zorgen dat verificatie en netwerktoegang op de secundaire server correct functioneren na geo-failover, wanneer de geo-secundaire de nieuwe primaire wordt. Zie SQL Database beveiliging na herstel na noodgeval voor meer informatie. Zie Cloud Solutions for Disaster Recovery ontwerpen met actieve geo-replicatie voor meer informatie over het ontwerpen van oplossingen voor herstel na noodgevallen.

Zie Point-in-Time Recovery (PITR) voor informatie over het gebruik van herstel naar een bepaald tijdstip met failovergroepen.

Eerste seeding

Wanneer u databases of elastische pools toevoegt aan een failovergroep, is er een initiële seedingfase voordat de gegevensreplicatie wordt gestart. De eerste seedingfase is de langste en duurste 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 uw gegevens, het aantal gerepliceerde databases, de belasting van primaire databases en de snelheid van de koppeling tussen de primaire en secundaire database. Onder normale omstandigheden is de mogelijke seedingsnelheid maximaal 500 GB per uur voor SQL Database. Seeding wordt parallel uitgevoerd voor alle databases.

Meerdere failovergroepen gebruiken om meerdere databases te failovern

Een of veel failovergroepen kunnen worden gemaakt tussen twee servers in verschillende regio's (primaire en secundaire servers). Elke groep kan een of meerdere databases bevatten die als eenheid worden hersteld als alle of sommige primaire databases niet beschikbaar zijn vanwege een storing in de primaire regio. Als u een failovergroep maakt, worden geo-secundaire databases gemaakt met dezelfde servicedoelstelling als de primaire database. Als u een bestaande geo-replicatierelatie toevoegt aan een failovergroep, moet u ervoor zorgen dat de geo-secundaire is geconfigureerd met dezelfde servicelaag en rekenkracht als de primaire.

De listener voor lezen/schrijven gebruiken (primair)

Gebruik voor lees-/schrijfworkloads <fog-name>.database.windows.net als de servernaam in de verbindingsreeks. Verbindingen worden automatisch omgeleid naar de primaire verbinding. Deze naam verandert niet na een failover. Houd er rekening mee dat de failover betrekking heeft op het bijwerken van de DNS-record, zodat de clientverbindingen alleen worden omgeleid naar de nieuwe primaire server nadat de DNS-cache van de client is vernieuwd. De time to live (TTL) van de DNS-record van de primaire en secundaire listener is 30 seconden.

De alleen-lezen listener (secundair) gebruiken

Als u logisch geïsoleerde alleen-lezenworkloads hebt die tolerant zijn voor gegevenslatentie, kunt u ze uitvoeren op de geo-secundaire locatie. Gebruik voor alleen-lezensessies <fog-name>.secondary.database.windows.net als de servernaam in de verbindingsreeks. Verbindingen worden automatisch omgeleid naar de geo-secundaire locatie. Het wordt ook aanbevolen om de leesintentie in de connection string aan te geven met behulp van ApplicationIntent=ReadOnly.

In Premium-, Bedrijfskritiek- en Hyperscale-servicelagen ondersteunt SQL Database het gebruik van alleen-lezen replica's om alleen-lezen queryworkloads te offloaden met behulp van de ApplicationIntent=ReadOnly parameter in de connection string. Wanneer u een geo-secundaire locatie 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 secundaire locatie, gebruikt ApplicationIntent=ReadOnly u en <fog-name>.secondary.database.windows.net.

Mogelijke prestatievermindering na failover

Een typische Azure-toepassing maakt gebruik van meerdere Azure-services en bestaat uit meerdere onderdelen. De automatische geo-failover van de failovergroep wordt geactiveerd op basis van de status van de Azure SQL onderdelen alleen. 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 zijn overgeschakeld naar de secundaire regio (DR), kan de latentie tussen de afhankelijke onderdelen toenemen. Als u de gevolgen van een hogere latentie op de prestaties van de toepassing wilt voorkomen, moet u de redundantie van alle onderdelen van de toepassing in de regio herstel na noodgeval controleren, deze richtlijnen voor netwerkbeveiliging volgen en de geo-failover van relevante toepassingsonderdelen samen met de database organiseren.

Potentieel gegevensverlies na failover

Als er een storing optreedt in de primaire regio, kunnen recente transacties mogelijk niet worden gerepliceerd naar de geo-secundaire regio. Als het beleid voor automatische failover is geconfigureerd, wacht het systeem op de periode die u hebt opgegeven GracePeriodWithDataLossHours voordat u een automatische geo-failover start. De standaardwaarde is 1 uur. Dit begunstigt de beschikbaarheid van databases boven gegevensverlies. Als GracePeriodWithDataLossHours u een groter aantal instelt, zoals 24 uur, of automatische geo-failover uitschakelt, kunt u de kans op gegevensverlies verminderen ten koste van de beschikbaarheid van de database.

Belangrijk

Elastische pools met 800 of minder DTU's of 8 of minder vCores, en meer dan 250 databases kunnen problemen ondervinden, waaronder langere geplande geo-failovers en verminderde prestaties. Deze problemen zijn waarschijnlijker voor schrijfintensieve workloads, wanneer geo-replica's veel worden gescheiden door geografie of wanneer meerdere secundaire geo-replica's voor elke database worden gebruikt. Een symptoom van deze problemen is een toename van de vertraging van geo-replicatie in de loop van de tijd, wat mogelijk leidt tot een uitgebreider gegevensverlies in een storing. Deze vertraging kan worden bewaakt met behulp van sys.dm_geo_replication_link_status. Als deze problemen optreden, omvat het opschalen van de pool om meer DTU's of vCores te hebben, of het aantal geo-gerepliceerde databases in de pool te verminderen.

Failovergroepen en netwerkbeveiliging

Voor sommige toepassingen vereisen de beveiligingsregels dat de netwerktoegang tot de gegevenslaag beperkt is tot een specifiek onderdeel of specifieke onderdelen, zoals een VM, webservice, enzovoort. Deze vereiste biedt enkele uitdagingen voor het ontwerp van bedrijfscontinuïteit en het gebruik van failovergroepen. Houd rekening met de volgende opties bij het implementeren van dergelijke beperkte toegang.

Failovergroepen en service-eindpunten voor virtuele netwerken gebruiken

Als u Virtual Network service-eindpunten en -regels gebruikt om de toegang tot uw database in SQL Database te beperken, moet u er rekening mee houden dat elk service-eindpunt van het virtuele netwerk slechts van toepassing is op slechts één Azure-regio. Met het eindpunt kunnen andere regio's geen communicatie van het subnet accepteren. Daarom kunnen alleen de clienttoepassingen die in dezelfde regio zijn geïmplementeerd, verbinding maken met de primaire database. Omdat een geo-failover resulteert in de SQL Database clientsessies die worden omgeleid naar een server in een andere (secundaire) regio, mislukken deze sessies als deze afkomstig zijn van een client buiten die regio. Daarom kan het beleid voor automatische failover niet worden ingeschakeld als de deelnemende servers of exemplaren zijn opgenomen in de Virtual Network regels. Voer de volgende stappen uit om handmatige failover te ondersteunen:

  1. Richt de redundante kopieën van de front-endonderdelen van uw toepassing (webservice, virtuele machines enzovoort) in de secundaire regio in.
  2. Configureer de regels voor virtuele netwerken afzonderlijk voor de primaire en secundaire server.
  3. Schakel de front-endfailover in met behulp van een Traffic Manager-configuratie.
  4. Handmatige geo-failover starten wanneer de storing wordt gedetecteerd. Deze optie is geoptimaliseerd voor de toepassingen waarvoor consistente latentie tussen de front-end en de gegevenslaag is vereist en ondersteuning biedt voor herstel wanneer de front-end, de gegevenslaag of beide worden beïnvloed door de storing.

Notitie

Als u de alleen-lezenlistener gebruikt om een alleen-lezenworkload te verdelen, moet u ervoor zorgen dat deze workload wordt uitgevoerd in een VIRTUELE machine of een andere resource in de secundaire regio, zodat deze verbinding kan maken met de secundaire database.

Failovergroepen en firewallregels gebruiken

Als voor uw bedrijfscontinuïteitsplan failover is vereist met behulp van groepen met automatische failover, kunt u de toegang tot uw database in SQL Database beperken met behulp van openbare IP-firewallregels. Voer de volgende stappen uit om automatische failover te ondersteunen:

  1. Maak een openbaar IP-adres.
  2. Maak een openbare load balancer en wijs het openbare IP-adres eraan toe.
  3. Maak een virtueel netwerk en de virtuele machines voor uw front-endonderdelen.
  4. Maak een netwerkbeveiligingsgroep en configureer binnenkomende verbindingen.
  5. Zorg ervoor dat de uitgaande verbindingen zijn geopend voor Azure SQL Database in een regio met behulp van een Sql.<Region>servicetag.
  6. Maak een SQL Database firewallregel om inkomend verkeer toe te staan van het openbare IP-adres dat u in stap 1 maakt.

Zie Uitgaande verbindingen van load balancer voor meer informatie over het configureren van uitgaande toegang en welk IP-adres moet worden gebruikt in de firewallregels.

De bovenstaande configuratie zorgt ervoor dat een automatische geo-failover verbindingen van de front-endonderdelen niet blokkeert en ervan uitgaat dat de toepassing de langere latentie tussen de front-end en de gegevenslaag kan tolereren.

Belangrijk

Als u bedrijfscontinuïteit wilt garanderen tijdens regionale storingen, moet u geografische redundantie garanderen voor zowel front-endonderdelen als databases.

Primaire database schalen

U kunt de primaire database omhoog of omlaag schalen naar een andere rekenkracht (binnen dezelfde servicelaag) zonder de verbinding met geo-secundaire databases te verbreken. Wanneer u omhoog schaalt, raden we u aan eerst de geo-secundaire schaal op te schalen en vervolgens de primaire schaal op te schalen. Wanneer u omlaag schaalt, draait u de volgorde om: schaal eerst de primaire omlaag en schaal vervolgens de secundaire waarde omlaag. Wanneer u een database schaalt naar een andere servicelaag, wordt deze aanbeveling afgedwongen.

Deze reeks wordt specifiek aanbevolen om te voorkomen dat het probleem waarbij de geo-secundaire bij een lagere SKU overbelast raakt en opnieuw moet worden gezaaid tijdens een upgrade- of downgradeproces. U kunt dit probleem ook vermijden door het primaire exemplaar alleen-lezen te maken. Dit gaat ten koste van alle lezen/schrijven-werkbelastingen die zijn gekoppeld aan het primaire exemplaar.

Notitie

Als u een geo-secundaire hebt gemaakt als onderdeel van de configuratie van de failovergroep, wordt het afgeraden om de geo-secundaire laag omlaag te schalen. Dit is om ervoor te zorgen dat uw gegevenslaag voldoende capaciteit heeft om uw normale workload te verwerken na een geo-failover.

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 uitvalt. Om kritieke transacties te beschermen tegen gegevensverlies, kan een toepassingsontwikkelaar de sp_wait_for_database_copy_sync opgeslagen procedure direct na het doorvoeren van de transactie aanroepen. 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.

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 het moment van de oproep.

Machtigingen

Machtigingen voor een failovergroep worden beheerd via op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC).

Schrijftoegang van Azure RBAC is nodig voor het maken en beheren van failovergroepen. De rol SQL Server Inzender beschikt over alle benodigde machtigingen voor het beheren van failovergroepen.

Raadpleeg voor specifieke machtigingsbereiken hoe u groepen voor automatische failover configureert in Azure SQL Database.

Beperkingen

Houd rekening met de volgende beperkingen:

  • Failovergroepen kunnen niet tussen twee servers in dezelfde Azure-regio worden gemaakt.
  • De naam van failovergroepen kan niet worden gewijzigd. U moet de groep verwijderen en opnieuw maken met een andere naam.
  • De naam van de database wordt niet ondersteund voor databases in een failovergroep. U moet de failovergroep tijdelijk verwijderen om de naam van een database te kunnen wijzigen of de database uit de failovergroep te verwijderen.

Failovergroepen programmatisch beheren

Zoals eerder besproken, kunnen groepen voor automatische failover ook programmatisch worden beheerd met behulp van Azure PowerShell, Azure CLI en REST API. In de volgende tabellen wordt de set opdrachten beschreven die beschikbaar zijn. Actieve geo-replicatie bevat een set Azure Resource Manager API's voor beheer, waaronder de Azure SQL Database REST API en Azure PowerShell cmdlets. Deze API's vereisen het gebruik van resourcegroepen en bieden ondersteuning voor op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC). Zie Op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) voor meer informatie over het implementeren van toegangsrollen.

Cmdlet Beschrijving
New-AzSqlDatabaseFailoverGroup Met deze opdracht maakt u een failovergroep en registreert u deze op zowel primaire als secundaire servers
Remove-AzSqlDatabaseFailoverGroup Hiermee verwijdert u een failovergroep van de server
Get-AzSqlDatabaseFailoverGroup Hiermee wordt de configuratie van een failovergroep opgehaald
Set-AzSqlDatabaseFailoverGroup Hiermee wijzigt u de configuratie van een failovergroep
Switch-AzSqlDatabaseFailoverGroup Hiermee wordt failover van een failovergroep naar de secundaire server geactiveerd
Add-AzSqlDatabaseToFailoverGroup Een of meer databases toevoegen aan een failovergroep

Volgende stappen