Aktiv geo-replikering

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 oftare i en annan region. Den här typen av läsbara sekundära databaser kallas även geo-sekundära eller geo-repliker.

Aktiv geo-replikering är utformad som en lösning för affärskontinuation som gör att du kan utföra snabb haveriberedskap för enskilda databaser vid ett regionalt haveri eller ett storskaligt avbrott. När geo-replikering har ställts in kan du initiera en geo-redundans till en geo-sekundär i en annan Azure-region. Geo-redundansen initieras programmatiskt av programmet eller manuellt av användaren.

Om ditt program kräver en stabil anslutningsslutpunkt och automatiskt stöd för geo-redundans utöver geo-replikering använder du automatiska redundansgrupper.

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

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

Du kan hantera geo-replikering och initiera en geo-redundans med hjälp av följande:

• Den Azure Portal
• PowerShell: Enkel databas
• PowerShell: Elastisk pool
• Transact-SQL: Enkel databas eller elastisk pool
• REST API: Enkel databas

Aktiv geo-replikering utnyttjar Always On-tillgänglighetsgruppens teknik för att asynkront replikera transaktionsloggen som genererats på den primära repliken till alla geo-repliker. När som helst kan en sekundär databas ligga något bakom den primära databasen, men data på en sekundär databas är garanterat transaktionellt konsekventa. Med andra ord är ändringar som görs av ogenomsagd transaktion inte synliga.

Regional redundans som tillhandahålls av geo-replikering gör att program snabbt kan återställas från en permanent förlust av en hel Azure-region eller delar av en region som orsakas av naturkatastrofer, oåterkalleliga mänskliga fel eller skadliga åtgärder. Du hittar RPO för geo-replikering i Översikt över affärskontinuation.

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 region i regionen USA, södra centrala.

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 avbrottstid.
• Programuppgraderingar: Du kan skapa en extra sekundär kopia som en återställning efter fel under programuppgraderingar.

För att uppnå fullständig affärskontinuhet är det bara en del av lösningen att lägga till regional redundans för databaser. Återställning av ett program (tjänst) från slutet till slut efter ett oåterkalleligt fel kräver återställning av alla komponenter som utgör tjänsten och eventuella beroende tjänster. Exempel på dessa komponenter är klientprogramvaran (till exempel en webbläsare med ett anpassat JavaScript), klientdelar för webben, lagring och DNS. Det är viktigt att alla komponenter är motståndskraftiga mot samma fel och blir tillgängliga inom mål för återställningstid (RTO) för ditt program. Därför måste du identifiera alla beroende tjänster och förstå de garantier och funktioner som de erbjuder. Sedan måste du vidta lämpliga åtgärder för att säkerställa att tjänsten fungerar under redundansen av de tjänster som den är beroende av. Mer information om hur du utformar lösningar för haveriberedskap finns i Designing Cloud Solutions for Disaster Recovery Using active geo-replication (Utforma molnlösningar för haveriberedskap med aktiv geo-replikering).

Terminologi och funktioner för aktiv geo-replikering

• Automatisk asynkron replikering

  Du kan bara skapa en geo-sekundär databas för en befintlig databas. Den geo-sekundära kan skapas på en annan logisk server än servern med den primära databasen. När den geo-sekundära repliken har skapats fylls den med data för den primära databasen. Den här processen kallas seeding. När en geo-sekundär har skapats och seedats replikeras uppdateringar till den primära databasen automatiskt och replikeras asynkront till den geo-sekundära repliken. Asynkron replikering innebär att transaktioner genomförs på 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 secondaries för att uppfylla lässkalningsscenarier 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 Affärskritisk eller Premium zonredundant konfiguration för tjänstnivåer eller Generell användning redundant konfiguration av zonredundant tjänstnivå för att uppnå isolering av tillgänglighetszoner.

• Planerad geo-redundans

  Planerad geo-redundans växlar rollerna för primära och geo-sekundära databaser efter fullständig datasynkronisering. En planerad redundans resulterar inte i dataförlust. Varaktigheten för planerad geo-redundans beror på storleken på transaktionsloggen på den primära som måste synkroniseras till den geo-sekundära. Planerad geo-redundans är utformad för följande scenarier:

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

• Oplanerad geo-redundans

  Oplanerad, eller framtvingad, geo-redundans växlar omedelbart den geo-sekundära till den primära rollen utan någon synkronisering med den primära. Alla transaktioner som genomförs på den primära men som ännu inte har replikerats till den sekundära förloras. Den här åtgärden är utformad som en återställningsmetod under avbrott när den primära inte är tillgänglig, men databasens tillgänglighet måste återställas snabbt. När den ursprungliga primära är online igen ansluts den automatiskt igen, skickas igen med aktuella primära data och blir en ny geo-sekundär.

  Viktigt

  Efter planerad eller oplanerad geo-redundans ändras anslutningsslutpunkten för den nya primära servern eftersom den nya primära nu finns på en annan logisk server.

