Delen via

Actieve geo-replicatie

Van toepassing op:Azure SQL Database

In dit artikel vindt u een overzicht van de actieve geo-replicatiefunctie voor Azure SQL Database, waarmee u continu gegevens kunt repliceren van een primaire database naar een leesbare secundaire database. De leesbare secundaire database kan zich in dezelfde Azure-regio bevinden als de primaire of, vaker, in een andere regio. Dit soort leesbare secundaire database wordt ook wel een geo-secundaire of geo-replica genoemd.

Actieve geo-replicatie wordt per database geconfigureerd. Als u een failover wilt uitvoeren voor een groep databases of als voor uw toepassing een stabiel verbindingseindpunt is vereist, kunt u in plaats daarvan failovergroepen overwegen.

U kunt ook een SQL-database migreren met actieve geo-replicatie.

Overzicht

Actieve geo-replicatie is ontworpen als een oplossing voor bedrijfscontinuïteit. Met actieve georeplicatie kunt u snel noodherstel van afzonderlijke databases uitvoeren als er een regionale ramp of een grootschalige storing is. Zodra geo-replicatie is ingesteld, kunt u een geo-failover initiëren naar een geo-secundair in een andere Azure-regio. De geo-failover wordt programmatisch geïnitieerd door de toepassing of handmatig door de gebruiker.

In het volgende diagram ziet u een typische configuratie van een geografisch redundante cloudtoepassing met behulp van actieve georeplicatie.

Diagram van actieve geo-replicatie.

Als uw primaire database om welke reden dan ook mislukt, kunt u een geo-failover starten naar een van uw secundaire databases. Wanneer een secundair wordt gepromoveerd naar de primaire rol, worden alle andere secundairen automatisch gekoppeld aan de nieuwe primaire.

U kunt geo-replicatie beheren en een geo-failover initiëren met behulp van een van de volgende methoden:

Actieve geo-replicatie maakt gebruik van de Always On-beschikbaarheidsgroeptechnologie om het transactielogboek dat op de primaire replica is gegenereerd, asynchroon te repliceren naar alle georeplica's. Hoewel op een bepaald moment een secundaire database iets achter kan blijven bij de primaire database, zijn de gegevens op een secundaire database gegarandeerd transactieconsistent. Met andere woorden, wijzigingen die zijn aangebracht door niet-vastgelegde transacties zijn niet zichtbaar.

Opmerking

Actieve georeplicatie repliceert wijzigingen door het transactielogboek van de database te streamen van de primaire replica naar secundaire replica's. Het heeft niets te maken met transactionele replicatie, waarbij wijzigingen worden gerepliceerd door DML-opdrachten (invoegen, bijwerken, verwijderen) uit te voeren op abonnees.

Geo-replicatie zorgt voor regionale redundantie. Regionale redundantie stelt toepassingen in staat om snel te herstellen van een permanent verlies van een volledige Azure-regio of delen van een regio, veroorzaakt door natuurrampen, catastrofale menselijke fouten of kwaadwillende handelingen. RPO voor geo-replicatie is te vinden in Overzicht van bedrijfscontinuïteit met Azure SQL Database.

In de volgende afbeelding ziet u een voorbeeld van actieve geo-replicatie die is geconfigureerd met een primaire in de regio VS - west 2 en een geo-secundair in de regio VS - oost.

Schermafbeelding van de Azure Portal met een SQL DB-georeplicatierelatie.

Naast herstel na noodgevallen kan actieve georeplicatie worden gebruikt in de volgende scenario's:

  • Databasemigratie: U kunt actieve georeplicatie gebruiken om een database van de ene server naar de andere te migreren met minimale downtime.
  • Toepassingsupgrades: u kunt een extra secundaire kopie maken als een failback-kopie tijdens toepassingsupgrades.

Om volledige bedrijfscontinuïteit te bereiken, is het toevoegen van regionale redundantie van de database slechts een deel 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. Zie Wereldwijd beschikbare services ontwerpen met behulp van Azure SQL Database voor meer informatie over het ontwerpen van oplossingen voor herstel na noodgevallen.

