Actieve geo-replicatie maken en gebruiken - Azure SQL Database

VAN TOEPASSING OP: Azure SQL Database

Actieve geo-replicatie is een Azure SQL Database waarmee u leesbare secundaire databases van afzonderlijke databases op een server in hetzelfde of een ander datacenter (regio) kunt maken.

Notitie

Actieve geo-replicatie voor Azure SQL Hyperscale is nu beschikbaar als openbare preview. Tot de huidige beperkingen behoren: slechts één geo-secundaire regio in dezelfde of een andere regio, geforceerd en geplande failover wordt momenteel niet ondersteund, database herstellen vanaf geo-secundair niet ondersteund, het gebruik van een geo-secundaire database als de brondatabase voor Database Copy of als de primaire database voor een andere geo-secundaire database wordt niet ondersteund. Als u het geo-secundaire beschrijfbaar wilt maken, kunt u dit doen door de geo-replicatiekoppeling te verbreken met de onderstaande stappen:

  1. Maak van de secundaire database een zelfstandige database voor lezen/schrijven met behulp van de cmdlet Remove-AzSqlDatabaseSecondary. Alle gegevenswijzigingen die zijn doorgevoerd naar de primaire maar nog niet zijn gerepliceerd naar de secundaire replica gaan verloren. Deze wijzigingen kunnen worden hersteld wanneer de oude primaire versie beschikbaar is, of in sommige gevallen door de oude primaire te herstellen naar het meest recente beschikbare tijdstip.
  2. Als de oude primaire versie beschikbaar is, verwijdert u deze en stelt u geo-replicatie in voor de nieuwe primaire replica (een nieuwe secundaire wordt geseed).
  3. Werk de verbindingsreeksen in uw toepassing dienovereenkomstig bij.

Notitie

Actieve geo-replicatie wordt niet ondersteund door Azure SQL Managed Instance. Gebruik voor geografische failover van exemplaren van SQL Managed Instance automatische failovergroepen.

Notitie

Zie Migrate SQL Database using active geo-replication (Migratie van sql-databases vanuit Azure Duitsland met behulp van actieve geo-replicatie) als u SQL-databases wilt migreren vanuit Azure Duitsland met behulp van actieve geo-replicatie.

Actieve geo-replicatie is ontworpen als een oplossing voor bedrijfscontinuïteit waarmee de toepassing snel herstel na noodgeval kan uitvoeren van afzonderlijke databases in geval van een regionale noodgeval of grootschalige storing. Als geo-replicatie is ingeschakeld, kan de toepassing failover naar een secundaire database in een andere Azure-regio initiëren. Er worden maximaal vier secondaries ondersteund in dezelfde of verschillende regio's en de secondaries kunnen ook worden gebruikt voor query's met alleen-lezentoegang. De failover moet handmatig worden gestart door de toepassing of de gebruiker. Na een failover heeft de nieuwe primaire een ander verbindings-eindpunt.

Notitie

Actieve geo-replicatie repliceert wijzigingen door het transactielogboek van de database te streamen. Het is niet gerelateerd aan transactionele replicatie,waarmee wijzigingen worden gerepliceerd door DML-opdrachten (INSERT, UPDATE, DELETE) uit te voeren.

Het volgende diagram illustreert een typische configuratie van een geografisch redundante cloudtoepassing met behulp van actieve geo-replicatie.

actieve geo-replicatie

Belangrijk

SQL Database ondersteunt ook groepen voor automatische failover. Zie Automatische failover-groepengebruiken voor meer informatie.

Als uw primaire database om een of andere reden mislukt of gewoon offline moet worden genomen, kunt u een failover naar een van uw secundaire databases initiëren. Wanneer failover wordt geactiveerd voor een van de secundaire databases, worden alle andere secundaire databases automatisch gekoppeld aan de nieuwe primaire database.

U kunt replicatie en failover van een afzonderlijke database of een set databases op een server of in een elastische pool beheren met behulp van actieve geo-replicatie. U kunt dit doen met behulp van:

