Actieve geo-replicatie

Van toepassing op: Azure SQL database

Actieve geo-replicatie is een functie waarmee u een continu gesynchroniseerde leesbare secundaire database voor een primaire database kunt maken. 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 database of geo-replica genoemd.

Actieve geo-replicatie is ontworpen als een oplossing voor bedrijfscontinuïteit waarmee u snel herstel na noodgevallen van afzonderlijke databases kunt uitvoeren in geval van een regionaal noodgeval of een grootschalige storing. Zodra geo-replicatie is ingesteld, kunt u een geo-failover naar een geo-secundaire locatie in een andere Azure-regio initiëren. 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. Zie Geo-replicatie vergelijken met failovergroepen voor meer informatie. Actieve geo-replicatie wordt niet ondersteund door Azure SQL Managed Instance.

Notitie

Zie Migreren SQL Database met actieve geo-replicatie als u SQL-databases wilt migreren vanuit Azure Duitsland met behulp van actieve geo-replicatie.

Als uw toepassing naast geo-replicatie een stabiel verbindingseindpunt en automatische ondersteuning voor geo-failover vereist, 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 uitvalt, kunt u een geo-failover naar een van uw secundaire databases initiëren. Wanneer een secundaire wordt gepromoveerd naar de primaire rol, worden alle andere secundaire databases 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-technologie voor beschikbaarheidsgroepen om het transactielogboek dat is gegenereerd op de primaire replica asynchroon te repliceren naar alle geo-replica's. Hoewel een secundaire database zich op een bepaald moment mogelijk iets achter de primaire database bevindt, zijn de gegevens op een secundaire database 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 database te streamen van de primaire replica naar secundaire replica's. Het is niet gerelateerd aan transactionele replicatie, die wijzigingen repliceert door DML-opdrachten (INSERT, UPDATE, DELETE) uit te voeren op abonnees.

Met regionale redundantie die door geo-replicatie wordt geboden, 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. Geo-replicatie-RPO 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 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 met minimale downtime van de ene server naar de andere te migreren.
  • Toepassingsupgrades: u kunt een extra secundaire kopie maken als een failback-kopie tijdens toepassingsupgrades.

Als u volledige bedrijfscontinuïteit wilt bereiken, is het toevoegen van regionale databaseredundantie slechts een deel 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 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 passende stappen ondernemen om ervoor te zorgen dat uw service werkt tijdens de failover van de services waarvan deze afhankelijk is. Zie Ontwerpen van cloudoplossingen voor herstel na noodgevallen 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, met uitzondering van 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 geseed, worden updates van 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 andere beveiligingsprincipals die worden gebruikt voor toegang tot de primaire database. Zie Alleen-lezenreplica'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 databases gebruiken om te voldoen aan uitschaalscenario's voor lezen in dezelfde regio. Een secundaire replica in dezelfde regio biedt echter geen extra tolerantie tegen catastrofale fouten of grootschalige uitval en is daarom geen geschikt failoverdoel voor herstel na noodgevallen. Het biedt ook geen garantie voor isolatie van beschikbaarheidszones. Gebruik zoneredundante configuratie van Bedrijfskritiek- of Premium-servicelagen of Algemeen servicelaag zone-redundante configuratie om isolatie van beschikbaarheidszones te bereiken.

  • Geplande geo-failover

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

    • Dr-oefeningen 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

    Niet-geplande of geforceerde geo-failover schakelt de geo-secundaire functie onmiddellijk over naar de primaire rol zonder enige synchronisatie met de primaire rol. Alle transacties die zijn vastgelegd op de primaire, maar nog niet zijn 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 de database moet snel worden hersteld. Wanneer de oorspronkelijke primaire verbinding weer online is, wordt deze automatisch opnieuw verbonden, opnieuw geeed met behulp van de huidige primaire gegevens en wordt deze een nieuwe geo-secundaire.

    Belangrijk

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

  • Meerdere leesbare geo-secundaire databases

    Er kunnen maximaal vier geo-secundaire databases 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 wordt gemaakt. Als er meerdere secundaire databases bestaan, blijft de toepassing beveiligd, zelfs als een van de secundaire databases mislukt. Aanvullende secundaire databases kunnen ook worden gebruikt om alleen-lezenwerkbelastingen 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 wilt bieden, kunt u een secundaire van een secundaire (een proces dat ketenkoppeling wordt genoemd) maken om extra geo-replica's te maken. Replicatievertraging op geketende 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 een 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-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 door de toepassing of de gebruiker expliciet worden overgeschakeld naar de primaire rol (failover). Tijdens een storing waarbij de primaire instantie niet toegankelijk is, kan alleen een niet-geplande geo-failover worden gebruikt. Dat bevordert onmiddellijk een geo-secundaire om de nieuwe primaire te worden. Wanneer de storing is verzacht, maakt het systeem automatisch van de herstelde primaire een geo-secundaire locatie en wordt deze bijgewerkt met de nieuwe primaire. Vanwege de asynchrone aard van geo-replicatie kunnen recente transacties verloren gaan tijdens niet-geplande geo-failovers als de primaire failover mislukt voordat deze transacties worden gerepliceerd naar een geo-secundaire locatie. Wanneer een failover van een primaire met meerdere geo-secundaire databases wordt uitgevoerd, worden replicatierelaties automatisch opnieuw geconfigureerd en worden de resterende geo-secundaire databases gekoppeld aan de zojuist gepromoveerde primaire, zonder tussenkomst van de gebruiker. Nadat de storing die de geo-failover heeft veroorzaakt, is opgelost, kan het wenselijk zijn om de primaire regio terug te keren naar de oorspronkelijke regio. Hiervoor roept u een geplande geo-failover aan.

