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 groepen voor automatische failover met Azure SQL Database en enkele aanbevolen procedures.

Raadpleeg Groep voor automatische failover configureren om aan de slag te gaan. Zie de zelfstudie voor groepen voor automatische failover voor een end-to-end-ervaring.

Notitie

Overzicht

Met de functie 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 bovenop de functie voor actieve 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 een andere niet-geplande gebeurtenis die leidt tot volledig of gedeeltelijk verlies van de SQL Database of SQL Managed Instance beschikbaarheid in de primaire regio. Dit zijn meestal storingen die niet automatisch kunnen worden verzacht door de ingebouwde infrastructuur voor hoge beschikbaarheid. Voorbeelden van geofailovertriggers zijn natuurrampen of incidenten die worden veroorzaakt doordat een tenant of besturingsring offline is vanwege een geheugenlek van een besturingssysteemkernel op rekenknooppunten. Zie Azure SQL hoge beschikbaarheid voor meer informatie.

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-lezenwerkbelastingen te offloaden. Gebruik de alleen-lezen-listener om alleen-lezen verkeer om te leiden naar een leesbare secundaire database.

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 worden gerouteerd naar de huidige primaire. Of u nu handmatige of automatische failoveractivering gebruikt, met een geo-failover worden alle secundaire databases in de groep overgeschakeld 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

Voor een volledige bedrijfscontinuïteit is het toevoegen van regionale databaseredundantie slechts een onderdeel van de oplossing. Voor het end-to-end herstellen van een toepassing (service) na een catastrofale fout moet alle onderdelen van de service en afhankelijke services worden hersteld. Voorbeelden van deze onderdelen zijn de clientsoftware (bijvoorbeeld een browser met een aangepast JavaScript), web-front-ends, opslag en DNS. Het is essentieel dat alle onderdelen bestand zijn tegen dezelfde fouten en beschikbaar komen binnen de RTO (Recovery Time Objective) van uw toepassing. Daarom moet u alle afhankelijke services identificeren en inzicht hebben in de garanties en mogelijkheden die ze bieden. Vervolgens moet u de juiste stappen ondernemen om ervoor te zorgen dat uw service werkt tijdens de failover van de services waarvan deze afhankelijk is.