Actieve geo-replicatie maakt gebruik van de AlwaysOn-beschikbaarheidsgroeptechnologie van de database-engine om asynchroon vastgelegde transacties op de primaire database te repliceren naar een secundaire database met behulp van isolatie van momentopnamen. Groepen voor automatische failover bieden de groepssemantiek boven op actieve geo-replicatie, maar hetzelfde asynchrone replicatiemechanisme wordt gebruikt. Hoewel de secundaire database op een bepaald moment mogelijk iets achter de primaire database ligt, hebben de secundaire gegevens gegarandeerd nooit gedeeltelijke transacties. Met regio-overschrijdende redundantie kunnen toepassingen snel herstellen van een permanent verlies van een volledig datacenter of delen van een datacenter die worden veroorzaakt door natuurrampen, onherstelbare menselijke fouten of schadelijke acties. De specifieke RPO-gegevens vindt u in Overzicht van bedrijfscontinuïteit.

Notitie

Als er een netwerkfout tussen twee regio's is, proberen we om de 10 seconden opnieuw verbinding te maken.

Belangrijk

Om ervoor te zorgen dat een kritieke wijziging in de primaire database wordt gerepliceerd naar een secundaire database voordat u een failover hebt, kunt u synchronisatie forcen om de replicatie van kritieke wijzigingen (bijvoorbeeld wachtwoordupdates) te garanderen. Geforceerd synchroniseren heeft invloed op de prestaties, omdat deze de aanroepingsthread blokkeert totdat alle vastgelegde transacties worden gerepliceerd. Zie voor meer informatie sp_wait_for_database_copy_sync. Zie voor het bewaken van de replicatievertraging tussen de primaire database en geo-secundaire database sys.dm_geo_replication_link_status.

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

geo-replicatierelatie

Omdat de secundaire databases leesbaar zijn, kunnen ze worden gebruikt voor het offloaden van alleen-lezen workloads, zoals rapportagetaken. Als u actieve geo-replicatie gebruikt, is het mogelijk om de secundaire database te maken in dezelfde regio als de primaire database, maar dit verhoogt de tolerantie van de toepassing niet voor onherstelbare fouten. Als u groepen voor automatische failover gebruikt, wordt uw secundaire database altijd in een andere regio gemaakt.

Naast herstel na noodherstel kan actieve geo-replicatie worden gebruikt in de volgende scenario's:

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

Voor echte bedrijfscontinuïteit maakt het toevoegen van database-redundantie tussen datacenters slechts deel uit van de oplossing. Als u een toepassing (service) end-to-end herstelt na een onherstelbare fout, moet u alle onderdelen herstellen waar de service deel van uit maakt en alle afhankelijke services. Voorbeelden van deze onderdelen zijn de clientsoftware (bijvoorbeeld een browser met een aangepaste JavaScript), webfront-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 krijgen 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 Cloudoplossingen ontwerpen voor herstel na noodherstel met behulp van actieve geo-replicatie voor meer informatie over het ontwerpen van oplossingen voor herstel na noodherstel.

Terminologie en mogelijkheden voor actieve geo-replicatie

  • Automatische asynchrone replicatie

    U kunt alleen een secundaire database maken door toe te voegen aan een bestaande database. De secundaire kan op elke server worden gemaakt. Na het maken wordt de secundaire database gevuld met de gegevens die zijn gekopieerd uit de primaire database. Dit proces wordt seeding genoemd. Nadat de secundaire database is gemaakt en geseed, worden updates voor de primaire database automatisch asynchroon gerepliceerd naar de secundaire database. Asynchrone replicatie betekent dat transacties worden vastgelegd op de primaire database voordat ze worden gerepliceerd naar de secundaire database.

  • Leesbare secundaire databases

    Een toepassing heeft toegang tot een secundaire database voor alleen-lezenbewerkingen met behulp van dezelfde of verschillende beveiligings-principals die worden gebruikt voor toegang tot de primaire database. De secundaire databases werken in de isolatiemodus voor momentopnamen om ervoor te zorgen dat replicatie van de updates van de primaire database (opnieuw afspelen van logboeken) niet wordt vertraagd door query's die op de secundaire database worden uitgevoerd.

