Actieve geo-replicatie

Van toepassing op: Azure SQL-database

Actieve geo-replicatie is een functie waarmee u een continu gesynchroniseerde secundaire database voor een primaire database kunt maken. De leesbare secundaire database bevindt zich mogelijk in dezelfde Azure-regio als de primaire of, vaker, in een andere regio. Dit type leesbare secundaire database wordt ook wel geo-secundaire of geo-replica genoemd.

Actieve geo-replicatie is ontworpen als een bedrijfscontinuïteitsoplossing waarmee u snel herstel na noodgevallen van afzonderlijke databases kunt uitvoeren in geval van een regionale noodgeval of een grootschalige storing. Zodra geo-replicatie is ingesteld, kunt u een geo-failover initiëren naar een geo-secundaire regio in een andere Azure-regio. De geo-failover wordt programmatisch gestart door de toepassing of handmatig door de gebruiker.

Notitie

Voor geografische failover van exemplaren van SQL Managed Instance gebruikt u groepen voor automatische failover. Voor meer informatie vergelijkt u geo-replicatie met failovergroepen. Actieve geo-replicatie wordt niet ondersteund door Azure SQL Managed Instance.

Als uw toepassing een stabiel verbindingseindpunt en automatische ondersteuning voor geo-failover vereist naast geo-replicatie, gebruikt u groepen voor automatische failover.

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

actieve geo-replicatie

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

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

Actieve geo-replicatie maakt gebruik van de AlwaysOn-beschikbaarheidsgroepstechnologie om transactielogboeken die zijn gegenereerd op de primaire replica asynchroon te repliceren naar alle geo-replica's. Op een bepaald moment kan een secundaire database iets achter de primaire database staan, maar de gegevens op een secundaire database zijn gegarandeerd transactieconsistent. Met andere woorden, wijzigingen die zijn aangebracht door niet-doorgevoerde transacties zijn niet zichtbaar.

Notitie

Actieve geo-replicatie repliceert wijzigingen door het transactielogboek van de primaire replica van de primaire replica naar secundaire replica's te streamen. Het is niet gerelateerd aan transactionele replicatie, waarmee wijzigingen worden gerepliceerd door DML-opdrachten (INSERT, UPDATE, DELETE) uit te voeren op abonnees.

Dankzij regionale redundantie die wordt geboden door geo-replicatie, kunnen toepassingen snel herstellen van een permanent verlies van een hele Azure-regio, of delen van een regio, veroorzaakt door natuurrampen, catastrofale menselijke fouten of schadelijke handelingen. RPO voor geo-replicatie vindt u in Overzicht van bedrijfscontinuïteit.

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

geo-replicatierelatie

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

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

Als u volledige bedrijfscontinuïteit wilt bereiken, maakt het toevoegen van regionale redundantie van de database 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. Zie Cloud Solutions for Disaster Recovery ontwerpen met actieve geo-replicatie voor meer informatie over het ontwerpen van oplossingen voor herstel na noodgevallen.

