Dela via

Aktiv geografisk replikering

Gäller för:Azure SQL Database

Den här artikeln innehåller och översikt över den aktiva geo-replikeringsfunktionen för Azure SQL Database, som gör att du kontinuerligt kan replikera data från en primär databas till en läsbar sekundär databas. Den läsbara sekundära databasen kan finnas i samma Azure-region som den primära eller, vanligare, i en annan region. Den här typen av läsbar sekundär databas kallas även för en geo-sekundär eller geo-replik.

Aktiv geo-replikering konfigureras per databas. Om du vill växla över en grupp databaser, eller om ditt program kräver en stabil anslutningsslutpunkt, bör du överväga failover-grupper i stället.

Du kan också migrera en SQL-databas med aktiv geo-replikering.

Översikt

Aktiv geo-replikering är utformad som en lösning för affärskontinuitet. Med aktiv geo-replikering kan du utföra snabb katastrofåterställning för enskilda databaser om det uppstår ett regionalt haveri eller ett storskaligt avbrott. När geo-replikering har konfigurerats kan du initiera en geo-omkoppling till en geografisk sekundärkoppling i en annan Azure-region. Geo-failover initieras programmatiskt av applikationen eller manuellt av användaren.

Följande diagram illustrerar en typisk konfiguration av ett geo-redundant molnprogram med aktiv geo-replikering.

Diagram över aktiv geo-replikering.

Om den primära databasen av någon anledning misslyckas kan du initiera en geo-failover till någon av dina sekundära databaser. När en sekundär befordras till den primära rollen länkas alla andra sekundärfiler automatiskt till den nya primära.

Du kan hantera geo-replikering och initiera en geo-failover med hjälp av någon av följande metoder:

Aktiv geo-replikering använder AlwaysOn-tillgänglighetsgruppens teknik för att asynkront replikera transaktionsloggen som genereras på den primära repliken till alla geo-repliker. När som helst kan en sekundär databas ligga något efter den primära databasen, men data på en sekundär är garanterat transaktionsmässigt konsekventa. Med andra ord visas inte ändringar som görs av icke-committerade transaktioner.

Anmärkning

Aktiv geo-replikering replikerar ändringar genom att strömma databastransaktionsloggen från den primära repliken till sekundära repliker. Det är inte relaterat till transaktionsreplikering, som replikerar ändringar genom att köra DML-kommandon (INSERT, UPDATE, DELETE) på prenumeranter.

Geo-replikering ger regional redundans. Regional redundans gör att program snabbt kan återställas från en permanent förlust av en hel Azure-region eller delar av en region, orsakad av naturkatastrofer, katastrofala mänskliga fel eller skadliga handlingar. Geo-replikerings-RPO finns i Översikt över affärskontinuitet med Azure SQL Database.

Följande bild visar ett exempel på aktiv geo-replikering som konfigurerats med en primär i regionen västra USA 2 och en geo-sekundär i regionen östra USA.

Skärmbild av Azure-portalen som visar en geo-replikeringsrelation för SQL DB.

Förutom katastrofberedskap kan aktiv geo-replikering användas i följande scenarier:

  • Databasmigrering: Du kan använda aktiv geo-replikering för att migrera en databas från en server till en annan med minimal stilleståndstid.
  • Programuppgraderingar: Du kan skapa en extra sekundär som en återställningskopia vid programuppgraderingar.

För att uppnå fullständig affärskontinuitet är det bara en del av lösningen att lägga till regional redundans för databasen. Återställning av ett program (tjänst) från slutpunkt till slutpunkt efter ett oåterkalleligt fel kräver återställning av alla komponenter som utgör tjänsten och alla beroende tjänster. Exempel på dessa komponenter är klientprogramvaran (till exempel en webbläsare med ett anpassat JavaScript), webbklientdelar, lagring och DNS. Det är viktigt att alla komponenter är motståndskraftiga mot samma fel och blir tillgängliga inom programmets mål för återställningstid (RTO). Därför måste du identifiera alla beroende tjänster och förstå de garantier och funktioner som de tillhandahåller. Sedan måste du vidta lämpliga åtgärder för att säkerställa att tjänsten fungerar under redundansväxlingen av de tjänster som den är beroende av. Mer information om hur du utformar lösningar för katastrofåterställning finns i Designa globalt tillgängliga tjänster med hjälp av Azure SQL Database.