• Flera läsbara geo-secondaries

  Upp till fyra geo-sekunders kan skapas för en primär. Om det bara finns en sekundär, och den misslyckas, exponeras programmet för högre risk tills en ny sekundär skapas. Om det finns flera secondaries förblir programmet skyddat även om en av de andra inte fungerar. Ytterligare secondaries kan också användas för att skala ut skrivskyddade arbetsbelastningar.

  Tips

  Om du använder aktiv geo-replikering för att skapa ett globalt distribuerat program och behöver ge skrivskyddade å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öjning på länkade geo-repliker kan vara högre än på geo-repliker som är direkt anslutna till den primära repliken. Att konfigurera topologier för länkad geo-replikering stöds endast programmatiskt och inte från Azure Portal.

• Geo-replikering av databaser i en elastisk pool

  Varje geo-sekundär databas kan vara en enkel 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 databasnamn på en logisk server måste vara unika kan flera geo-sekundärfiler av samma primära server aldrig dela en elastisk pool.

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

  En geo-sekundär som har slutfört den inledande seedingen kan när som helst växlas till den primära rollen (växlades över) när som helst av programmet eller användaren. Under ett avbrott där den primära är otillgänglig kan endast en oplanerad geo-redundans användas. Detta gör att en geo-sekundär blir den nya primära. När avbrottet minimeras gör systemet automatiskt den återställda primära till geo-sekundär och gör den uppdaterad med den nya primära. På grund av geo-replikeringens asynkrona natur kan de senaste transaktionerna gå förlorade under oplanerade geo-redundanser om den primära misslyckas innan transaktionerna replikeras till en geo-sekundär. När en primär dator med flera geo-sekundersrepliker misslyckas konfigurerar systemet automatiskt om replikeringsrelationer och länkar återstående geo-sekundärfiler till den nyligen uppflyttade primära, utan att användaren behöver göra något. Efter avbrottet som orsakade geo-redundansen kan det vara önskvärt att den primära regionen återgår till den ursprungliga regionen. Det gör du genom att anropa en planerad geo-redundans.

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 efter geo-redundans. Mer information finns i SQL Database säkerhet efter haveriberedskap. Kontrollera också att principen för kvarhållning av säkerhetskopior på den sekundära databasen matchar den primära. 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 standardperiod för PITR-kvarhållning på sju dagar. Mer information finns i SQL Database säkerhetskopieringar.

Konfigurera geo-sekundär

Både primär och geo-sekundär måste ha samma tjänstnivå. Vi rekommenderar också starkt att den geo-sekundära är konfigurerad med samma redundans och beräkningsstorlek för säkerhetskopiering (DPU:er eller virtuella kärnor) som den primära. Om den primära har en tung skrivarbetsbelastning kanske en geo-sekundär med en lägre beräkningsstorlek inte kan hålla reda på det. Detta leder till 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 minimera dessa risker minskar den aktiva geo-replikeringen (begränsar) den primära primära transaktionsloggfrekvensen om det behövs för att låta de andra replikerna komma ikapp.

En annan följd av en obalanserad geo-sekundär konfiguration är att efter redundansen kan programprestanda påverkas på grund av otillräcklig beräkningskapacitet hos den nya primära. I så fall är det nödvändigt att skala upp databasen så att den har tillräckligt med resurser, vilket kan ta lång tid och kräver redundans med hög tillgänglighet i slutet av uppskalningsprocessen, vilket kan avbryta programarbetsbelastningar.

Om du bestämmer dig för att skapa den geo-sekundära instansen med en lägre beräkningsstorlek 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 instansen som krävs för att upprätthålla replikeringsbelastningen. Om den primära databasen till exempel är P6 (1 000 DTU) och dess logg-I/S är 50 % måste den geo-sekundära vara minst P4 (500 DTU). Om du vill hämta historiska logg-IO-data använder sys.resource_stats vyn. Om du vill hämta senaste logg-IO-data med högre kornighet som bättre återspeglar kortsiktiga toppar använder du sys.dm_db_resource_stats vyn.

Som standard är redundans för lagring av säkerhetskopior för 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 tas alltid på den primära databasen. Om den sekundära har konfigurerats med en annan redundans för lagring av säkerhetskopior kommer nya säkerhetskopior efter en geo-redundans att lagras och faktureras enligt typen av lagring (RA-GRS, ZRS, LRS) som valts på den nya primära (föregående sekundära).

Geo-replikering mellan prenumerationer

Om du vill skapa en geo-sekundär i en annan prenumeration än prenumerationen för den primära (oavsett om det är under samma Azure Active Directory klientorganisation eller inte) följer du stegen i det här avsnittet.

1. Lägg till IP-adressen för den klientdator som kör T-SQL nedan i serverbrandväggen för både den primära och den sekundära servern. Du kan bekräfta IP-adressen genom att köra följande fråga när du är ansluten till den primära servern från samma klientdator.

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

   Mer information finns i Konfigurera brandväggen.

2. I huvuddatabasen på den primära servern skapar du en SQL inloggning för aktiv geo-replikering. Justera inloggningsnamn och lösenord efter behov.

   create login geodrsetup with password = 'ComplexPassword01';
   