Terminologie en mogelijkheden voor actieve geo-replicatie

  • Automatische asynchrone replicatie

    U kunt alleen een geo-secundaire database maken voor een bestaande database. De geo-secundaire server kan worden gemaakt op elke logische server, behalve de server met de primaire database. Zodra de geo-secundaire replica is gemaakt, wordt deze gevuld met de gegevens van de primaire database. Dit proces wordt seeding genoemd. Nadat een geo-secundaire database is gemaakt en gezaaid, worden updates voor de primaire database automatisch en asynchroon gerepliceerd naar de geo-secundaire replica. Asynchrone replicatie betekent dat transacties worden doorgevoerd in de primaire database voordat ze worden gerepliceerd.

  • Leesbare geo-secundaire replica's

    Een toepassing heeft toegang tot een geo-secundaire replica om alleen-lezenquery's uit te voeren met behulp van dezelfde of verschillende beveiligingsprinciplen 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 geo-replicatie gebruiken om secundaire replica's te maken in dezelfde regio als de primaire. U kunt deze secundaire bestanden gebruiken om te voldoen aan uitschaalscenario's voor leesbewerkingen in dezelfde regio. Een secundaire replica in dezelfde regio biedt echter geen extra tolerantie voor catastrofale storingen of grootschalige storingen, en is daarom geen geschikt failoverdoel voor herstel na noodgevallen. Het garandeert ook geen isolatie van beschikbaarheidszones. Gebruik Bedrijfskritiek of Premium-servicelagen zone-redundante configuratie of Algemeen zone-redundante configuratie van de servicelaag om isolatie van beschikbaarheidszones te bereiken.

  • Geplande geo-failover

    Geplande geo-failover schakelt de rollen van primaire en geo-secundaire databases over nadat volledige gegevenssynchronisatie is voltooid. Een geplande failover leidt niet tot gegevensverlies. De duur van geplande geo-failover is afhankelijk van de grootte van het transactielogboek op de primaire die moet worden gesynchroniseerd met de geo-secundaire. Geplande geo-failover is ontworpen voor de volgende scenario's:

    • Dr-drills uitvoeren in productie wanneer het gegevensverlies niet acceptabel is;
    • Verplaats de database naar een andere regio;
    • Retourneer de database naar de primaire regio nadat de storing is verzacht (ook wel failback genoemd).
  • Niet-geplande geo-failover

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

    Belangrijk

    Na geplande of niet-geplande geo-failover, verandert het verbindingseindpunt voor de nieuwe primaire wijzigingen omdat de nieuwe primaire zich nu op een andere logische server bevindt.

  • Meerdere leesbare geo-secondaries

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

    Tip

    Als u actieve geo-replicatie gebruikt om een wereldwijd gedistribueerde toepassing te bouwen en alleen-lezentoegang tot gegevens in meer dan vier regio's moet bieden, kunt u een secundaire van een secundaire (een proces dat bekend staat als keten) maken om extra geo-replica's te maken. Replicatievertraging op gekoppelde geo-replica's kan hoger zijn dan op geo-replica's die rechtstreeks zijn verbonden met de primaire replica. Het instellen van gekoppelde geo-replicatietopologieën wordt alleen programmatisch ondersteund en niet vanuit Azure Portal.

  • Geo-replicatie van databases in een elastische pool

    Elke geo-secundaire database kan één database of een database in een elastische pool zijn. De keuze voor elastische pools voor elke geo-secundaire database is gescheiden 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-secundaire databases van dezelfde primaire server nooit een elastische pool delen.

  • Door de gebruiker beheerde geo-failover en failback

    Een geo-secundaire die de eerste seeding heeft voltooid, kan op elk gewenst moment worden overgeschakeld naar de primaire rol (failover) door de toepassing of de gebruiker. Tijdens een storing waarbij de primaire niet toegankelijk is, kan alleen een ongeplande geo-failover worden gebruikt. Dat bevordert onmiddellijk een geo-secundaire om de nieuwe primaire te zijn. Wanneer de storing wordt verzacht, maakt het systeem automatisch de herstelde primaire geo-secundaire en wordt deze up-to-date gebracht met de nieuwe primaire. Vanwege de asynchrone aard van geo-replicatie kunnen recente transacties verloren gaan tijdens ongeplande geo-failovers als de primaire mislukt voordat deze transacties worden gerepliceerd naar een geo-secundaire. Wanneer een primaire met meerdere geo-secundaire bestanden een failover uitvoert, worden replicatierelaties automatisch opnieuw geconfigureerd en worden de resterende geo-secundaire bestanden gekoppeld aan de zojuist gepromoveerde primaire, zonder tussenkomst van de gebruiker. Na de storing waardoor de geo-failover is verzacht, kan het wenselijk zijn om de primaire naar de oorspronkelijke regio te retourneren. Hiervoor roept u een geplande geo-failover aan.

Voorbereiden op geo-failover

Controleer of de verificatie en netwerktoegang voor uw secundaire server correct zijn geconfigureerd om ervoor te zorgen dat uw toepassing direct toegang heeft tot de nieuwe primaire na geo-failover. Zie SQL Database beveiliging na herstel na noodgeval voor meer informatie. Controleer ook of het bewaarbeleid voor back-ups op 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 database. De geo-secundaire is standaard geconfigureerd met een standaardretentieperiode van zeven dagen. Zie SQL Database automatische 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 opdracht failover voor geo-replicatie. Gebruik de failoveropdracht voor de groep. Als u een failover van een afzonderlijke database wilt uitvoeren, moet u deze eerst verwijderen uit de failovergroep. Zie groepen voor automatische failover voor meer informatie.

