Vägledning för haveriberedskap – Azure SQL Database

  • Artikel

Gäller för:Azure SQL Database

Azure SQL Database ger en branschledande garanti för hög tillgänglighet på minst 99,99 % för att stödja en mängd olika program, inklusive verksamhetskritiska, som alltid måste vara tillgängliga. Azure SQL Database har också viktiga funktioner för affärskontinuitet som du utför snabb haveriberedskap i händelse av ett regionalt avbrott. Den här artikeln innehåller värdefull information att granska före programdistributionen.

Även om vi ständigt strävar efter att tillhandahålla hög tillgänglighet finns det tillfällen då Azure SQL Database-tjänsten drabbas av avbrott som orsakar att databasen inte är tillgänglig och därmed påverkar ditt program. När vår tjänstövervakning identifierar problem som orsakar omfattande anslutningsfel, fel eller prestandaproblem deklarerar tjänsten automatiskt ett avbrott för att hålla dig informerad.

Tjänstavbrott

I händelse av ett avbrott i Azure SQL Database-tjänsten kan du hitta ytterligare information om avbrott på följande platser:

  • Banderoll för Azure-portalen

    Om din prenumeration identifieras som påverkad visas ett avbrottsavisering om ett tjänstproblem i azure-portalens meddelanden:

    A screenshot from the Azure portal of a notification of an Azure SQL Database service issue.

  • Hjälp + support eller support + felsökning

    När du skapar ett supportärende från Hjälp + support eller Support + felsökning finns det information om eventuella problem som påverkar dina resurser. Välj Visa avbrottsinformation för mer information och en sammanfattning av påverkan. Det finns också en avisering på sidan Ny supportbegäran .

    A screenshot of the Help+Support page showing a notification of an active service health issue..

  • Tjänststatus

    Sidan Service Health i Azure-portalen innehåller information om Status för Azure-datacenter globalt. Sök efter "tjänsthälsa" i sökfältet i Azure-portalen och visa sedan tjänstproblem i kategorin Aktiva händelser . Du kan också visa hälsotillståndet för enskilda resurser på sidan Resurshälsa för alla resurser under hjälpmenyn . Följande är exempel på en skärmbild av sidan Service Health med information om ett aktivt tjänstproblem i Sydostasien:

    A screenshot of the Azure portal Service Health page during a service issue in Southeast Asia, showing the Issue and a map of affected resources.

  • E-postavisering

    Om du har konfigurerat aviseringar skickas ett e-postmeddelande från azure-noreply@microsoft.com när ett tjänstavbrott påverkar din prenumeration och resurs. Brödtexten i e-postmeddelandet börjar vanligtvis med "Aktivitetsloggaviseringen ... utlöstes av ett tjänstproblem för Azure-prenumerationen...". Mer information om aviseringar om tjänsthälsa finns i Ta emot aktivitetsloggaviseringar på Azure-tjänstaviseringar med hjälp av Azure-portalen.

När haveriberedskap ska initieras under ett avbrott

I händelse av ett tjänststopp som påverkar programresurser bör du överväga följande åtgärder:

  • Azure-teamen arbetar flitigt för att återställa tjänstens tillgänglighet så snabbt som möjligt, men beroende på rotorsaken kan det ibland ta timmar. Om programmet kan tolerera betydande stilleståndstid kan du helt enkelt vänta tills återställningen har slutförts. I det här fallet krävs ingen åtgärd från din sida. Visa hälsotillståndet för enskilda resurser på sidan Resurshälsa för alla resurser under hjälpmenyn . Se sidan Resurshälsa för uppdateringar och den senaste informationen om ett avbrott. Efter återställningen av regionen återställs programmets tillgänglighet.

  • Återställning till en annan Azure-region kan kräva att program anslutningssträng ändras eller att DNS-omdirigering används, vilket kan leda till permanent dataförlust. Därför bör haveriberedskap endast utföras när avbrottstiden närmar sig programmets mål för återställningstid (RTO). När programmet distribueras till produktion bör du utföra regelbunden övervakning av programmets hälsa och kontrollera att återställningen endast är berättigad när det uppstår ett långvarigt anslutningsfel från programnivån till databasen. Beroende på din programtolerans mot stilleståndstid och eventuellt affärsansvar kan du bestämma om du vill vänta tills tjänsten har återställts eller initierat haveriberedskap själv.

Vägledning för återställning vid avbrott

Om azure SQL Database-avbrott i en region inte har åtgärdats under en längre tid och påverkar programmets serviceavtal (SLA) bör du överväga följande steg:

Redundansväxling (ingen dataförlust) till geo-replikerad sekundär server