3. I samma databas skapar du en användare för inloggningen och lägger till den i dbmanager rollen:

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

4. Anteckna SID-värdet för den nya inloggningen. Hämta SID-värdet med hjälp av följande fråga.

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

5. Anslut till den primära databasen (inte huvuddatabasen) och skapa en användare för samma inloggning.

   create user geodrsetup for login geodrsetup;
   

6. Lägg till användaren i rollen i samma db_owner databas.

   alter role db_owner add member geodrsetup;
   

7. I huvuddatabasen på den sekundära servern skapar du samma inloggning som på den primära servern med samma namn, lösenord och SID. Ersätt det hexadecimala SID-värdet i exempelkommandot nedan med det som erhölls i steg 4.

   create login geodrsetup with password = 'ComplexPassword01', sid=0x010600000000006400000000000000001C98F52B95D9C84BBBA8578FACE37C3E;
   

8. I samma databas skapar du en användare för inloggningen och lägger till den i dbmanager rollen.

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

9. Anslut till huvuddatabasen på den primära servern med den nya inloggningen och initiera geodrsetup geo-sekundär generering på den sekundära servern. Justera databasnamnet och det sekundära servernamnet efter behov. När kommandot har körts kan du övervaka den geo-sekundära genereringen genom att fråga sys.dm_geo_replication_link_status-vyn i den primära databasen och sys.dm_operation_status-vyn i huvuddatabasen på den primära servern. Hur lång tid det tar att skapa en geo-sekundär databas beror på storleken på den primära databasen.

   alter database [dbrep] add secondary on server [servername];
   

10. När den geo-sekundära har skapats kan användare, inloggningar och brandväggsregler som skapats med den här proceduren tas bort.

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-secondaries har samma IP-brandväggsregler som den primära. Den här metoden eliminerar behovet av att kunder manuellt konfigurerar och underhåller 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 inneslutna databasanvändare för dataåtkomst att både primära och sekundära databaser alltid har samma autentiseringsuppgifter. Det innebär att det efter en geo-redundans inte finns några avbrott på grund av matchningsfel för autentiseringsuppgifter. 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 se till att samma inloggningar finns för den sekundära databasen. Konfigurationsinformation finns i Så här konfigurerar du inloggningar och användare.

Skala primär databas

Du kan skala upp eller ned den primära databasen till en annan beräkningsstorlek (inom samma tjänstnivå) utan att koppla från några geo-andra. 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 skalar du om i omvänd ordning: skala ned den primära först och skala sedan ned den sekundära.

Förhindra förlust av kritiska data

På grund av den höga svarstiden i breda nätverk använder geo-replikering en asynkron replikeringsmekanism. Asynkron replikering gör det möjligt att förlora data om den primära misslyckas. För att skydda kritiska transaktioner mot dataförlust kan en programutvecklare anropa den sp_wait_for_database_copy_sync lagrade proceduren direkt efter att transaktionen har genomförs. Anrop blockerar anropstråden tills den senast införda transaktionen har överförts sp_wait_for_database_copy_sync och härdats i transaktionsloggen för den sekundära databasen. Den väntar dock inte på att de överförda transaktionerna ska spelas upp (göra om) på den sekundära. sp_wait_for_database_copy_sync är begränsad till en specifik geo-replikeringslänk. Alla användare med anslutningsbehörighet till den primära databasen kan anropa den här proceduren.

Övervaka fördröjning för geo-replikering

Om du vill övervaka fördröjning i förhållande till RPO använder replication_lag_sec kolumn i sys.dm_geo_replication_link_status på den primära databasen. Den visar fördröjning i sekunder mellan de transaktioner som genomförs på den primära och härdade 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 så går transaktioner som genomförs under den sista sekunden förlorade.

För att mäta fördröjning med avseende på ändringar i den primära databasen som har härdats 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.

Hantera aktiv geo-replikering programmässigt

Som vi nämnt tidigare kan aktiv geo-replikering också hanteras programmatiskt med hjälp av T-SQL, Azure PowerShell och REST API. Följande tabeller beskriver uppsättningen kommandon som är tillgängliga. Aktiv geo-replikering innehåller en uppsättning Azure Resource Manager API:er för hantering, inklusive cmdletarna Azure SQL Database REST API och Azure PowerShell. 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

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

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

Nästa steg

• Exempelskript finns i:
  • Konfigurera och redundans för en enkel databas med aktiv geo-replikering.
  • Konfigurera och redundans för en pooldatabas med aktiv geo-replikering.
• SQL Database också stöd för automatiska redundansgrupper. Mer information finns i använda automatiska redundansgrupper.
• En översikt över affärskontinuhet och scenarier finns i Översikt över affärskontinuhet.
• Mer information om hur Azure SQL Database säkerhetskopieringar finns i SQL Database automatiska säkerhetskopieringar.
• Mer information om hur du använder automatiska säkerhetskopieringar för återställning finns i Återställa en databas från tjänstinitierade säkerhetskopior.
• Mer information om autentiseringskrav för en ny primär server och databas finns i SQL Database säkerhet efter haveriberedskap.