Terminologie en mogelijkheden

  • Failovergroep (FOG)

    Een failovergroep is een benoemde groep databases die wordt beheerd door één server die als eenheid een failover naar een andere Azure-regio kan uitvoeren 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 globaal 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 regio mag 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 er automatisch een secundaire database gemaakt met dezelfde editie en rekenkracht 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 bevat 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 in elastische pool toevoegen aan 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 database 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 voor het hosten van de secundaire databases die door de failovergroep worden gemaakt. 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 bevat op een server die geen deel uitmaakt van de failovergroep, wordt er een nieuwe secundaire database gemaakt in de secundaire pool.

  • Listener voor lezen/schrijven van failovergroep

    Een DNS CNAME-record die verwijst naar de huidige primaire. Deze wordt automatisch gemaakt wanneer de failovergroep wordt gemaakt en stelt de lees-schrijfworkload in staat om op transparante wijze opnieuw verbinding te maken met de primaire groep wanneer de primaire groep na een failover wordt 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.

  • Alleen-lezen-listener voor failovergroep

    Een DNS CNAME-record die verwijst naar de huidige secundaire. Deze wordt automatisch gemaakt wanneer de failovergroep wordt gemaakt en stelt de ALLEEN-lezen SQL-workload in staat om transparant verbinding te maken met de secundaire workload wanneer de secundaire wijziging na een failover wordt uitgevoerd. 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 kan onafhankelijk van elkaar worden overgeschakeld. Als uw tenant-per-database-toepassing is geïmplementeerd in meerdere regio's en gebruikmaakt van elastische pools, kunt u deze mogelijkheid gebruiken om primaire en secundaire databases in elke pool te combineren. Op deze manier kunt u de impact van een storing op slechts enkele tenantdatabases verminderen.

  • Beleid voor automatische failover

    Standaard wordt een failovergroep geconfigureerd met een beleid voor automatische failover. 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 geo-failover wilt beheren vanuit de toepassing of handmatig, kunt u het beleid voor automatische failover uitschakelen.

    Notitie

    Omdat verificatie van de schaal van de storing en hoe snel deze kan worden verzacht menselijke acties omvat, kan de respijtperiode niet lager zijn dan één uur en kan de exacte tijd van de failover enigszins afwijken van de respijtperiode die is ingesteld. Deze beperking geldt voor alle databases in de failovergroep, ongeacht de status van de gegevenssynchronisatie.

  • Failoverbeleid voor alleen-lezen

    De failover van de alleen-lezen-listener is standaard uitgeschakeld. Het zorgt ervoor dat de prestaties van de primaire 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 kunt gebruiken voor zowel alleen-lezen- als alleen-lezen-schrijvenverkeer ten koste van de mogelijke prestatievermindering van de primaire, kunt u failover inschakelen voor de alleen-lezen-listener door de AllowReadOnlyFailoverToPrimary eigenschap te configureren. In dat geval wordt het alleen-lezen verkeer automatisch omgeleid naar de primaire als het secundaire verkeer niet beschikbaar is.

    Notitie

    De AllowReadOnlyFailoverToPrimary eigenschap heeft alleen effect als beleid voor automatische failover is ingeschakeld en een automatische geo-failover is geactiveerd. Als de eigenschap in dat geval is ingesteld op Waar, wordt de nieuwe primaire sessie gebruikt voor zowel lezen/schrijven als alleen-lezensessies.

  • Geplande failover

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

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

    Notitie

    Als een database OLTP-objecten in het geheugen bevat, moeten de primaire databases en de doeldatabases voor secundaire geo-replica's overeenkomende servicelagen hebben, omdat OLTP-objecten in het geheugen altijd in het geheugen worden gehydrateerd. Een lagere servicelaag in de doeldatabase voor geo-replica's kan leiden tot problemen met onvoldoende geheugen. Als dit gebeurt, kan de betrokken geo-secundaire databasereplica in een beperkte alleen-lezenmodus worden geplaatst, de modus oltp-controle in het geheugen . Alleen-lezen tabelquery's zijn toegestaan, maar alleen-lezen in-memory OLTP-tabelquery's zijn niet toegestaan op de betrokken geo-secundaire databasereplica. Geplande failover wordt geblokkeerd als alle replica's in de geo-secundaire database zich in de modus Alleen controlepunt bevinden. Niet-geplande failover kan mislukken vanwege problemen met onvoldoende geheugen. U kunt dit voorkomen door de servicelaag van de secundaire database bij te werken zodat deze overeenkomt met de primaire database tijdens de geplande failover. Upgrades van de servicelaag kunnen bewerkingen van de gegevensgrootte zijn en het kan even duren voordat deze is voltooid.

  • Niet-geplande failover

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

  • Handmatige failover

    U kunt een geo-failover op elk gewenst moment handmatig initiëren, ongeacht de configuratie van de automatische failover. Tijdens een storing die van invloed is op de primaire, als automatisch failoverbeleid niet is geconfigureerd, is een handmatige failover vereist om de secundaire rol te promoveren naar de primaire rol. U kunt een geforceerde (ongeplande) of beschrijvende (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 connectiviteit met de nieuwe primaire server te garanderen.

  • 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 met beleid voor automatische failover gebruikt, 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 enkele 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 toont een typische configuratie van een geografisch redundante cloudtoepassing met behulp van meerdere databases en een groep voor automatische failover.

Wanneer u een service ontwerpt met het oog op bedrijfscontinuïteit, volgt u de algemene richtlijnen en best practices die in dit artikel worden beschreven. Wanneer u een failovergroep configureert, moet u ervoor zorgen dat verificatie en netwerktoegang op de secundaire groep zo zijn ingesteld dat deze correct werken na een geo-failover, wanneer de geo-secundaire de nieuwe primaire wordt. Zie SQL Database beveiliging na herstel na noodgeval voor meer informatie. Zie Ontwerpen van cloudoplossingen voor herstel na noodgevallen met actieve geo-replicatie voor meer informatie over het ontwerpen van oplossingen voor herstel na noodgevallen.

Zie Herstel naar een bepaald tijdstip (PITR) voor meer informatie over het gebruik van herstel naar een bepaald tijdstip met failovergroepen.

Eerste seeding

Wanneer u databases of elastische pools toevoegt aan een failovergroep, vindt er een eerste seedingfase plaats voordat de gegevensreplicatie wordt gestart. De eerste seedingfase is de langste en duurste bewerking. Zodra de eerste seeding is voltooid, worden de 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 een failover uit te voeren voor meerdere databases

Een of meer failovergroepen kunnen worden gemaakt tussen twee servers in verschillende regio's (primaire en secundaire servers). Elke groep kan een of meer databases bevatten die als een eenheid worden hersteld voor het geval alle of sommige primaire databases niet meer 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 groep 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. Deze naam verandert niet na een failover. Opmerking: de failover omvat het bijwerken van de DNS-record, zodat de clientverbindingen pas worden omgeleid naar de nieuwe primaire server nadat de DNS-cache van de client is vernieuwd. De TTL (Time to Live) van de DNS-record voor de primaire en secundaire listener is 30 seconden.

De alleen-lezenlistener (secundair) gebruiken

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

In de servicelagen Premium, Bedrijfskritiek en Hyperscale ondersteunt SQL Database het gebruik van alleen-lezenreplica's voor het offloaden van alleen-lezen queryworkloads 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 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 zijn overgeschakeld naar de secundaire regio (DR), kan de latentie tussen de afhankelijke onderdelen toenemen. Om de impact van hogere latentie op de prestaties van de toepassing te voorkomen, zorgt u voor de redundantie van alle onderdelen van de toepassing in de DR-regio, volgt u deze netwerkbeveiligingsrichtlijnen en organiseert u de geo-failover van relevante toepassingsonderdelen samen met de database.

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 door GracePeriodWithDataLossHours voordat een automatische geo-failover wordt gestart. De standaardwaarde is 1 uur. Dit begunstigt de beschikbaarheid van databases boven gegevensverlies. Als u GracePeriodWithDataLossHours een groter aantal instelt, bijvoorbeeld 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 DTU's of minder, of 8 vCores of minder, en meer dan 250 databases, kunnen problemen ondervinden, waaronder langere geplande geo-failovers en verminderde prestaties. Deze problemen treden waarschijnlijk op bij schrijfintensieve werkbelastingen, wanneer geo-replica's op grote schaal worden gescheiden door geografie of wanneer meerdere secundaire geo-replica's worden gebruikt voor elke database. Een symptoom van deze problemen is een toename van de vertraging van geo-replicatie in de loop van de tijd, wat mogelijk leidt tot groter gegevensverlies bij een storing. Deze vertraging kan worden bewaakt met behulp van sys.dm_geo_replication_link_status. Als deze problemen optreden, omvat de beperking het omhoog schalen 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 wordt beperkt tot een specifiek onderdeel of specifieke onderdelen, zoals een VM, webservice, enzovoort. Deze vereiste brengt enkele uitdagingen met zich mee 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 voor een virtueel netwerk slechts op één Azure-regio van toepassing is. Het eindpunt stelt andere regio's niet in staat om communicatie van het subnet te accepteren. Daarom kunnen alleen de clienttoepassingen die in dezelfde regio zijn geïmplementeerd, verbinding maken met de primaire database. Omdat een geo-failover ertoe leidt dat de SQL Database clientsessies worden omgeleid naar een server in een andere (secundaire) regio, mislukken deze sessies als ze 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. Start handmatige geo-failover wanneer de storing wordt gedetecteerd. Deze optie is geoptimaliseerd voor de toepassingen die consistente latentie tussen de front-end en de gegevenslaag vereisen en ondersteunt herstel wanneer de front-end, gegevenslaag of beide worden beïnvloed door de storing.

Notitie

Als u de alleen-lezen-listener gebruikt om een alleen-lezen werkbelasting te verdelen, moet u ervoor zorgen dat deze workload wordt uitgevoerd op een VM 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 binnenkomend verkeer toe te staan vanaf 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 gaat ervan uit 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 zorgen voor geografische redundantie 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 om eerst de geo-secundaire locatie omhoog te schalen en vervolgens de primaire op te schalen. Wanneer u omlaag schaalt, keert u de volgorde om: schaal eerst de primaire laag omlaag en schaal vervolgens de secundaire laag omlaag. Wanneer u een database schaalt naar een andere servicelaag, wordt deze aanbeveling afgedwongen.

Deze reeks wordt specifiek aanbevolen om het probleem te voorkomen waarbij de geo-secundaire op een lagere SKU overbelast raakt en opnieuw moet worden geseed 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 locatie hebt gemaakt als onderdeel van de configuratie van de failovergroep, wordt het afgeraden om de geo-secundaire laag omlaag te schalen. Zo zorgt u ervoor dat uw gegevenslaag voldoende capaciteit heeft om uw normale workload te verwerken nadat een geo-failover is geactiveerd.

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 fout uitvalt. Om kritieke transacties te beschermen tegen gegevensverlies, kan een toepassingsontwikkelaar de sp_wait_for_database_copy_sync opgeslagen procedure aanroepen direct na het doorvoeren van de transactie. Aanroepen sp_wait_for_database_copy_sync blokkeert de aanroepende thread totdat de laatste doorgevoerde transactie is verzonden en beveiligd in het transactielogboek van de secundaire database. Er wordt echter niet gewacht tot de verzonden transacties opnieuw worden afgespeeld (opnieuw) 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 procedureaanroep kan aanzienlijk zijn en is afhankelijk van de grootte van het nog niet verzonden transactielogboek op het primaire tijdstip van de aanroep.

Machtigingen

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

Azure RBAC-schrijftoegang is nodig om failovergroepen te maken en te beheren. De rol SQL Server Inzender heeft alle benodigde machtigingen voor het beheren van failovergroepen.

Zie Groepen voor automatische failover configureren in Azure SQL Database voor specifieke machtigingsbereiken.

Beperkingen

Houd rekening met de volgende beperkingen:

  • Failovergroepen kunnen niet worden gemaakt tussen twee servers in dezelfde Azure-regio.
  • Namen van failovergroepen kunnen niet worden gewijzigd. U moet de groep verwijderen en opnieuw maken met een andere naam.
  • Namen databases wijzigen wordt niet ondersteund voor databases in een failovergroep. U moet de failovergroep tijdelijk verwijderen om de naam van een database te 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 beschikbare opdrachten beschreven. 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 ondersteunen 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 een failover van een failovergroep naar de secundaire server geactiveerd
Add-AzSqlDatabaseToFailoverGroup Hiermee voegt u een of meer databases toe aan een failovergroep

Volgende stappen