Om aktiva geo-replikerings - eller redundansgrupper är aktiverade kontrollerar du om resursstatusen för den primära och sekundära databasen är Online i Azure-portalen. I så fall är dataplanet för både den primära och sekundära databasen felfritt. Initiera en redundansväxling av aktiva geo-replikerings- eller redundansgrupper till den sekundära regionen med hjälp av Azure-portalen, T-SQL, PowerShell eller Azure CLI.

Kommentar

En redundansväxling kräver fullständig datasynkronisering innan roller byts ut och resulterar inte i dataförlust. Beroende på typen av tjänstfel finns det ingen garanti för att redundansväxlingen utan dataförlust lyckas, men det är värt att prova som det första återställningsalternativet.

Om du vill initiera en redundansväxling använder du följande länkar:

Teknik Metod Steg
Aktiv geo-replikering PowerShell Redundansväxling till geo-replikering sekundär via PowerShell
T-SQL Redundansväxling till geo-replikering sekundär via T-SQL
Redundansgrupper Azure CLI Redundansväxling till sekundär server via Azure CLI
Azure Portal Redundansväxling till sekundär server via Azure-portalen
PowerShell Redundansväxling till sekundär server via PowerShell

Tvingad redundansväxling (potentiell dataförlust) till geo-replikerad sekundär server

Om redundansväxlingen inte slutförs korrekt och får fel, eller om den primära databasstatusen inteär Online, bör du noga överväga tvingad redundansväxling med potentiell dataförlust i den sekundära regionen.

Om du vill initiera en tvingad redundansväxling använder du följande länkar:

Teknik Metod Steg
Aktiv geo-replikering Azure CLI Tvingad redundans till geo-replikering sekundär via Azure CLI
Azure Portal Tvingad redundans till geo-replikering sekundär via Azure-portalen
PowerShell Tvingad redundans till geo-replikering sekundär via PowerShell
T-SQL Tvingad redundans till geo-replikering sekundär via T-SQL
redundansgrupper Azure Portal Tvingad redundans till sekundär server via Azure-portalen men välj Tvingad redundansväxling.
Azure CLI Tvingad redundans till sekundär server via Azure CLI men använder --allow-data-loss
PowerShell Tvingad redundans till sekundär server via PowerShell men använder -AllowDataLoss

Geo-återställning

Om du inte har aktiverat aktiva geo-replikerings- eller redundansgrupper kan du som sista utväg använda geo-återställning för att återställa från ett avbrott. Geo-återställning använder geo-replikerade säkerhetskopior som källa. Du kan återställa en databas på valfri logisk server i valfri Azure-region från de senaste geo-replikerade säkerhetskopiorna. Du kan begära en geo-återställning även om ett avbrott har gjort databasen eller hela regionen otillgänglig.

Mer information om geo-återställningar via Azure CLI, Azure-portalen, PowerShell eller REST-API :et finns i geo-återställning av Azure SQL Database.

Konfigurera databasen efter återställning

Om du använder geo-redundans eller geo-återställning för att återställa från ett avbrott måste du se till att anslutningen till den nya databasen är korrekt konfigurerad så att den normala programfunktionen kan återupptas. Det här är en checklista med uppgifter för att förbereda den återställda databasproduktionen.

Viktigt!

Vi rekommenderar att du utför regelbundna detaljgranskningar av din strategi för haveriberedskap för att verifiera programtoleransen samt alla operativa aspekter av återställningsproceduren. De andra lagren i programinfrastrukturen kan kräva omkonfiguration. Mer information om elastiska arkitektursteg finns i checklistan för hög tillgänglighet och haveriberedskap i Azure SQL Database.

Uppdatera anslutningssträng

  • Om du använder aktiv geo-replikering eller geo-återställning måste du se till att anslutningen till de nya databaserna är korrekt konfigurerad så att den normala programfunktionen kan återupptas. 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äng finns i lämpligt utvecklingsspråk för anslutningsbiblioteket.
  • Om du använder redundansgrupper för att återställa från ett avbrott och använda skrivskyddade och skrivskyddade lyssnare i programmet anslutningssträng behövs ingen ytterligare åtgärd eftersom anslutningar automatiskt dirigeras till ny primär.

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

Skapa de inloggningar som måste finnas i master databasen på den nya primära servern och se till att dessa inloggningar har lämpliga behörigheter i master databasen, om sådana finns. Mer information finns i Azure SQL Database-säkerhet efter haveriberedskap.

Konfigurera telemetriaviseringar

Du måste se till att dina befintliga aviseringsregelinställningar uppdateras för att mappa till den nya primära databasen och den olika servern. Mer information om regler för databasaviseringar finns i Ta emot aviseringsaviseringar och Spåra tjänstens hälsa.

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 Azure SQL-granskning för Azure SQL Database.

Nästa steg