Återställa din Azure SQL Database eller redundans till en sekundär

  • Artikel
  • 5 minuter för att läsa

GÄLLER FÖR: Azure SQL Database

Azure SQL Database erbjuder följande funktioner för återställning efter ett avbrott:

Mer information om scenarier för affärskontinuier och de funktioner som stöder dessa scenarier finns i Affärskontinui.

Anteckning

Om du använder zonredundant lagring Premium eller Affärskritisk databaser eller pooler automatiseras återställningsprocessen och resten av det här materialet gäller inte.

Både primära och sekundära databaser måste ha samma tjänstnivå. Vi rekommenderar också starkt att den sekundära databasen skapas med samma beräkningsstorlek (DPU:er eller virtuella kärnor) som den primära. Mer information finns i Uppgradera eller nedgradera som primär databas.

Använd en eller flera redundansgrupper för att hantera redundans för flera databaser. Om du lägger till en befintlig geo-replikeringsrelation till redundansgruppen kontrollerar du att den geo-sekundära är konfigurerad med samma tjänstnivå och beräkningsstorlek som den primära. Mer information finns i Använda automatiska redundansgrupper för att aktivera transparent och koordinerad redundans för flera databaser.

Förbereda för ett avbrott

För att lyckas med återställning till en annan dataregion med hjälp av redundansgrupper eller geo-redundanta säkerhetskopieringar måste du förbereda en server i ett annat datacenteravbrott för att bli den nya primära servern om behovet uppstår samt ha väldefinierade steg dokumenterade och testade för att säkerställa en smidig återställning. De här förberedelsestegen omfattar:

  • Identifiera servern i en annan region för att bli den nya primära servern. För geo-återställning är detta vanligtvis en server i den parkopplade regionen för den region där databasen finns. Detta eliminerar den extra trafikkostnaden under geo-återställningsåtgärder.
  • Identifiera och eventuellt definiera de IP-brandväggsregler på servernivå som krävs för att användare ska få åtkomst till den nya primära databasen.
  • Bestäm hur du ska omdirigera användare till den nya primära servern, till exempel genom att ändra anslutningssträngar eller genom att ändra DNS-poster.
  • Identifiera och eventuellt skapa de inloggningar som måste finnas i huvuddatabasen på den nya primära servern och se till att dessa inloggningar har rätt behörigheter i huvuddatabasen, om sådana finns. Mer information finns i SQL Database säkerhet efter haveriberedskap
  • Identifiera aviseringsregler som måste uppdateras för att mappas till den nya primära databasen.
  • Dokumentera granskningskonfigurationen för den aktuella primära databasen
  • Utför ett haveriberedskapsgranskning. Om du vill simulera ett avbrott för geo-återställning kan du ta bort eller byta namn på källdatabasen för att orsaka anslutningsfel för programmet. Om du vill simulera ett avbrott med hjälp av redundansgrupper kan du inaktivera webbappen eller den virtuella datorn som är ansluten till databasen eller redundans för att orsaka anslutningsfel för programmet.

När återställningen ska initieras

Återställningsåtgärden påverkar programmet. Det kräver att du SQL en anslutningssträng eller omdirigering med DNS och kan leda till permanent dataförlust. Därför bör det bara göras när avbrottet sannolikt kommer att vara längre än programmets mål för återställningstid. När programmet distribueras till produktion bör du utföra regelbunden övervakning av programmets hälsotillstånd och använda följande datapunkter för att kontrollera att återställningen är korrekt:

  1. Permanent anslutningsfel från programnivån till databasen.
  2. I Azure Portal visas en avisering om en incident i regionen med bred påverkan.

Anteckning

Om du använder redundansgrupper och väljer automatisk redundans är återställningsprocessen automatiserad och transparent för programmet.

Beroende på programtoleransen för driftstopp och möjliga verksamhetsansvar kan du överväga följande återställningsalternativ.

Använd Hämta återställningsbar databas (LastAvailableBackupDate) för att hämta den senaste geo-replikerade återställningspunkten.

Vänta på tjänståterställning

Azure-teamen arbetar noggrant med att återställa tjänstens tillgänglighet så snabbt som möjligt, men beroende på rotorsaken kan det ta flera timmar eller dagar. Om programmet kan tolerera betydande stilleståndstid kan du vänta tills återställningen är klar. I det här fallet krävs ingen åtgärd från din sida. Du kan se aktuell tjänststatus på vår Azure Service Health Instrumentpanel. När regionen har återställts återställs programmets tillgänglighet.

Redundans till geo-replikerad sekundär server i redundansgruppen

Om programmets driftstopp kan leda till verksamhetsansvar bör du använda redundansgrupper. Det gör att programmet snabbt kan återställa tillgängligheten i en annan region vid ett avbrott. En självstudiekurs finns i Implementera en geo-distribuerad databas.

För att återställa tillgängligheten för databaserna måste du initiera redundansen till den sekundära servern med någon av de metoder som stöds.

Använd någon av följande guider för redundans till en geo-replikerad sekundär databas:

Återställa med geo-återställning

Om programmets driftstopp inte leder till verksamhetsansvar kan du använda geo-återställning som metod för att återställa dina programdatabaser. Den skapar en kopia av databasen från den senaste geo-redundanta säkerhetskopieringen.

Konfigurera databasen efter återställning

Om du använder geo-återställning för att återställa efter ett avbrott måste du se till att anslutningen till de nya databaserna är korrekt konfigurerad så att den normala programfunktionen kan återupptas. Det här är en checklista med uppgifter som gör din återställda databasproduktion redo.

Uppdatera anslutningssträngar

Eftersom den återställda databasen finns på en annan server måste du uppdatera programmets anslutningssträng så att den pekar på den servern.

Mer information om hur du ändrar anslutningssträngar finns i lämpligt utvecklingsspråk för anslutningsbiblioteket.

Konfigurera brandväggsregler

Du måste se till att brandväggsreglerna som konfigurerats på servern och på databasen matchar de som har konfigurerats på den primära servern och den primära databasen. Mer information finns i How to: Configure Firewall Inställningar (Azure SQL Database).

Konfigurera inloggningar och databasanvändare

Du måste se till att alla inloggningar som används av ditt program finns på den server som är värd för den återställda databasen. Mer information finns i Säkerhetskonfiguration för geo-replikering.

Anteckning

Du bör konfigurera och testa serverns brandväggsregler och inloggningar (och deras behörigheter) under ett programåterställningstest. Dessa objekt på servernivå och deras konfiguration kanske inte är tillgängliga under avbrottet.

Konfigurera telemetriaviseringar

Du måste se till att dina befintliga aviseringsregelinställningar har uppdaterats för att mappas till den återställda databasen och den andra servern.

Mer information om databasaviseringsregler finns i Ta emot aviseringsmeddelanden och Spåra Service Health.

Aktivera granskning

Om granskning krävs för att få åtkomst till databasen måste du aktivera Granskning efter databasåterställningen. Mer information finns i Databasgranskning.

Nästa steg