Notitie

Het opnieuw afspelen van logboeken wordt vertraagd op de secundaire database als er schema-updates op de primaire database zijn. Voor de laatste is een schemavergrendeling voor de secundaire database vereist.

Belangrijk

U kunt geo-replicatie gebruiken om een secundaire database te maken in dezelfde regio als de primaire database. U kunt deze secundaire gebruiken om een load balancer te maken voor alleen-lezen workloads in dezelfde regio. Een secundaire database in dezelfde regio biedt echter geen extra fout resilience en is daarom geen geschikt failoverdoel voor herstel na noodherstel. Het garandeert ook geen isolatie van beschikbaarheidszone. Gebruik bedrijfskritieke of Premium-servicelaag met zone-redundante configuratie of een zone-redundante configuratie Algemeen servicelaag om isolatie van beschikbaarheidszone te bereiken.

  • Geplande failover

    Met geplande failover worden de rollen van primaire en secundaire databases overgezet nadat de volledige synchronisatie is voltooid. Het is een onlinebewerking die niet leidt tot gegevensverlies. De tijd van de bewerking is afhankelijk van de grootte van het transactielogboek op de primaire die moet worden gesynchroniseerd. Geplande failover is ontworpen voor de volgende scenario's: (a) voor het uitvoeren van dr-oefeningen in productie wanneer het gegevensverlies niet acceptabel is; (b) om de database naar een andere regio te verplaatsen; en (c) om de database te retourneren naar de primaire regio nadat de storing is vereengeld (failback).

  • Niet-geplande failover

    Met niet-geplande of geforceerd failover wordt de secundaire functie onmiddellijk overgezet naar de primaire rol zonder synchronisatie met de primaire rol. Alle transacties die zijn vastgelegd in de primaire maar niet gerepliceerd naar de secundaire, gaan verloren. Deze bewerking is ontworpen als een herstelmethode tijdens uitval wanneer de primaire niet toegankelijk is, maar de beschikbaarheid van de database snel moet worden hersteld. Wanneer de oorspronkelijke primaire versie weer online is, wordt deze automatisch opnieuw verbonden en wordt deze een nieuwe secundaire. Alle niet-gesynchroniseerde transacties vóór de failover blijven behouden in het back-upbestand, maar worden niet gesynchroniseerd met de nieuwe primaire transactie om conflicten te voorkomen. Deze transacties moeten handmatig worden samengevoegd met de meest recente versie van de primaire database.

  • Meerdere leesbare secondaries

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

    Notitie

    Als u actieve geo-replicatie gebruikt om een wereldwijd gedistribueerde toepassing te bouwen en alleen-lezentoegang tot gegevens in meer dan vier regio's wilt bieden, kunt u een secundaire van een secundaire toepassing maken (een proces dat ketening wordt genoemd). Op deze manier kunt u een vrijwel onbeperkte schaal van databasereplicatie bereiken. Bovendien vermindert ketening de overhead van replicatie vanuit de primaire database. De afweging is de toegenomen replicatievertraging op de meest voorkomende secundaire databases.

  • Geo-replicatie van databases in een elastische pool

    Elke secundaire database kan afzonderlijk deelnemen aan een elastische pool of zich helemaal niet in een elastische pool. De poolkeuze voor elke secundaire database is afzonderlijk en is niet afhankelijk van de configuratie van een andere secundaire database (primair of secundair). Elke elastische pool is opgenomen in één regio, waardoor meerdere secundaire databases in dezelfde topologie nooit een elastische pool kunnen delen.

  • Door de gebruiker beheerde failover en failback

    Een secundaire database kan op elk moment expliciet worden overgeschakeld naar de primaire rol door de toepassing of de gebruiker. Tijdens een echte storing moet de optie 'niet-gepland' worden gebruikt, waardoor een secundaire direct wordt gepromoot als primaire. Wanneer de primaire fout wordt hersteld en weer beschikbaar is, markeert het systeem automatisch de herstelde primaire als secundaire en brengt het systeem deze up-to-date met de nieuwe primaire. Vanwege de asynchrone aard van replicatie kan een kleine hoeveelheid gegevens verloren gaan tijdens niet-geplande failovers als een primaire failover mislukt voordat de meest recente wijzigingen naar de secundaire replica worden gerepliceerd. Wanneer een primaire functie met meerdere secundaire replica's een fout maakt, worden de replicatierelaties automatisch opnieuw geconfigureerd en worden de resterende secundaire bestanden aan de zojuist gepromoveerde primaire replica's koppelt zonder tussenkomst van de gebruiker. Nadat de storing die de failover heeft veroorzaakt, is beperkt, kan het wenselijk zijn om de toepassing terug te brengen naar de primaire regio. Om dit te doen, moet de failover-opdracht worden aangeroepen met de optie 'gepland'.