Voorbereiden op geo-failover

Controleer of de verificatie en netwerktoegang voor de secundaire server correct zijn geconfigureerd om ervoor te zorgen dat uw toepassing na geo-failover onmiddellijk toegang heeft tot de nieuwe primaire server. Zie SQL Database beveiliging na herstel na noodgeval 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 vanaf de primaire database. De geo-secundaire is standaard geconfigureerd met een standaardretentieperiode van zeven dagen. Zie automatische back-ups SQL Database voor meer informatie.

Belangrijk

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

Geo-secundair configureren

Zowel de primaire als de geo-secundaire laag moeten dezelfde servicelaag hebben. Het wordt ook ten zeerste aanbevolen dat de geo-secundaire wordt geconfigureerd met dezelfde redundantie en rekenkracht (DTU's of vCores) als de primaire opslag. Als de primaire werkbelasting te maken heeft met een zware schrijfworkload, kan een geo-secundaire met een lagere rekenkracht het mogelijk niet bijhouden. Dit veroorzaakt replicatievertraging op de geo-secundaire locatie en kan uiteindelijk leiden tot niet-beschikbaarheid van de geo-secundaire. Om deze risico's te beperken, zal actieve geo-replicatie indien nodig de transactielogboeksnelheid van de primaire instantie verminderen (beperken), zodat de secundaire databases hun achterstand kunnen inhalen.

Een ander gevolg van een onevenwichtige geo-secundaire configuratie is dat na een failover de prestaties van de toepassing kunnen worden beïnvloed door onvoldoende rekencapaciteit van de nieuwe primaire. In dat geval is het nodig om de database op te schalen om voldoende resources te hebben. Dit kan veel tijd in beslag nemen en vereist een failover met hoge beschikbaarheid aan het einde van het proces voor omhoog schalen, waardoor toepassingsworkloads mogelijk worden onderbroken.

Als u besluit om de geo-secundaire met een lagere rekenkracht te maken, moet u de logboek-IO-snelheid in de loop van de tijd op de primaire locatie bewaken. 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 50% bedraagt, moet de geo-secundaire database ten minste P4 (500 DTU) zijn. Gebruik de weergave sys.resource_stats om historische logboek-IO-gegevens op te halen. Als u recente logboek-IO-gegevens met een hogere granulariteit wilt ophalen die pieken op de korte termijn beter weerspiegelen, gebruikt u de weergave sys.dm_db_resource_stats .

Tip

Io-beperking van transactielogboeken op de primaire basis vanwege een 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.

De I/O van het transactielogboek op de primaire computer kan worden beperkt om redenen die geen verband houden met een lagere rekenkracht op een geo-secundaire locatie. Dit soort beperking kan zelfs optreden als de geo-secundaire computer dezelfde of hogere rekenkracht heeft dan de primaire. Zie Transactielogboeksnelheidsbeheer voor meer informatie, waaronder wachttypen voor verschillende soorten logboek-IO-beperking.

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, 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).

Geo-replicatie binnen meerdere abonnementen