Geo-secundair configureren

Zowel primaire als geo-secundaire moeten dezelfde servicelaag hebben. Het wordt ook sterk aanbevolen dat de geo-secundaire is geconfigureerd met dezelfde back-upopslagredundantie en rekengrootte (DTU's of vCores) als de primaire. Als de primaire werkbelasting een zware schrijfworkload ondervindt, kan een geo-secundaire met een lagere rekenkracht mogelijk niet bijhouden. Dit veroorzaakt replicatievertraging op de geo-secundaire locatie en kan uiteindelijk leiden tot niet-beschikbaarheid van de geo-secundaire locatie. Om deze risico's te beperken, vermindert actieve geo-replicatie zo nodig de snelheid van het transactielogboek van de primaire instantie om de secondaries in te halen.

Een ander gevolg van een onevenwichtige geo-secundaire configuratie is dat na een failover de prestaties van toepassingen kunnen lijden als gevolg van onvoldoende rekencapaciteit van de nieuwe primaire. In dat geval is het nodig om de database omhoog te schalen om voldoende resources te hebben, wat veel tijd kan duren en een failover met hoge beschikbaarheid aan het einde van het proces voor omhoog schalen vereist, waardoor toepassingsworkloads mogelijk worden onderbroken.

Als u besluit om de geo-secundaire met een lagere rekenkracht te maken, moet u de io-snelheid van het logboek in de loop van de tijd bewaken. Hiermee kunt u een schatting maken van de minimale rekenkracht van de geo-secundaire die vereist is om de replicatiebelasting te ondersteunen. Als uw primaire database bijvoorbeeld P6 (1000 DTU) is en de bijbehorende logboek-IO 50% heeft, moet de geo-secundaire database ten minste P4 (500 DTU) zijn. Gebruik de sys.resource_stats weergave om historische IO-gegevens in logboeken op te halen. Gebruik de sys.dm_db_resource_stats weergave om recente IO-gegevens in logboeken op te halen met een hogere granulariteit die beter overeenkomt met pieken op korte termijn.

Tip

Io-beperking in transactielogboek op de primaire server vanwege lagere rekenkracht op een geo-secundaire locatie wordt gerapporteerd met behulp van het HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO wachttype, zichtbaar in de sys.dm_exec_requests - en sys.dm_os_wait_stats databaseweergaven.

Io voor transactielogboek op de primaire server kan worden beperkt om redenen die niet zijn gerelateerd aan lagere rekenkracht op een geo-secundaire locatie. Dit soort beperking kan zich voordoen, zelfs als de geo-secundaire waarde dezelfde of hogere rekenkracht heeft dan de primaire. Zie Voor meer informatie, inclusief wachttypen voor verschillende soorten io-beperking voor logboeken, governance van transactielogboekfrequentie.

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

Geo-replicatie binnen meerdere abonnementen

Voer de stappen in deze sectie uit om een geografisch secundair abonnement te maken in een ander abonnement dan het abonnement van de primaire (of niet onder dezelfde Azure Active Directory-tenant).

  1. Voeg het IP-adres van de clientcomputer toe die de onderstaande T-SQL-opdrachten uitvoert aan de serverfirewalls van zowel de primaire als de secundaire servers. U kunt dit IP-adres bevestigen door de volgende query uit te voeren terwijl u verbinding hebt met de primaire server vanaf dezelfde clientcomputer.

    select client_net_address from sys.dm_exec_connections where session_id = @@SPID;
    

    Zie Firewall configureren voor meer informatie.

  2. Maak in de master database op de primaire server een SQL-verificatieaanmelding die is toegewezen aan de actieve installatie van geo-replicatie. Pas indien nodig de aanmeldingsnaam en het wachtwoord aan.

    create login geodrsetup with password = 'ComplexPassword01';
    
  3. Maak in dezelfde database een gebruiker voor de aanmelding en voeg deze toe aan de dbmanager rol:

    create user geodrsetup for login geodrsetup;
    alter role dbmanager add member geodrsetup;
    
  4. Noteer de SID-waarde van de nieuwe aanmelding. Haal de SID-waarde op met behulp van de volgende query.

    select sid from sys.sql_logins where name = 'geodrsetup';
    
  5. Maak verbinding met de primaire database (niet de master database) en maak een gebruiker voor dezelfde aanmelding.

    create user geodrsetup for login geodrsetup;
    
  6. Voeg in dezelfde database de gebruiker toe aan de db_owner rol.

    alter role db_owner add member geodrsetup;
    
  7. Maak in de hoofddatabase op de secundaire server dezelfde aanmelding als op de primaire server met dezelfde naam, wachtwoord en SID. Vervang de hexadecimale SID-waarde in de onderstaande voorbeeldopdracht door de waarde die u in stap 4 hebt verkregen.

    create login geodrsetup with password = 'ComplexPassword01', sid=0x010600000000006400000000000000001C98F52B95D9C84BBBA8578FACE37C3E;
    
  8. Maak in dezelfde database een gebruiker voor de aanmelding en voeg deze toe aan de dbmanager rol.

    create user geodrsetup for login geodrsetup;
    alter role dbmanager add member geodrsetup;
    
  9. Maak verbinding met de hoofddatabase op de primaire server met behulp van de nieuwe geodrsetup aanmelding en initieer geo-secundaire creatie op de secundaire server. Pas de databasenaam en de secundaire servernaam zo nodig aan. Zodra de opdracht is uitgevoerd, kunt u geo-secundaire creatie bewaken door een query uit te voeren op de sys.dm_geo_replication_link_status weergave in de primaire database en de sys.dm_operation_status weergave in de hoofddatabase op de primaire server. De tijd die nodig is om een geo-secundaire database te maken, is afhankelijk van de primaire databasegrootte.

    alter database [dbrep] add secondary on server [servername];
    
  10. Nadat de geo-secundaire locatie is gemaakt, kunnen de gebruikers, aanmeldingen en firewallregels die door deze procedure zijn gemaakt, worden verwijderd.

Notitie

Geo-replicatiebewerkingen tussen abonnementen, waaronder installatie en geo-failover, worden alleen ondersteund met REST API & T-SQL-opdrachten.

Het toevoegen van een geo-secundaire toepassing met T-SQL wordt niet ondersteund bij het maken van verbinding 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-secundaire locatie ondersteund wanneer deze is verbonden met de primaire server vanaf een openbaar IP-adres. Zodra een geo-secundaire locatie is toegevoegd, kan de toegang tot het openbare netwerk worden geweigerd.

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

Referenties 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, waardoor alle geo-secundaire bestanden dezelfde IP-firewallregels hebben als de primaire. Deze aanpak elimineert de noodzaak voor klanten om handmatig firewallregels te configureren en te onderhouden op servers die als host fungeren voor de primaire en secundaire databases. 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 vanwege niet-overeenkomende verificatiereferenties. Als u aanmeldingen en gebruikers gebruikt (in plaats van ingesloten gebruikers), moet u extra stappen uitvoeren om ervoor te zorgen dat dezelfde aanmeldingen bestaan voor uw secundaire database. Zie Aanmeldingen en gebruikers configureren voor configuratiedetails.

Primaire database schalen

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

Notitie

Als u een geo-secundaire database hebt gemaakt als onderdeel van een failovergroepsconfiguratie, wordt het afgeraden deze 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.

Belangrijk

De primaire database in een failovergroep kan niet worden geschaald naar een hogere servicelaag (editie), tenzij de secundaire database eerst wordt geschaald naar de hogere laag. Als u bijvoorbeeld de primaire schaal van Algemeen naar Bedrijfskritiek wilt schalen, moet u eerst de geo-secundaire schaal naar Bedrijfskritiek schalen. Als u probeert de primaire of geo-secundaire schaal op een manier te schalen die deze regel schendt, krijgt u de volgende fout:

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.

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. 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 is beperkt in het transactielogboek van de secundaire database. Het wacht echter niet totdat 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 procedureoproep kan aanzienlijk zijn en is afhankelijk van de grootte van het nog niet verzonden transactielogboek op het primaire moment van de oproep.

Vertraging van geo-replicatie bewaken

Gebruik replication_lag_sec kolom van sys.dm_geo_replication_link_status op de primaire database om vertraging met betrekking tot RPO te controleren. Het toont vertraging in seconden tussen de transacties die zijn vastgelegd op de primaire, en wordt beperkt tot het transactielogboek op de secundaire. Als de vertraging bijvoorbeeld één seconde is, betekent dit dat als de primaire wordt beïnvloed door een storing op dit moment 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 beperkt op de geo-secundaire database, vergelijkt u last_commit tijd op de geo-secundaire database met dezelfde waarde op de primaire database.

Tip

Als replication_lag_sec op de primaire waarde NULL is, betekent dit dat de primaire niet weet hoe ver achter een geo-secundaire locatie zich bevindt. Dit gebeurt meestal nadat het proces opnieuw is opgestart en een tijdelijke voorwaarde moet zijn. Overweeg een waarschuwing te verzenden als replication_lag_sec NULL gedurende een langere periode retourneert. Het kan erop wijzen dat de geo-secundaire niet kan communiceren met de primaire vanwege een verbindingsfout.

Er zijn ook voorwaarden die het verschil kunnen veroorzaken tussen last_commit tijd op de geo-secundaire locatie en de primaire om groot te worden. Als er bijvoorbeeld een doorvoering wordt aangebracht op de primaire server na een lange periode zonder wijzigingen, gaat het verschil omhoog naar een grote waarde voordat u snel terugkeert naar nul. Overweeg een waarschuwing te verzenden als het verschil tussen deze twee waarden lang groot blijft.

Programmatisch actieve geo-replicatie beheren

Zoals eerder is besproken, kan actieve geo-replicatie 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 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 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: geo-failover van individuele en pooldatabases beheren

Belangrijk

Deze T-SQL-opdrachten zijn alleen van toepassing op actieve geo-replicatie en zijn niet van toepassing op failovergroepen. Daarom zijn ze ook niet van toepassing op SQL Managed Instance, die alleen failovergroepen ondersteunt.

Opdracht Beschrijving
ALTER DATABASE GEBRUIK HET argument ADD SECONDARY ON SERVER om een secundaire database te maken voor een bestaande database en gegevensreplicatie te starten
ALTER DATABASE Failover ofFORCE_FAILOVER_ALLOW_DATA_LOSS gebruiken om een secundaire database om te zetten in een 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 Hiermee haalt u de laatste replicatietijd, 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 doorgevoerde transacties zijn beperkt tot het transactielogboek van een geo-secundaire locatie.

PowerShell: Geo-failover van individuele en pooldatabases beheren

Notitie

In dit artikel wordt gebruikgemaakt van de Azure Az PowerShell-module. Dit 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 voor een database op.

REST API: Geo-failover van individuele en pooldatabases beheren

API Beschrijving
Database maken of bijwerken (createMode=Restore) Hiermee maakt u een primaire of secundaire database, werkt u deze bij of herstelt u deze.
Databasestatus maken of bijwerken Retourneert de status tijdens een bewerking maken.
Secundaire database instellen als primair (geplande failover) Hiermee stelt u in welke secundaire database primair is door een failover uit te voeren van de huidige primaire database. Deze optie wordt niet ondersteund voor SQL Managed Instance.
Secundaire database instellen als primair (niet-geplande failover) Hiermee stelt u in welke secundaire database primair is door een failover uit te voeren van de huidige primaire database. Deze bewerking kan leiden tot gegevensverlies. Deze optie wordt niet ondersteund voor SQL Managed Instance.
Replicatiekoppeling ophalen Hiermee haalt u een specifieke replicatiekoppeling op voor een bepaalde database in een geo-replicatierelatie. Hiermee wordt de informatie opgehaald die zichtbaar is in de sys.geo_replication_links catalogusweergave. Deze optie wordt niet ondersteund voor SQL Managed Instance.
Replicatiekoppelingen - Lijst per database Hiermee haalt u alle replicatiekoppelingen voor een bepaalde database op in een geo-replicatiepartnerschap. Hiermee wordt de informatie opgehaald die zichtbaar is in de sys.geo_replication_links catalogusweergave.
Replicatiekoppeling verwijderen Hiermee verwijdert u een databasereplicatiekoppeling. Kan niet worden uitgevoerd tijdens een failover.

Volgende stappen