Terminologie en mogelijkheden

  • Automatische asynchrone replicatie

    U kunt alleen een geo-secundair maken voor een bestaande database. De geo-secundaire kan worden gemaakt op elke logische server, anders dan de server met de primaire database. Nadat de geosecundaire replica is gemaakt, wordt deze gevuld met de gegevens van de primaire database. Dit proces staat bekend als zaaien. Nadat een geo-secundair is gemaakt en gezaaid, worden updates van de primaire database automatisch en asynchroon gerepliceerd naar de geo-secundaire replica. Asynchrone replicatie betekent dat transacties worden vastgelegd in de primaire database voordat ze worden gerepliceerd.

  • Leesbare geo-secundaire replica's

    Een toepassing kan toegang krijgen tot een geo-secundaire replica om alleen-lezen query's uit te voeren met dezelfde of verschillende beveiligings-principals die worden gebruikt voor toegang tot de primaire database. Zie Alleen-lezen replica's gebruiken om alleen-lezen queryworkloads te offloaden voor meer informatie.

    Belangrijk

    U kunt georeplicatie gebruiken om secundaire replica's te maken in dezelfde regio als de primaire. U kunt deze secundaire scenario's gebruiken om te voldoen aan uitschalingsscenario's in dezelfde regio. Een secundaire replica in dezelfde regio biedt echter geen extra veerkracht tegen catastrofale storingen of grootschalige uitval en is daarom geen geschikt failover-doel voor noodhersteldoeleinden. Het garandeert ook geen isolatie van de beschikbaarheidszone. Gebruik redundante configuratie voor bedrijfskritieke of Premium-servicelagen of redundante configuratie voor algemene servicelaagzones om isolatie van beschikbaarheidszones te bereiken.

  • failover (geen gegevensverlies)

    Failover wisselt de rollen van primaire en geo-secundaire databases na het voltooien van de volledige gegevenssynchronisatie, zodat er geen gegevensverlies is. De duur van de failover is afhankelijk van de grootte van het transactielogboek op de primaire die moet worden gesynchroniseerd met de geo-secundaire. Failover is ontworpen voor de volgende scenario's:

    • Voer DR-oefeningen uit in productie wanneer het gegevensverlies niet acceptabel is
    • De database verplaatsen naar een andere regio
    • Zet de database terug naar de primaire regio nadat de storing is verholpen (ook wel failback genoemd).

  • geforceerde failover (mogelijk gegevensverlies)

    Geforceerde failover schakelt de geo-secundaire rol onmiddellijk over naar de primaire rol zonder te wachten op synchronisatie met de primaire. Alle transacties die op de primaire zijn uitgevoerd, maar nog niet zijn gerepliceerd naar de secundaire, gaan verloren. Deze bewerking is ontworpen als een herstelmethode tijdens storingen wanneer de primaire niet toegankelijk is, maar de beschikbaarheid van de database snel moet worden hersteld. Wanneer de oorspronkelijke primaire weer online is, wordt deze automatisch opnieuw verbonden, opnieuw gezaaid met behulp van de huidige gegevens van de primaire en wordt deze de nieuwe geo-secundaire.

    Belangrijk

    Na een failover of geforceerde failover wordt het verbindingseindpunt voor de nieuwe primaire code gewijzigd omdat de nieuwe primaire failover zich nu op een andere logische server bevindt.

  • Meerdere leesbare geo-secondaries

    Er kunnen maximaal vier geo-secondaries worden gemaakt voor een primaire. Als er slechts één secundaire is en deze mislukt, loopt de toepassing een hoger risico totdat er een nieuwe secundaire wordt gemaakt. Als er meerdere secundaire apparaten zijn, blijft de toepassing beveiligd, zelfs als een van de secundaire apparaten mislukt. Extra secundaire workloads kunnen ook worden gebruikt om alleen-lezen workloads uit te schalen.

    Aanbeveling

    Als u actieve georeplicatie gebruikt om een wereldwijd gedistribueerde toepassing te bouwen en alleen-lezen toegang moet bieden tot gegevens in meer dan vier regio's, kunt u een secundaire of een secundaire versie maken (een proces dat bekend staat als ketening) om extra georeplica's te maken. De replicatievertraging op geketende geo-replica's kan hoger zijn dan op geo-replica's die rechtstreeks zijn verbonden met de primaire. Het instellen van geketende georeplicatietopologieën wordt alleen programmatisch ondersteund en niet vanuit Azure Portal.

  • Geo-replicatie van databases in een elastische pool

    Elke geo-secundaire kan een enkele database zijn of een database in een elastische pool. De keuze voor de elastische pool voor elke geo-secundaire database is afzonderlijk en is niet afhankelijk van de configuratie van een andere replica in de topologie (primair of secundair). Elke elastische pool bevindt zich in één logische server. Omdat databasenamen op een logische server uniek moeten zijn, kunnen meerdere geo-secondaries van dezelfde primaire server nooit een elastische pool delen.

  • Door de gebruiker gecontroleerde geo-failover en failback

    Een geo-secundair instrument dat de eerste seeding heeft voltooid, kan op elk gewenst moment door de toepassing of de gebruiker expliciet worden overgeschakeld naar de primaire rol (failover). Tijdens een storing waarbij de primaire ontoegankelijk is, kan alleen geforceerde failover worden gebruikt, waardoor een geo-secundair onmiddellijk wordt gepromoot tot de nieuwe primaire. Wanneer de storing is verholpen, maakt het systeem automatisch van de herstelde primaire een geo-secundair en brengt deze up-to-date met de nieuwe primaire. Vanwege de asynchrone aard van geo-replicatie kunnen recente transacties verloren gaan tijdens geforceerde failovers als de primaire mislukt voordat deze transacties worden gerepliceerd naar een geo-secundaire. Wanneer een failover wordt uitgevoerd voor een primaire met meerdere geo-secondaries, worden replicatierelaties automatisch opnieuw geconfigureerd en worden de resterende geo-secondaries gekoppeld aan de nieuw gepromoveerde primaire, zonder dat er tussenkomst van de gebruiker nodig is. Nadat de storing die de geo-failover heeft veroorzaakt, is verholpen, kan het wenselijk zijn om de primaire terug te zetten naar de oorspronkelijke regio. Voer hiervoor een handmatige failover uit.

  • Stand-by replica

    Als uw secundaire replica alleen wordt gebruikt voor herstel na noodgevallen (DR) en geen lees- of schrijfworkloads heeft, kunt u de replica aanwijzen als stand-by om te besparen op licentiekosten.