Secundaire database voorbereiden op failover

Zorg ervoor dat de verificatievereisten voor uw secundaire server en database correct zijn geconfigureerd om ervoor te zorgen dat uw toepassing onmiddellijk toegang heeft tot de nieuwe primaire server na een failover. Zie Beveiliging na SQL Database herstel na noodherstel voor meer informatie. Als u naleving na een failover wilt garanderen, moet u ervoor zorgen dat het bewaarbeleid voor back-ups voor de secundaire database overeenkomt met dat van de primaire database. Deze instellingen maken geen deel uit van de database en worden niet gerepliceerd. Standaard wordt de secundaire server geconfigureerd met een standaardretentieperiode van zeven dagen. Zie automatische back SQL Database back-ups voor meer informatie.

Belangrijk

Als uw database lid is van een failovergroep, kunt u de failover niet initiëren met behulp van de failoveropdracht voor geo-replicatie. Gebruik de failover-opdracht voor de groep. Als u een failover wilt maken voor een afzonderlijke database, moet u deze eerst uit de failovergroep verwijderen. Zie failovergroepen voor meer informatie.

Secundaire database configureren

Zowel primaire als secundaire databases moeten dezelfde servicelaag hebben. Het wordt ook sterk aanbevolen dat de secundaire database wordt gemaakt met dezelfde redundantie voor back-upopslag en rekenkracht (DTUs of vCores) als de primaire database. Als de primaire database een zware schrijfworkload ondervindt, kan een secundaire database met een lagere rekenkracht deze mogelijk niet bijbenen. Dit zorgt voor een vertraging bij opnieuw doen op de secundaire en mogelijk onbeschikbaarheid van de secundaire. Om deze risico's te beperken, beperkt actieve geo-replicatie zo nodig de snelheid van het transactielogboek van de primaire replica om de secundaire replica's in te halen.

Een ander gevolg van een onevenwichtige secundaire configuratie is dat de prestaties van de toepassing na een failover kunnen worden teruggezet als gevolg van onvoldoende rekencapaciteit van de nieuwe primaire server. In dat geval is het nodig om de databaseservicedoelstelling op te schalen naar het benodigde niveau, wat veel tijd en rekenbronnen kan kosten, en dat er een failover met hoge beschikbaarheid nodig is aan het einde van het omhoog schalen.