Terminologi och funktioner

  • Automatisk asynkron replikering

    Du kan bara skapa en geo-sekundär för en befintlig databas. Den geo-sekundära kan skapas på valfri logisk server, förutom servern med den primära databasen. När den geo-sekundära repliken har skapats fylls den med data från den primära databasen. Den här processen kallas sådd. När en geo-sekundär har skapats och initierats, replikeras uppdateringar från den primära databasen automatiskt och asynkront till geo-sekundären. Asynkron replikering innebär att transaktioner utförs i den primära databasen innan de replikeras.

  • Läsbara geo-sekundära repliker

    Ett program kan komma åt en geo-sekundär replik för att köra läsfrågor genom att använda samma eller olika säkerhetsobjekt som används för åtkomst till den primära databasen. Mer information finns i Använda skrivskyddade repliker för att avlasta skrivskyddade frågearbetsbelastningar.

    Viktigt!

    Du kan använda geo-replikering för att skapa sekundära repliker i samma region som den primära. Du kan använda dessa sekundärfiler för att uppfylla utskalningsscenarier för läsning i samma region. En sekundär replik i samma region ger dock inte ytterligare motståndskraft mot oåterkalleliga fel eller storskaliga avbrott och är därför inte ett lämpligt redundansmål för haveriberedskap. Det garanterar inte heller isolering av tillgänglighetszoner. Använd zonredundant konfiguration på affärskritisk eller Premium-tjänstnivå eller zonredundant konfiguration på tjänstnivå för generell användning för att uppnå isolering av tillgänglighetszoner.

  • Failover (ingen dataförlust)

    Redundansväxling byter rollerna mellan primära och geo-sekundära databaser efter att fullständig datasynkronisering har genomförts, vilket säkerställer att inga data går förlorade. Varaktigheten av överflyttningen beror på storleken på transaktionsloggen på den primära som måste synkroniseras till den geo-sekundära. Omkoppling vid fel är utformat för följande scenarier:

    • Utföra DR-övningar i produktion när dataförlusten inte är acceptabel
    • Flytta databasen till en annan region
    • Returnera databasen till den primära regionen efter att avbrottet har åtgärdats, vilket kallas failback.

  • Tvingad failover (potentiell dataförlust)

    Tvingad redundans växlar omedelbart den geo-sekundära till den primära rollen utan att vänta på synkronisering med den primära. Alla transaktioner som har genomförts på den primära men som ännu inte replikerats till den sekundära går förlorade. Den här åtgärden är utformad som en återställningsmetod vid avbrott när den primära inte är tillgänglig, men databastillgängligheten måste snabbt återställas. När den ursprungliga primära noden är online igen återansluts den automatiskt, uppdateras med aktuell data från den primära noden och blir en ny geografisk sekundär nod.

    Viktigt!

    Efter antingen en failover eller en framtvingad failover ändras anslutningsslutpunkten för den nya primära eftersom den nu ligger på en annan logisk server.

  • Flera läsbara geo-sekundärfiler

    Upp till fyra geo-sekundärfiler kan skapas för en primär. Om det bara finns en sekundär, och det misslyckas, utsätts programmet för högre risk tills en ny sekundär skapas. Om det finns flera sekundärfiler förblir programmet skyddat även om någon av sekundärfilerna misslyckas. Ytterligare sekundärfiler kan också användas för att skala ut skrivskyddade arbetsbelastningar.

    Tips/Råd

    Om du använder aktiv georeplikering för att skapa en globalt distribuerad applikation och behöver ge skrivskyddad åtkomst till data i mer än fyra regioner, kan du skapa en sekundär replika av en sekundär replika (en process som kallas kedjning) för att skapa ytterligare georepliker. Replikeringsfördröjningen på länkade geo-repliker kan vara högre än på geo-repliker som är anslutna direkt till den primära. Konfiguration av länkade topologier för geo-replikering stöds endast programmatiskt och inte från Azure-portalen.

  • Geo-replikering av databaser i en elastisk pool

    Varje geo-sekundär kan vara en enskild databas eller en databas i en elastisk pool. Valet av elastisk pool för varje geo-sekundär databas är separat och beror inte på konfigurationen av någon annan replik i topologin (antingen primär eller sekundär). Varje elastisk pool finns i en enda logisk server. Eftersom databasnamnen på en logisk server måste vara unika kan flera geo-sekundärfiler för samma primära aldrig dela en elastisk pool.

  • Användarkontrollerad geo-redundans och återställning efter fel

    En geo-sekundär som har slutfört den initiala seedingen kan uttryckligen bytas till den primära rollen (bytas över) när som helst av programmet eller användaren. Under ett avbrott där den primära är otillgänglig kan endast tvingad överkoppling användas, vilket omedelbart uppgraderar en geosekundär till den nya primären. När avbrotten har åtgärdats gör systemet automatiskt den återställda primära till en geo-sekundär och ger den up-to-date med den nya primära. På grund av den asynkrona naturen av geo-replikering kan de senaste transaktionerna gå förlorade under tvingade överflyttningar om det primära misslyckas innan dessa transaktioner replikeras till en geo-sekundär. När en primär med flera geo-sekundärfiler redundansväxlar konfigurerar systemet automatiskt om replikeringsrelationer och länkar de återstående geo-sekundärfilerna till den nyligen upphöjda primära filen, utan att användaren behöver göra något. Efter att det avbrott som orsakade geo-redundansen har åtgärdats kan det vara önskvärt att returnera den primära till den ursprungliga regionen. Utför en manuell redundansväxling för att göra det.

  • Säkerhetskopiareplik

    Om din sekundära replik endast används för katastrofåterställning (DR) och inte har några läs- eller skrivarbetsbelastningar kan du ange repliken som viloläge för att spara på licenskostnaderna.

Förbereda för geografisk failover

Kontrollera att autentisering och nätverksåtkomst för den sekundära servern är korrekt konfigurerade för att säkerställa att programmet omedelbart kan komma åt den nya primära datorn efter geo-failover. Mer information finns i Konfigurera och hantera Azure SQL Database-säkerhet för geo-återställning eller redundans. Kontrollera också att kvarhållningsprincipen för säkerhetskopiering på den sekundära databasen matchar den primära databasens. Den här inställningen är inte en del av databasen och replikeras inte från den primära. Som standard konfigureras den geo-sekundära med en PITR-kvarhållningsperiod på sju dagar. Mer information finns i Automatiserade säkerhetskopieringar i Azure SQL Database.

Viktigt!

Om databasen är medlem i en failovergrupp kan du inte initiera failover med hjälp av geo-replikations-failover-kommandot. Använd redundanskommandot för gruppen. Om du behöver växla över en enskild databas, måste du först ta bort den från övergångsgruppen. Se Redundansgrupper för mer information.

Konfigurera geo-sekundär

Både den primära och geo-sekundära måste ha samma tjänstnivå. Vi rekommenderar också starkt att den geo-sekundära databasen konfigureras med samma säkerhetskopieringslagringens redundans, beräkningsnivå (etablerad eller serverlös) och beräkningsstorlek (DTU:er eller virtuella kärnor) som den primära. Om den primära noden har en tung skrivningsarbetsbelastning kanske en geo-sekundär med en mindre beräkningskapacitet inte kan hänga med. Det orsakar replikeringsfördröjning på den geo-sekundära och kan så småningom orsaka otillgänglighet för den geo-sekundära. För att minska dessa risker stryper aktiv geo-replikering vid behov den primäras transaktionsloggens skrivhastighet för att låta sekundärerna komma ikapp.

En annan konsekvens av en obalanserad geo-sekundärkonfiguration är att programprestanda kan bli lidande efter en överflyttning på grund av otillräcklig beräkningskapacitet för den nya primära noden. I så fall är det nödvändigt att skala upp databasen för att ha tillräckligt med resurser, vilket kan ta lång tid, och kräver en redundansväxling med hög tillgänglighet i slutet av uppskalningsprocessen, vilket kan avbryta programarbetsbelastningarna.

Om du bestämmer dig för att skapa den geo-sekundära med en annan konfiguration bör du övervaka loggens I/O-hastighet på den primära över tid. På så sätt kan du beräkna den minsta beräkningsstorleken för den geo-sekundära som krävs för att upprätthålla replikeringsbelastningen. Om din primära databas till exempel är P6 (1 000 DTU) och dess logg-I/O bibehålls vid 50%måste den geo-sekundära vara minst P4 (500 DTU). Om du vill hämta historiska I/O-loggdata använder du vyn sys.resource_stats . Om du vill hämta de senaste logg-I/O-data med högre kornighet som bättre återspeglar kortsiktiga toppar, använder du vyn sys.dm_db_resource_stats.