Voorbereiden op geo-failover

Om ervoor te zorgen dat uw toepassing onmiddellijk toegang heeft tot de nieuwe primaire server na geo-failover, controleert u of verificatie en netwerktoegang voor uw secundaire server correct zijn geconfigureerd. Zie Azure SQL Database-beveiliging configureren en beheren voor geo-herstel of failover-voor meer informatie. Controleer ook of het bewaarbeleid voor back-ups in de secundaire database overeenkomt met dat van de primaire database. Deze instelling maakt geen deel uit van de database en wordt niet gerepliceerd vanuit de primaire instelling. Standaard is de geo-secundaire geconfigureerd met een standaard PITR-bewaarperiode van zeven dagen. Zie Geautomatiseerde back-ups in Azure SQL Database voor meer informatie.

Belangrijk

Als uw database lid is van een failovergroep, kunt u de failover niet starten met de opdracht geo-replicatiefailover. Gebruik de failover-opdracht voor de groep. Als u een failover van een afzonderlijke database moet uitvoeren, moet u deze eerst uit de failovergroep verwijderen. Zie Failovergroepen voor meer informatie.

Geo-secundair configureren

Zowel de primaire als de geosecundaire moeten dezelfde servicelaag hebben. Het wordt ook sterk aanbevolen dat de geo-secundaire wordt geconfigureerd met dezelfde redundantie van back-upopslag, rekenlaag (ingericht of serverloos) en rekengrootte (DTU's of vCores) als de primaire. Als de primaire een zware schrijfworkload ondervindt, kan een geo-secundaire met een lagere rekengrootte deze mogelijk niet bijhouden. Dat veroorzaakt replicatievertraging op de geo-secundaire, en kan er uiteindelijk toe leiden dat de geo-secundaire niet beschikbaar is. Om deze risico's te beperken, verlaagt actieve georeplicatie de transactielogsnelheid van de primaire indien nodig om de secundaire te laten inhalen.

Een ander gevolg van een ongebalanceerde geo-secundaire configuratie is dat na failover de prestaties van de applicatie kunnen lijden onder onvoldoende rekencapaciteit van de nieuwe primaire. In dat geval is het noodzakelijk om de database op te schalen om over voldoende resources te beschikken, wat veel tijd kan kosten, en een failover met hoge beschikbaarheid vereist aan het einde van het opschalingsproces, wat de workloads van applicaties kan onderbreken.

Als u besluit om de geo-secundaire met een andere configuratie te maken, moet u de log-IO-snelheid op de primaire in de loop van de tijd controleren. Hiermee kunt u een schatting maken van de minimale rekenkracht van de geo-secundaire die nodig is om de replicatiebelasting te ondersteunen. Als uw primaire database bijvoorbeeld P6 (1000 DTU) is en de logboek-IO op 50%wordt gehandhaafd, moet de geo-secundaire database ten minste P4 (500 DTU) zijn. Als u historische log-IO-gegevens wilt ophalen, gebruikt u de sys.resource_stats weergave. Als u recente log-IO-gegevens wilt ophalen met een hogere granulariteit die kortetermijnpieken beter weerspiegelt, gebruikt u de weergave sys.dm_db_resource_stats .

Aanbeveling

IO-beperking in het transactielogboek kan optreden:

  • Als de geo-secundair een lagere rekengrootte heeft dan de primaire. Zoek naar de HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO wacht, typ sys.dm_exec_requests en sys.dm_os_wait_stats databaseweergaven.
  • Redenen die niets te maken hebben met de rekengrootte. Zie Beheer van transactielogtarieven voor meer informatie, waaronder wachttypen voor verschillende soorten IO-beperking in logboeken.

Standaard is de redundantie van de back-upopslag van de geo-secundaire hetzelfde als voor de primaire database. U kunt ervoor kiezen om een geo-secundair te configureren met een andere redundantie voor back-upopslag. Back-ups worden altijd gemaakt in de primaire database. Als de secundaire is geconfigureerd met een andere redundantie voor back-upopslag, worden na een geo-failover, wanneer de geo-secundaire wordt gepromoveerd naar de primaire, nieuwe back-ups opgeslagen en gefactureerd op basis van het type opslag (RA-GRS, ZRS, LRS) dat is geselecteerd op de nieuwe primaire (vorige secundaire).

Bespaar kosten met de stand-by replica

Als uw secundaire replica wordt gebruikt alleen voor herstel na noodgevallen en geen lees- of schrijfworkloads heeft, kunt u besparen op licentiekosten door de database voor stand-by aan te wijzen wanneer u een nieuwe actieve geo-replicatierelatie configureert.

Bekijk licentievrije stand-bykopie voor meer informatie.

Geo-replicatie tussen abonnementen

  • U kunt de Azure Portal gebruiken om actieve georeplicatie in te stellen voor abonnementen, zolang beide abonnementen zich in dezelfde Microsoft Entra-tenant bevinden.

  • Het maken van een geo-secundair abonnement op een logische server in dezelfde of een andere Microsoft Entra-tenant wordt niet ondersteund wanneer Microsoft Entra-verificatie is ingeschakeld op de primaire of secundaire logische server en het maken wordt geprobeerd met behulp van een Microsoft Entra-id-gebruiker.

Zie Zelfstudie: Actieve geo-replicatie en failover configureren (Azure SQL Database) voor methoden en stapsgewijze instructies.

Privé-eindpunten

Het toevoegen van een geo-secundair met behulp van T-SQL wordt niet ondersteund wanneer u verbinding maakt met de primaire server via een privé-eindpunt.

  • Als een privé-eindpunt is geconfigureerd, maar openbare netwerktoegang is toegestaan, wordt het toevoegen van een geo-secundair ondersteund wanneer het is verbonden met de primaire server vanaf een openbaar IP-adres.
  • Zodra een geo-secundair is toegevoegd, kan de toegang tot het openbare netwerk worden geweigerd.

Aanmeldingsgegevens en firewallregels gesynchroniseerd houden

Wanneer u openbare netwerktoegang gebruikt om verbinding te maken met de database, raden we u aan IP-firewallregels op databaseniveau te gebruiken voor geo-gerepliceerde databases. Deze regels worden gerepliceerd met de database, die ervoor zorgt dat alle geo-secondaries dezelfde IP-firewallregels hebben als de primaire. Deze aanpak elimineert de noodzaak voor klanten om firewallregels handmatig te configureren en te onderhouden op servers die de primaire en secundaire databases hosten. Op dezelfde manier zorgt het gebruik van ingesloten databasegebruikers voor gegevenstoegang ervoor dat zowel primaire als secundaire databases altijd dezelfde verificatiereferenties hebben. Op deze manier zijn er na een geo-failover geen onderbrekingen als gevolg van mismatches in authenticatiegegevens. Als u aanmeldingen en gebruikers gebruikt (in plaats van ingesloten gebruikers), moet u extra stappen ondernemen om ervoor te zorgen dat dezelfde aanmeldingen bestaan voor uw secundaire database. Zie Azure SQL Database-beveiliging configureren en beheren voor geo-herstel of failover voor meer informatie over de configuratie.

Primaire database schalen

U kunt de primaire database omhoog of omlaag schalen naar een andere rekengrootte (binnen dezelfde servicelaag) zonder de verbinding met geo-secundairen te verbreken. Bij het opschalen raden we u aan eerst de geo-secundaire schaal op te schalen en vervolgens de primaire omhoog. Wanneer u omlaag schaalt, keert u de volgorde om: schaal eerst de primaire omlaag en schaal vervolgens de secundaire waarde omlaag.

Voor informatie over failovergroepen raadpleegt u De schaal van een replica in een failovergroep.

Verlies van kritieke gegevens voorkomen

Vanwege de hoge latentie van wide area networks maakt geo-replicatie gebruik van een asynchroon replicatiemechanisme. Asynchrone replicatie maakt de mogelijkheid van gegevensverlies onvermijdelijk als de primaire mislukt. Een toepassingsontwikkelaar kan de sp_wait_for_database_copy_sync opgeslagen procedure direct na het doorvoeren van de transactie aanroepen om kritieke transacties te beschermen tegen gegevensverlies. Het aanroepen van sp_wait_for_database_copy_sync blokkeert de oproepende thread tot de laatst doorgevoerde transactie is verzonden en gehard in het transactielogboek van de secundaire database. Het wacht ook tot de verzonden transacties opnieuw worden afgespeeld (opnieuw gedaan) 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.

Opmerking

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.

Vertraging van geo-replicatie bewaken

Als u de vertraging met betrekking tot RTO wilt bewaken, gebruikt u de kolom replication_lag_sec van sys.dm_geo_replication_link_status in de primaire database. Er wordt een vertraging in seconden weergegeven tussen de transacties die zijn doorgevoerd op de primaire en het transactielogboek op de secundaire locatie. Als de vertraging bijvoorbeeld één seconde is, betekent dit dat als de primaire op dit moment wordt beïnvloed door een storing en er een geo-failover wordt gestart, transacties die in de laatste seconde zijn vastgelegd, verloren gaan.

Als u vertraging wilt meten met betrekking tot wijzigingen in de primaire database die zijn gehard op de geosecundaire, vergelijkt u last_commit de tijd op de geosecundaire database met dezelfde waarde op de primaire.

Aanbeveling

Als replication_lag_sec op de primaire NULL is, betekent dit dat de primaire momenteel niet weet hoe ver deze achterloopt op een geo-secundaire. Dit gebeurt meestal nadat het proces opnieuw is opgestart en zou een voorbijgaande toestand moeten zijn. Overweeg een waarschuwing te sturen als replication_lag_sec voor een langere periode NULL retourneert. Dit kan erop duiden dat de geo-secundaire niet kan communiceren met de primaire vanwege een verbindingsfout.

Er zijn ook omstandigheden die ervoor kunnen zorgen dat het verschil tussen last_commit tijd op de geo-secundaire en op de primaire groot wordt. Als er bijvoorbeeld een commit wordt gedaan op de primaire na een lange periode van geen wijzigingen, zal het verschil omhoog springen naar een grote waarde voordat het snel terugkeert naar nul. Overweeg om een alert te sturen als het verschil tussen deze twee waarden lange tijd groot blijft.

Actieve georeplicatie programmatisch beheren

Actieve geo-replicatie kan ook programmatisch worden beheerd met behulp van T-SQL, Azure PowerShell en REST API. In de volgende tabellen wordt de set opdrachten beschreven die beschikbaar zijn. Actieve georeplicatie omvat een set Azure Resource Manager-API's voor beheer, waaronder de Azure SQL Database REST API en Azure PowerShell-cmdlets. Deze API's bieden ondersteuning voor op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC). Raadpleeg voor meer informatie over hoe u toegangsrollen kunt implementeren Azure rolgebaseerd toegangsbeheer (Azure RBAC).