Volg de stappen in deze sectie om een geo-secundaire locatie te maken in een ander abonnement dan het abonnement van het primaire abonnement (al dan niet onder dezelfde Azure Active Directory-tenant).

  1. Voeg het IP-adres van de clientcomputer die de onderstaande T-SQL-opdrachten uitvoert toe aan de serverfirewalls van zowel de primaire als secundaire servers. U kunt dat 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 het instellen van actieve geo-replicatie. Pas de aanmeldingsnaam en het wachtwoord indien nodig 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 master database op de secundaire server dezelfde aanmelding als op de primaire server met dezelfde naam, hetzelfde wachtwoord en dezelfde SID. Vervang de hexadecimale SID-waarde in de onderstaande voorbeeldopdracht door de waarde die is verkregen in stap 4.

    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 master database 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 naam van de secundaire server zo nodig aan. Zodra de opdracht is uitgevoerd, kunt u het geo-secundaire maken controleren door een query uit te voeren op de weergave sys.dm_geo_replication_link_status in de primaire database en de weergave sys.dm_operation_status in de master database op de primaire server. De tijd die nodig is om een geo-secundaire database te maken, is afhankelijk van de grootte van de primaire database.

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

Notitie

Bewerkingen voor geo-replicatie tussen abonnementen, waaronder installatie en geo-failover, worden alleen ondersteund met rest API & T-SQL-opdrachten.

Het toevoegen van een geo-secundaire locatie 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-secundaire locatie ondersteund wanneer u bent verbonden met de primaire server vanaf een openbaar IP-adres. Zodra een geo-secundaire locatie is toegevoegd, kan de openbare netwerktoegang worden geweigerd.

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

Referenties en firewallregels gesynchroniseerd houden

Wanneer u openbare netwerktoegang gebruikt om verbinding te maken met de database, wordt u aangeraden IP-firewallregels op databaseniveau te gebruiken voor geo-gerepliceerde databases. Deze regels worden gerepliceerd met de database, waardoor alle geo-secundaire databases 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 ondernemen 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-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.

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 naar de hogere laag wordt geschaald. Als u bijvoorbeeld het primaire niveau omhoog wilt schalen van Algemeen naar Bedrijfskritiek, moet u eerst de geo-secundaire waarde schalen naar Bedrijfskritiek. Als u probeert de schaal van de primaire of geo-secundaire op een manier te schalen die in strijd is met deze regel, 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 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.

Vertraging van geo-replicatie bewaken

Als u vertraging met betrekking tot RPO wilt controleren, gebruikt u replication_lag_sec kolom met 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 beperkt tot 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 doorgevoerd, 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 is null, betekent dit dat de primaire momenteel niet weet hoe ver achter een geo-secundaire locatie zich bevindt. Dit gebeurt meestal nadat het proces opnieuw is gestart en moet een tijdelijke situatie zijn. U kunt een waarschuwing verzenden als replication_lag_sec gedurende een langere periode NULL retourneert. Dit kan erop wijzen dat de geo-secundaire niet kan communiceren met de primaire vanwege een verbindingsfout.

Er zijn ook omstandigheden die ertoe kunnen leiden dat het verschil tussen last_commit tijd op de geo-secundaire en de primaire tijd groot wordt. Als er bijvoorbeeld een doorvoer wordt gemaakt op de primaire basis na een lange periode zonder wijzigingen, springt het verschil omhoog naar een grote waarde voordat het snel terugkeert naar nul. U kunt een waarschuwing verzenden als het verschil tussen deze twee waarden lang groot blijft.

Actieve geo-replicatie programmatisch beheren

Zoals eerder 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 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 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 niet op failovergroepen. Daarom zijn ze ook niet van toepassing op SQL Managed Instance, die alleen failovergroepen ondersteunt.

Opdracht Beschrijving
ALTER DATABASE Het argument ADD SECONDARY ON SERVER gebruiken om een secundaire database voor een bestaande database te maken en de gegevensreplicatie te starten
ALTER DATABASE Failover of FORCE_FAILOVER_ALLOW_DATA_LOSS gebruiken 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 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 beperkt tot het transactielogboek van een geo-secundaire.

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 wordt een primaire of secundaire database gemaakt, bijgewerkt of hersteld.
Databasestatus maken of bijwerken ophalen Retourneert de status tijdens een maakbewerking.
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 op voor een bepaalde database in een geo-replicatierelatie. Hiermee wordt de informatie opgehaald die zichtbaar is in de sys.geo_replication_links catalogusweergave.
Replicatiekoppeling verwijderen Hiermee verwijdert u een koppeling voor databasereplicatie. Kan niet worden uitgevoerd tijdens een failover.

Volgende stappen