Als u besluit om de secundaire te maken met een lagere rekenkracht, biedt het logboek-IO-percentagediagram in Azure Portal een goede manier om de minimale rekenkracht van de secundaire te schatten die nodig is om de replicatiebelasting te ondersteunen. Als uw primaire database bijvoorbeeld P6 (1000 DTU) is en het schrijf percentage voor logboeken 50% is, moet de secundaire database ten minste P4 (500 DTU' zijn). Als u historische logboek-I/O-gegevens wilt ophalen, gebruikt u sys.resource_stats weergave. Als u recente schrijfgegevens voor logboeken wilt ophalen met een hogere granulariteit die beter de korte-termijnpieken in de logboeksnelheid weerspiegelt, gebruikt sys.dm_db_resource_stats weergave.

Beperking van transactielogboeksnelheid op de primaire database vanwege een lagere rekenkracht op een secundaire database wordt gerapporteerd met behulp van het HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO-wachttype, dat zichtbaar is in de databaseweergaven sys.dm_exec_requests en sys.dm_os_wait_stats.

Standaard is de redundantie van de back-upopslag van de secundaire database hetzelfde als die van de primaire database. U kunt ervoor kiezen om de secundaire te configureren met een andere redundantie voor back-upopslag. Back-ups worden altijd gemaakt op de primaire database. Als de secundaire server is geconfigureerd met een andere redundantie voor back-upopslag, worden back-ups na een failover naar de primaire gefactureerd op basis van de opslag redundantie die is geselecteerd op de nieuwe primaire (vorige secundaire).

Notitie

De snelheid van het transactielogboek op de primaire kan worden beperkt om redenen die geen verband houden met een lagere rekenkracht op een secundaire. Dit soort beperking kan zelfs optreden als de secundaire computer dezelfde of een hogere rekenkracht heeft dan de primaire. Zie Governance van transactielogboekfrequentie voor meer informatie, waaronder wachttypen voor verschillende soorten beperking van logboeksnelheid.

Notitie

Azure SQL Database configureerbare redundantie voor back-upopslag is momenteel beschikbaar als openbare preview-versie in Brazilië - zuid algemeen beschikbaar in de Azure-regio Azië - zuidoost. Wanneer de brondatabase wordt gemaakt met lokaal redundante of zone-redundante back-upopslag redundantie, wordt het maken van een secundaire database in een andere Azure-regio niet ondersteund.

Zie What are SQL Database Service Tiers (Wat SQL Database servicelagen) voor meer informatie over de SQL Database rekenkracht.

Geo-replicatie tussen abonnementen

Notitie

Het maken van een geo-replica op een logische server in een andere Azure-tenant wordt niet ondersteund wanneer Azure Active Directory-auth actief is (ingeschakeld) op een primaire of secundaire logische server.

Als u actieve geo-replicatie wilt instellen tussen twee databases die tot verschillende abonnementen behoren (al dan niet onder dezelfde tenant), moet u de speciale procedure volgen die in deze sectie wordt beschreven. De procedure is gebaseerd op SQL-opdrachten en vereist:

  • Een bevoegde aanmelding maken op beide servers
  • Het IP-adres toevoegen aan de lijst met toegestane servers van de client die de wijziging op beide servers (zoals het IP-adres van de host met SQL Server Management Studio).

De client die de wijzigingen moet uitvoeren, heeft netwerktoegang tot de primaire server nodig. Hoewel hetzelfde IP-adres van de client moet worden toegevoegd aan de lijst met toegestane adressen op de secundaire server, is netwerkverbinding met de secundaire server niet strikt vereist.

Op de hoofdserver van de primaire server

  1. Voeg het IP-adres toe aan de lijst met toegestane adressen van de client die de wijzigingen moet uitvoeren (zie Firewall configureren voor meer informatie).

  2. Maak een aanmelding die is toegewezen om actieve geo-replicatie in te stellen (en pas de referenties naar behoefte aan):

    create login geodrsetup with password = 'ComplexPassword01'
    
  3. Maak een bijbehorende gebruiker en wijs deze toe aan de rol dbmanager:

    create user geodrsetup for login geodrsetup
    alter role dbmanager add member geodrsetup
    
  4. Noteer de SID van de nieuwe aanmelding met behulp van deze query:

    select sid from sys.sql_logins where name = 'geodrsetup'
    

Op de brondatabase op de primaire server

  1. Maak een gebruiker voor dezelfde aanmelding:

    create user geodrsetup for login geodrsetup
    
  2. Voeg de gebruiker toe aan de db_owner rol:

    alter role db_owner add member geodrsetup
    

Op de hoofdserver van de secundaire server

  1. Voeg het IP-adres van de client toe aan de lijst met toegestane adressen onder firewallregels voor de secundaire server. Controleer of exact hetzelfde IP-adres van de client dat is toegevoegd op de primaire server ook is toegevoegd aan de secundaire server. Dit is een vereiste stap die moet worden uitgevoerd voordat u de opdracht ALTER DATABASE ADD SECONDARY gebruikt om geo-replicatie te initiëren.

  2. Maak dezelfde aanmelding als op de primaire server met hetzelfde gebruikersnaamwachtwoord en dezelfde SID:

    create login geodrsetup with password = 'ComplexPassword01', sid=0x010600000000006400000000000000001C98F52B95D9C84BBBA8578FACE37C3E
    
  3. Maak een bijbehorende gebruiker en wijs deze toe aan de rol dbmanager:

    create user geodrsetup for login geodrsetup;
    alter role dbmanager add member geodrsetup
    

Op de hoofdserver van de primaire server

  1. Meld u aan bij de hoofdserver van de primaire server met behulp van de nieuwe aanmelding.

  2. Maak een secundaire replica van de brondatabase op de secundaire server (pas de databasenaam en servernaam naar behoefte aan):

    alter database dbrep add secondary on server <servername>
    

Na de eerste installatie kunnen de gebruikers, aanmeldingen en firewallregels die zijn gemaakt, worden verwijderd.

Referenties en firewallregels gesynchroniseerd houden

We raden u aan OM IP-firewallregels op databaseniveau te gebruiken voor databases met geo-replicatie, zodat deze regels kunnen worden gerepliceerd met de database om ervoor te zorgen dat alle secundaire databases dezelfde IP-firewallregels hebben als de primaire database. Met deze aanpak hoeven klanten geen firewallregels handmatig te configureren en te onderhouden op servers die als host voor zowel de primaire als secundaire databases worden gebruikt. Op dezelfde manier zorgt het gebruik van ingesloten databasegebruikers voor gegevenstoegang ervoor dat zowel primaire als secundaire databases altijd dezelfde gebruikersreferenties hebben, zodat er tijdens een failover geen onderbrekingen zijn vanwege niet-overeenkomende aanmeldingen en wachtwoorden. Met de toevoeging van Azure Active Directorykunnen klanten gebruikerstoegang tot zowel primaire als secundaire databases beheren en hoeven ze de referenties in databases helemaal niet meer te beheren.

Primaire database upgraden of downgraden

U kunt een primaire database upgraden of downgraden naar een andere rekenkracht (binnen dezelfde servicelaag, niet tussen Algemeen en Bedrijfskritiek) zonder dat de verbinding met secundaire databases wordt verbroken. Bij het upgraden raden we u aan eerst de secundaire database bij te upgraden en vervolgens de primaire database bij te upgraden. Als u een downgrade wilt uitvoeren, doet u dat in omgekeerde volgorde: downgrade eerst de primaire en vervolgens de secundaire. Bij het upgraden of downgraden van de database naar een andere servicelaag wordt deze aanbeveling afgedwongen.

Notitie

Als u een secundaire database hebt gemaakt als onderdeel van de configuratie van de failovergroep, wordt het niet aanbevolen de secundaire database te downgraden. Dit is om ervoor te zorgen dat uw gegevenslaag voldoende capaciteit heeft om uw normale workload te verwerken nadat de failover is geactiveerd.

Belangrijk

De primaire database in een failovergroep kan niet naar een hogere laag worden geschaald, tenzij eerst de secundaire database naar de hogere laag wordt geschaald. Als u probeert de primaire database te schalen voordat de secundaire database wordt geschaald, wordt mogelijk de volgende fout weergegeven:

Error message: The source database 'Primaryserver.DBName' cannot have higher edition than the target database 'Secondaryserver.DBName'. Upgrade the edition on the target before upgrading the source.

Voorkomen dat kritieke gegevens verloren gaan

Vanwege de hoge latentie van Wide Area Networks maakt continue kopie gebruik van een asynchrone replicatiemechanisme. Asynchrone replicatie maakt gegevensverlies onvermijdelijk als er een fout optreedt. Voor sommige toepassingen is echter mogelijk geen gegevensverlies vereist. Om deze essentiële updates te beveiligen, kan een toepassingsontwikkelaar de sp_wait_for_database_copy_sync onmiddellijk na het uitvoeren van de transactie aanroepen. Het sp_wait_for_database_copy_sync blokkeert de aanroepingsthread totdat de laatste vastgelegde transactie is verzonden naar de secundaire database. Er wordt echter niet gewacht tot de verzonden transacties opnieuw worden afgespeeld en op de secundaire worden vastgelegd. sp_wait_for_database_copy_sync is gericht op een specifieke koppeling voor continue kopie. Elke gebruiker met de verbindingsrechten voor de primaire database kan deze procedure aanroepen.

Notitie

sp_wait_for_database_copy_sync voorkomt gegevensverlies na een failover, maar garandeert geen volledige synchronisatie voor leestoegang. De vertraging die wordt veroorzaakt door sp_wait_for_database_copy_sync procedureoproep kan aanzienlijk zijn en is afhankelijk van de grootte van het transactielogboek op het moment van de aanroep.

Geo-replicatievertraging bewaken

Als u vertraging met betrekking tot RPO wilt bewaken, gebruikt replication_lag_sec kolom met sys.dm_geo_replication_link_status in de primaire database. Het toont vertraging in seconden tussen de transacties die zijn vastgelegd op de primaire en persistent op de secundaire. Bijvoorbeeld Als de waarde van de vertraging 1 seconde is, betekent dit dat als de primaire op dit moment wordt beïnvloed door een storing en failover wordt gestart, 1 seconde van de meest recente overgangen niet wordt opgeslagen.

Als u vertraging wilt meten met betrekking tot wijzigingen in de primaire database die zijn toegepast op de secundaire database, dat wil zeggen beschikbaar om te lezen vanaf de secundaire database, vergelijkt u last_commit tijd op de secundaire database met dezelfde waarde voor de primaire database.

Notitie

Soms replication_lag_sec op de primaire database een NULL-waarde heeft, wat betekent dat de primaire database momenteel niet weet hoe ver de secundaire database is. Dit gebeurt meestal nadat het proces opnieuw is opgestart en moet een tijdelijke voorwaarde zijn. Overweeg de toepassing te waarschuwen als de replication_lag_sec null voor een langere periode retourneert. Dit geeft aan dat de secundaire database niet kan communiceren met de primaire database vanwege een permanente verbindingsfout. Er zijn ook voorwaarden die ertoe kunnen leiden dat het verschil last_commit op de secundaire database en op de primaire database te groot wordt. Bijvoorbeeld Als er na een lange periode zonder wijzigingen een door commit op de primaire wordt gemaakt, zal het verschil omhoog gaan naar een grote waarde voordat deze snel terugkeert naar 0. Houd er rekening mee dat het een foutvoorwaarde is wanneer het verschil tussen deze twee waarden lange tijd groot blijft.

Actieve geo-replicatie programmatisch beheren

Zoals eerder besproken, kan actieve geo-replicatie ook programmatisch worden beheerd met behulp Azure PowerShell en de 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 cmdlets Azure SQL Database REST API en Azure PowerShell. 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.

T-SQL: failover van individuele en pooldatabases beheren

Belangrijk

Deze Transact-SQL-opdrachten zijn alleen van toepassing op actieve geo-replicatie en zijn niet van toepassing op failovergroepen. Als zodanig zijn ze ook niet van toepassing op exemplaren van SQL Managed Instance, omdat ze alleen failovergroepen ondersteunen.

Opdracht Beschrijving
ALTER DATABASE Gebruik het argument ADD SECONDARY ON SERVER om een secundaire database voor een bestaande database te maken en gegevensreplicatie te starten
ALTER DATABASE Gebruik FAILOVER of FORCE_FAILOVER_ALLOW_DATA_LOSS om een secundaire database om te zetten in primaire database om failover te initiëren
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 Haalt de laatste replicatietijd, laatste replicatievertraging en andere informatie op over de replicatiekoppeling voor een bepaalde database.
sys.dm_operation_status Toont de status voor alle databasebewerkingen, inclusief de status van de replicatiekoppelingen.
sp_wait_for_database_copy_sync zorgt ervoor dat de toepassing wacht totdat alle vastgelegde transacties zijn gerepliceerd en bevestigd door de actieve secundaire database.

PowerShell: failover van individuele en pooldatabases beheren

Notitie

Dit artikel is bijgewerkt om gebruik te maken van de Azure Az PowerShell-module. De Az PowerShell-module is de aanbevolen PowerShell-module voor interactie met Azure. Raadpleeg Azure PowerShell installeren om aan de slag te gaan met de Az PowerShell-module. Raadpleeg Azure PowerShell migreren van AzureRM naar Az om te leren hoe u naar de Azure PowerShell-module migreert.

Belangrijk

De module PowerShell Azure Resource Manager wordt nog steeds ondersteund in Azure SQL Database, maar alle toekomstige ontwikkeling is voor de Az.Sql-module. Zie AzureRM.Sql voor deze cmdlets. De argumenten voor de opdrachten in de Az-module en in de AzureRm-modules zijn vrijwel identiek.

Cmdlet Beschrijving
Get-AzSqlDatabase Hiermee haalt u een of meer databases op.
New-AzSqlDatabaseSecondary Hiermee maakt u een secundaire database voor een bestaande database en wordt gegevensreplicatie gestart.
Set-AzSqlDatabaseSecondary Hiermee wordt overgeschakeld op een secundaire database als primaire om de failover te initiëren.
Remove-AzSqlDatabaseSecondary Hiermee wordt gegevensreplicatie tussen een SQL Database en de opgegeven secundaire database beëindigd.
Get-AzSqlDatabaseReplicationLink Hiermee haalt u de geo-replicatiekoppelingen tussen een Azure SQL Database en een resourcegroep of logische SQL Server op.

Belangrijk

Zie Configure and failover a single database using active geo-replication (Een individuele database configureren en failover uitvoeren met actieve geo-replicatie) en Configure and failover a pooled database using active geo-replication(Een pooldatabase configureren en failover uitvoeren met actieve geo-replicatie) voor voorbeeldscripts.

REST API: Failover van individuele en pooldatabases beheren

API Beschrijving
Database maken of bijwerken (createMode=Restore) Hiermee wordt een primaire of secundaire database gemaakt, bijgewerkt of hersteld.
Databasestatus maken of bijwerken Retourneert de status tijdens een maakbewerking.
Secundaire database instellen op Primair (geplande failover) Hiermee stelt u in welke secundaire database primair is door een failing over te slaan van de huidige primaire database. Deze optie wordt niet ondersteund voor SQL Managed Instance.
Secundaire database instellen op primair (niet-geplande failover) Hiermee stelt u in welke secundaire database primair is door een failing over te slaan van de huidige primaire database. Deze bewerking kan leiden tot gegevensverlies. Deze optie wordt niet ondersteund voor SQL Managed Instance.
Replicatiekoppeling op halen Haalt een specifieke replicatiekoppeling op voor een bepaalde database in een geo-replicatiepartnerschap. Hiermee haalt u de informatie op die zichtbaar is in sys.geo_replication_links catalogusweergave. Deze optie wordt niet ondersteund voor SQL Managed Instance.
Replicatiekoppelingen - Lijst per database Haalt alle replicatiekoppelingen op voor een bepaalde database in een geo-replicatiepartnerschap. Hiermee haalt u de informatie op die zichtbaar is in sys.geo_replication_links catalogusweergave.
Replicatiekoppeling verwijderen Hiermee verwijdert u een databasereplicatiekoppeling. Kan niet worden uitgevoerd tijdens de failover.

Volgende stappen