Belangrijk

Deze T-SQL-opdrachten zijn alleen van toepassing op actieve georeplicatie en niet op failovergroepen.

Opdracht Beschrijving
ALTER DATABASE Gebruik het argument SECUNDAIR OP SERVER TOEVOEGEN om een secundaire database voor een bestaande database te maken en de gegevensreplicatie te starten
ALTER DATABASE Gebruik FAILOVER of FORCE_FAILOVER_ALLOW_DATA_LOSS om een secundaire database om te zetten naar primair om failover te starten
ALTER DATABASE Gebruik REMOVE SECONDARY ON SERVER om een gegevensreplicatie tussen een SQL-database en de opgegeven secundaire database te beëindigen.
sys.geo_replication_links Retourneert informatie over alle bestaande replicatiekoppelingen voor elke database op een server.
sys.dm_geo_replication_link_status Hiermee haalt u de laatste replicatietijd, de laatste replicatievertraging en andere informatie over de replicatiekoppeling voor een bepaalde database op.
sys.dm_operation_status Toont de status voor alle databasebewerkingen, inclusief wijzigingen in replicatiekoppelingen.
sys.sp_wait_for_database_copy_sync Zorgt ervoor dat de toepassing wacht totdat alle vastgelegde transacties zijn vastgelegd in het transactielogboek van een geo-secundaire.

Verwante inhoud

Actieve georeplicatie configureren:

Andere inhoud over bedrijfscontinuïteit: