Aktiv geo-replikering

  • Artikel

Gäller för:Azure SQL Database

Aktiv geo-replikering är en funktion som gör att du kan skapa en kontinuerligt synkroniserad läsbar sekundär databas för en primär databas. Den läsbara sekundära databasen kan finnas i samma Azure-region som den primära eller, vilket är mer vanligt, 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 och stöder endast manuell redundans. Om du vill redundansväxla en grupp databaser, eller om programmet kräver en stabil anslutningsslutpunkt, bör du överväga redundansgrupper i stället.

Du kan också använda Migrera SQL Database 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 haveriberedskap 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-redundans till en geo-sekundär i en annan Azure-region. Geo-redundans initieras programmatiskt av programmet eller manuellt av användaren.

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

active geo-replication

Om den primära databasen av någon anledning misslyckas kan du initiera en geo-redundansväxling 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-redundans med 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-bakåtkompatibla transaktioner.

Kommentar

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.

Följande bild visar ett exempel på aktiv geo-replikering som konfigurerats med en primär i regionen USA, norra centrala och en geo-sekundär i regionen USA, södra centrala.

geo-replication relationship

Förutom haveriberedskap 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 haveriberedskap finns i Designa molnlösningar för haveriberedskap med aktiv geo-replikering.

Aktiv geo-replikeringsterminologi 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 seeding. När en geo-sekundär har skapats och skapats replikeras uppdateringar till den primära databasen automatiskt och asynkront till den geo-sekundära repliken. 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 skrivskyddade frågor med 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åer eller zonredundant konfiguration på tjänstnivå för generell användning för att uppnå isolering i tillgänglighetszonen.

  • Redundansväxling (ingen dataförlust)

    Redundansväxling växlar rollerna för primära och geo-sekundära databaser när fullständig datasynkronisering har slutförts så att inga data går förlorade. Redundansväxlingens varaktighet beror på storleken på transaktionsloggen på den primära som måste synkroniseras med den geo-sekundära. Redundans är utformat för följande scenarier:

    • Utföra DR-detaljgranskningar 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 (kallas återställning efter fel).

  • Tvingad redundansväxling (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 checkats in på den primära men som ännu inte replikerats till den sekundära åtgärden 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 är online igen återansluts den automatiskt, återställs med aktuella data från den primära och blir den nya geo-sekundära.

    Viktigt!

    Efter redundansväxling eller framtvingad redundans ändras anslutningsslutpunkten för de nya primära ändringarna eftersom den nya primära nu finns 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.

    Dricks

    Om du använder aktiv geo-replikering för att skapa ett globalt distribuerat program och behöver ge skrivskyddad åtkomst till data i fler än fyra regioner, kan du skapa en sekundär av en sekundär (en process som kallas länkning) för att skapa ytterligare geo-repliker. 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 första seedingen kan uttryckligen växlas till den primära rollen (redundas över) när som helst av programmet eller användaren. Under ett avbrott där den primära är otillgänglig kan endast tvingad redundans användas, vilket omedelbart befordrar en geo-sekundär till den nya primära. När avbrotten har åtgärdats gör systemet automatiskt den återställda primära till en geo-sekundär och uppdaterar den med den nya primära. På grund av den asynkrona typen av geo-replikering kan de senaste transaktionerna gå förlorade under framtvingade redundansväxlingar 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.

  • Väntelägesreplik

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

Förbereda för geo-redundans

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-redundansväxling. Mer information finns i SQL Database-säkerhet efter haveriberedskap. 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 STANDARD-PITR-kvarhållningsperiod på sju dagar. Mer information finns i Automatiserade säkerhetskopieringar av SQL Database.

Viktigt!

Om databasen är medlem i en redundansgrupp kan du inte initiera redundansväxlingen med hjälp av kommandot för geo-replikeringsredundans. Använd redundanskommandot för gruppen. Om du behöver redundansväxlara en enskild databas måste du först ta bort den från redundansgruppen. Mer information finns i Redundansgrupper .

Konfigurera geo-sekundär

Både den primära och geo-sekundära krävs för att ha samma tjänstnivå. Vi rekommenderar också starkt att den geo-sekundära konfigureras med samma redundans för säkerhetskopieringslagring, beräkningsnivå (etablerad eller serverlös) och beräkningsstorlek (DTU:er eller virtuella kärnor) som primär. Om den primära har en tung skrivningsarbetsbelastning kanske en geo-sekundär med lägre beräkningsstorlek 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 minskar aktiv geo-replikering (begränsningar) den primäras transaktionsloggfrekvens om det behövs för att låta dess sekundärfiler komma ikapp.

En annan konsekvens av en obalanserad geo-sekundär konfiguration är att programprestanda kan bli lidande efter redundansväxlingen på grund av otillräcklig beräkningskapacitet för den nya primära. 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 på 50 %, måste den geo-sekundära vara minst P4 (500 DTU). Om du vill hämta historiska logg-I/O-data använder du vyn sys.resource_stats . Om du vill hämta senaste logg-I/O-data med högre kornighet som bättre återspeglar kortsiktiga toppar använder du vyn sys.dm_db_resource_stats .

Dricks

Transaktionsloggens I/O-begränsning på den primära på grund av lägre beräkningsstorlek på en geo-sekundär rapporteras med hjälp av HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO väntetyp som visas i databasvyerna sys.dm_exec_requests och sys.dm_os_wait_stats .

Transaktionsloggens I/O på den primära kan begränsas av orsaker som inte är relaterade till lägre beräkningsstorlek på en geo-sekundär. Den här typen av begränsning kan inträffa även om den geo-sekundära har samma eller högre beräkningsstorlek än den primära. 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 lagringen 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, lagras och faktureras nya säkerhetskopior efter en geo-redundans när den geo-sekundära uppgraderas till den primära, och faktureras enligt den typ av lagring (RA-GRS, ZRS, LRS) som valts på den nya primära (föregående 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 ange databasen för vänteläge när du konfigurerar en ny aktiv geo-replikeringsrelation.

Läs mer i den licensfria väntelägesrepliken .

Geo-replikering mellan prenumerationer

Använd Transact-SQL (T-SQL) för att skapa en geo-sekundär i en prenumeration som skiljer sig från prenumerationen för den primära (oavsett om det är under samma klientorganisation för Microsoft Entra ID (tidigare Azure Active Directory) eller inte). Mer information finns i Konfigurera aktiv geo-replikering .

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-redundansväxling inte uppstå några avbrott på grund av autentiseringsautentiseringsfel. 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 inloggningar och användare.

Skala en primär databas

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 gör du det i omvänd ordning: skala ned den primära först och sedan den sekundära.

Kommentar

Om du har skapat en geo-sekundär server som en del av konfigurationen för redundansgrupper så rekommenderar vi inte att du skalar ned den. Detta säkerställer att datanivån har tillräckligt med kapacitet för att bearbeta din normala arbetsbelastning efter en geo-redundansväxling.

Viktigt!

Den primära databasen i en redundansgrupp kan inte skalas till en högre tjänstnivå (utgåva) om inte den sekundära databasen först skalas till den högre nivån. Om du till exempel vill skala upp den primära från Generell användning till Affärskritisk måste du först skala den geo-sekundära till Affärskritisk. Om du försöker skala den primära eller geo-sekundära på ett sätt som bryter mot den här regeln får du följande fel:

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.

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. Anrop sp_wait_for_database_copy_sync blockerar den anropande tråden tills den senast checkade transaktionen har överförts och härdats i transaktionsloggen för den sekundära databasen. Det väntar dock inte på att de överförda transaktionerna ska spelas upp igen (görs om) på den sekundära. 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.

Kommentar

sp_wait_for_database_copy_sync förhindrar dataförlust efter geo-redundans för specifika transaktioner, men garanterar inte fullständig synkronisering för läsåtkomst. 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 RPO använder du kolumnen replication_lag_sec i sys.dm_geo_replication_link_status i 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 den primära påverkas av ett avbrott just nu och en geo-redundans initieras, går transaktioner som checkas in under den sista sekunden förlorade.

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

Dricks

Om replication_lag_sec på den primära är NULL innebär det att den primära för närvarande inte vet hur långt bakom en geo-sekundär ä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 tidsperiod. 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 aktiv geo-replikering programmatiskt

Som tidigare nämnts kan aktiv geo-replikering 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).

T-SQL: Hantera geo-redundans för enkla databaser och pooldatabaser

Viktigt!

Dessa T-SQL-kommandon gäller endast för aktiv geo-replikering och gäller inte för redundansgrupper. Därför gäller de inte heller för SQL Managed Instance, som endast stöder redundansgrupper.

Kommando beskrivning
ALTER DATABASE 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
ALTER DATABASE Använd REDUNDANS eller FORCE_FAILOVER_ALLOW_DATA_LOSS för att växla en sekundär databas till att vara primär för att initiera redundansväxling
ALTER DATABASE 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 incheckade transaktioner har hårdnat till transaktionsloggen för en geo-sekundär.

PowerShell: Hantera geo-redundans för enkla databaser och pooldatabaser

Kommentar

Den här artikeln använder Azure Az PowerShell-modulen, som är den rekommenderade PowerShell-modulen för interaktion med Azure. För att komma igång med Az PowerShell kan du läsa artikeln om att installera Azure PowerShell. Information om hur du migrerar till Az PowerShell-modulen finns i artikeln om att migrera Azure PowerShell från AzureRM till Az.

Viktigt!

PowerShell Azure Resource Manager-modulen stöds fortfarande av Azure SQL Database, men all framtida utveckling gäller för Az.Sql-modulen. Dessa cmdletar finns i AzureRM.Sql. Argumenten för kommandona i Az-modulen och i AzureRm-modulerna är väsentligen identiska.

Cmdlet beskrivning
Get-AzSqlDatabase Hämtar en eller flera databaser.
New-AzSqlDatabaseSecondary Skapar en sekundär databas för en befintlig databas och startar datareplikeringen.
Set-AzSqlDatabaseSecondary Växlar en sekundär databas till att vara primär för att initiera redundans.
Remove-AzSqlDatabaseSecondary Avslutar datareplikering mellan en SQL Database och den angivna sekundära databasen.
Get-AzSqlDatabaseReplicationLink Hämtar geo-replikeringslänkarna för en databas.

Dricks

Exempelskript finns i Konfigurera och redundanshantera en enskild databas med aktiv geo-replikering och Konfigurera och redundanshantera en pooldatabas med aktiv geo-replikering.

REST API: Hantera geo-redundans för enkla databaser och pooldatabaser

API beskrivning
Skapa eller uppdatera databas (createMode=Återställ) Skapar, uppdaterar eller återställer en primär eller sekundär databas.
Hämta status för skapa eller uppdatera databas Returnerar statusen under en skapandeåtgärd.
Ange sekundär databas som primär (planerad redundans) Anger vilken sekundär databas som är primär genom att växla över från den aktuella primära databasen. Det här alternativet stöds inte för SQL Managed Instance.
Ange sekundär databas som primär (oplanerad redundans) Anger vilken sekundär databas som är primär genom att växla över från den aktuella primära databasen. Den här åtgärden kan leda till dataförlust. Det här alternativet stöds inte för SQL Managed Instance.
Hämta replikeringslänk Hämtar en specifik replikeringslänk för en viss databas i ett geo-replikeringssamarbete. Den hämtar den information som visas i sys.geo_replication_links katalogvyn. Det här alternativet stöds inte för SQL Managed Instance.
Replikeringslänkar – lista efter databas Hämtar alla replikeringslänkar för en viss databas i ett geo-replikeringssamarbete. Den hämtar den information som visas i sys.geo_replication_links katalogvyn.
Ta bort replikeringslänk Tar bort en databasreplikeringslänk. Det går inte att göra under redundansväxlingen.

Nästa steg