Tips/Råd

I/O-begränsning för transaktionsloggar kan inträffa:

  • Om den geo-sekundär är i en lägre beräkningskapacitet än den primära. Leta efter HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO väntetyp i sys.dm_exec_requests och sys.dm_os_wait_stats databasvyer.
  • Orsaker som inte är relaterade till beräkningsstorlek. Mer information, inklusive väntetyper för olika typer av logg-I/O-begränsning, finns i Styrning av transaktionsloggfrekvens.

Som standard är redundans för säkerhetskopiering av den geo-sekundära databasen samma som för den primära databasen. Du kan välja att konfigurera en geo-sekundär med en annan redundans för lagring av säkerhetskopior. Säkerhetskopior görs alltid på den primära databasen. Om den sekundära är konfigurerad med en annan redundans för lagring av säkerhetskopior, kommer nya säkerhetskopior efter en geo-failover, när den geo-sekundära promoveras till den primära, att lagras och faktureras enligt den typ av lagring (RA-GRS, ZRS, LRS) som valts på den nya primära (tidigare sekundära).

Spara på kostnader med väntelägesrepliken

Om din sekundära replik endast används för haveriberedskap (DR) och inte har några läs- eller skrivarbetsbelastningar kan du spara på licenskostnaderna genom att markera databasen för reservläge när du konfigurerar en ny aktiv geo-replikeringsrelation.

Granska standby-replikan utan licenskrav för att lära dig mer.

Geo-replikering mellan prenumerationer

  • Du kan använda Azure-portalen för att konfigurera aktiv geo-replikering mellan prenumerationer så länge båda prenumerationerna finns i samma Microsoft Entra-klientorganisation.

  • Det går inte att skapa en geo-sekundär mellanprenumeration på en logisk server i samma eller en annan Microsoft Entra-klientorganisation när Microsoft Entra-endast autentisering är aktiverat på en primär eller sekundär logisk server och skapandet görs med hjälp av en Microsoft Entra-ID-användare.

Metoder och stegvisa instruktioner finns i Självstudie: Konfigurera aktiv geo-replikering och redundans (Azure SQL Database).

Privata slutpunkter

Det går inte att lägga till en geo-sekundär med T-SQL när du ansluter till den primära servern via en privat slutpunkt.

Synkronisera autentiseringsuppgifter och brandväggsregler

När du använder offentlig nätverksåtkomst för att ansluta till databasen rekommenderar vi att du använder IP-brandväggsregler på databasnivå för geo-replikerade databaser. Dessa regler replikeras med databasen, vilket säkerställer att alla geo-sekundärfiler har samma IP-brandväggsregler som den primära. Den här metoden eliminerar behovet för kunder att manuellt konfigurera och underhålla brandväggsregler på servrar som är värdar för de primära och sekundära databaserna. På samma sätt säkerställer användningen av oberoende databasanvändare för dataåtkomst att både primära och sekundära databaser alltid har samma autentiseringsuppgifter. På så sätt kan det efter en geo-övergång inte uppstå några avbrott på grund av autentiseringsfel. Om du använder inloggningar och användare (i stället för inneslutna användare) måste du vidta extra åtgärder för att säkerställa att samma inloggningar finns för den sekundära databasen. Konfigurationsinformation finns i Konfigurera och hantera Azure SQL Database-säkerhet för geo-återställning eller redundans.

Skala primärdatabas

Du kan skala upp eller skala ned den primära databasen till en annan beräkningsstorlek (inom samma tjänstnivå) utan att koppla från några geo-sekundärfiler. När du skalar upp rekommenderar vi att du skalar upp den geo-sekundära först och sedan skalar upp den primära. När du skalar ned ändrar du ordningen: skala ned den primära först och skala sedan ned den sekundära.

Information om failover-grupper finns i granska skala en replik i en failover-grupp.

Förhindra förlust av kritiska data

På grund av den långa svarstiden för nätverk i stora områden använder geo-replikering en asynkron replikeringsmekanism. Asynkron replikering gör risken för dataförlust oundviklig om den primära replikeringen misslyckas. För att skydda kritiska transaktioner mot dataförlust kan en programutvecklare anropa den sp_wait_for_database_copy_sync lagrade proceduren omedelbart efter att transaktionen har genomförts. Ett anrop till sp_wait_for_database_copy_sync blockerar den anropande tråden tills den senaste committerade transaktionen har överförts och härdats i den sekundära databasens transaktionslogg. Den väntar också på att de överförda transaktionerna ska återuppspelas (göras om) på den sekundära servern. sp_wait_for_database_copy_sync är begränsad till en specifik geo-replikeringslänk. Alla användare med anslutningsrättigheter till den primära databasen kan anropa den här proceduren.

Anmärkning

sp_wait_for_database_copy_sync förhindrar dataförlust efter geo-omstart för specifika transaktioner, men garanterar inte full synkronisering för läsaccess. Fördröjningen som orsakas av ett sp_wait_for_database_copy_sync proceduranrop kan vara betydande och beror på storleken på den ännu inte överförda transaktionsloggen på den primära vid tidpunkten för anropet.

Övervaka tidskrävande geo-replikering

Om du vill övervaka fördröjning med avseende på RPO använder du kolumnen replication_lag_sec i sys.dm_geo_replication_link_status på den primära databasen. Den visar fördröjning i sekunder mellan de transaktioner som checkas in på den primära och härdas till transaktionsloggen på den sekundära. Om fördröjningen till exempel är en sekund innebär det att om det primära påverkas av ett avbrott just nu och en geo-redundans initieras, går transaktioner som bekräftades under den senaste sekunden förlorade.

Om du vill mäta fördröjningen med avseende på ändringar i den primära databasen som har skrivits till den geo-sekundära, jämför du last_commit tiden på den geo-sekundära med samma värde på den primära databasen.

Tips/Råd

Om replication_lag_sec på den primära servern är NULL innebär det att den primära servern för närvarande inte vet hur långt efter en geo-sekundär server är. Detta inträffar vanligtvis när processen startas om och bör vara ett tillfälligt villkor. Överväg att skicka en avisering om replication_lag_sec returnerar NULL under en längre tid. Det kan tyda på att den geo-sekundära inte kan kommunicera med den primära på grund av ett anslutningsfel.

Det finns också villkor som kan göra att skillnaden mellan last_commit tid på den geo-sekundära och den primära blir stor. Om till exempel en incheckning görs på den primära efter en lång period utan ändringar, hoppar skillnaden upp till ett stort värde innan den snabbt återgår till noll. Överväg att skicka en avisering om skillnaden mellan dessa två värden förblir stor under en lång tid.

Hantera geo-replikering programmatiskt aktivt

Aktiv geo-replikering kan också hanteras programmatiskt med T-SQL, Azure PowerShell och REST API. I följande tabeller beskrivs vilken uppsättning kommandon som är tillgängliga. Aktiv geo-replikering innehåller en uppsättning Azure Resource Manager-API:er för hantering, inklusive Azure SQL Database REST API och Azure PowerShell cmdletar. Dessa API:er stöder rollbaserad åtkomstkontroll i Azure (Azure RBAC). Mer information om hur du implementerar åtkomstroller finns i Rollbaserad åtkomstkontroll i Azure (Azure RBAC).

Viktigt!

Dessa T-SQL-kommandon gäller endast för aktiv geo-replikering och gäller inte för redundansgrupper.

Kommando Beskrivning
ÄNDRA DATABAS Använd ARGUMENTET LÄGG TILL SEKUNDÄR PÅ SERVER för att skapa en sekundär databas för en befintlig databas och starta datareplikering
ÄNDRA DATABAS Använd FAILOVER eller FORCE_FAILOVER_ALLOW_DATA_LOSS för att ändra en sekundär databas till att bli primär och initiera failover.
ÄNDRA DATABAS Använd REMOVE SECONDARY ON SERVER för att avsluta en datareplikering mellan en SQL Database och den angivna sekundära databasen.
sys.geo_replication_links Returnerar information om alla befintliga replikeringslänkar för varje databas på en server.
sys.dm_geo_replication_link_status Hämtar den senaste replikeringstiden, den senaste replikeringsfördröjningen och annan information om replikeringslänken för en viss databas.
sys.dm_operation_status Visar status för alla databasåtgärder, inklusive ändringar av replikeringslänkar.
sys.sp_wait_for_database_copy_sync Gör att programmet väntar tills alla bekräftade transaktioner har skrivits till transaktionsloggen för en geografisk sekundär.

Relaterat innehåll

Konfigurera aktiv geo-replikering:

Annat innehåll för affärskontinuitet: