Översikt över affärskontinuitet med Azure SQL Database
Gäller för:
Azure SQL Database
Den här artikeln innehåller en översikt över funktionerna för affärskontinuitet och haveriberedskap i Azure SQL Database och beskriver alternativen och rekommendationerna för att återställa från störande händelser som kan leda till dataförlust eller leda till att databasen och programmet blir otillgängliga. Lär dig vad du ska göra när ett användar- eller programfel påverkar dataintegriteten, en Azure-tillgänglighetszon eller en region har ett avbrott eller om ditt program kräver underhåll.
Översikt
Affärskontinuitet i Azure SQL Database refererar till de mekanismer, principer och procedurer som gör att ditt företag kan fortsätta att arbeta med avbrott genom att tillhandahålla tillgänglighet, hög tillgänglighet och haveriberedskap.
I de flesta fall hanterar SQL Database störande händelser som kan inträffa i en molnmiljö och håller dina program och affärsprocesser igång. Det finns dock några störande händelser där åtgärder kan ta lite tid, till exempel:
- Användaren tar av misstag bort eller uppdaterar en rad i en tabell.
- Den skadliga angriparen tar bort data eller tar bort en databas.
- Katastrofala naturkatastrofer drabbar ett datacenter, en tillgänglighetszon eller en region.
- Sällsynta datacenter, tillgänglighetszoner eller regionomfattande avbrott som orsakas av en konfigurationsändring, programvarufel eller maskinvarukomponentfel.
Tillgänglighet
Azure SQL Database levereras med ett grundläggande löfte om återhämtning och tillförlitlighet som skyddar den mot programvaru- eller maskinvarufel. Databassäkerhetskopior automatiseras för att skydda dina data från skador eller oavsiktlig borttagning. Som paaS (Platform-as-a-service) ger Azure SQL Database-tjänsten tillgänglighet som en off-the-shelf-funktion med ett branschledande serviceavtal för tillgänglighet på 99,99 %.
Hög tillgänglighet
För att uppnå hög tillgänglighet i Azure-molnmiljön aktiverar du zonredundans så att databasen, eller den elastiska poolen, använder tillgänglighetszoner för att säkerställa att databasen eller den elastiska poolen är motståndskraftig mot zonfel. Många Azure-regioner tillhandahåller tillgänglighetszoner, som är avgränsade grupper av datacenter i en region som har oberoende infrastruktur för ström, kylning och nätverk. Tillgänglighetszoner är utformade för att tillhandahålla regionala tjänster, kapacitet och hög tillgänglighet i de återstående zonerna om en zon drabbas av ett avbrott. Genom att aktivera zonredundans är databasen eller den elastiska poolen motståndskraftig mot zonindelat maskin- och programvarufel och återställningen är transparent för program. När hög tillgänglighet är aktiverat kan Azure SQL Database-tjänsten tillhandahålla ett serviceavtal med högre tillgänglighet på 99,995 %.
Haveriberedskap
För att uppnå högre tillgänglighet och redundans mellan regioner kan du aktivera funktioner för haveriberedskap för att snabbt återställa databasen från ett oåterkalleligt regionalt fel. Alternativ för haveriberedskap med Azure SQL Database är:
- Med aktiv geo-replikering kan du skapa en kontinuerligt synkroniserad läsbar sekundär databas i valfri region för en primär databas.
- Redundansgrupper, förutom att tillhandahålla kontinuerlig synkronisering mellan en primär och sekundär databas, gör det också möjligt att hantera replikering och redundans för vissa, eller alla, databaser på en logisk server till en sekundär logisk server i en annan region. Redundansgrupper tillhandahåller skrivskyddade och skrivskyddade lyssnarslutpunkter som förblir oförändrade, så det är inte nödvändigt att uppdatera program anslutningssträng efter redundansväxling.
- Med geo-återställning kan du återställa från ett regionalt avbrott genom att återställa från geo-replikerade säkerhetskopior när du inte kan komma åt databasen i den primära regionen genom att skapa en ny databas på en befintlig server i någon Azure-region.
I följande tabell jämförs aktiva geo-replikerings- och redundansgrupper, två alternativ för haveriberedskap för Azure SQL Database:
| Aktiv geo-replikering | Redundansgrupper | |
|---|---|---|
| Kontinuerlig datasynkronisering mellan primär och sekundär | Ja | Ja |
| Växla över flera databaser samtidigt | Nej | Ja |
| Anslut ionssträngen förblir oförändrad efter redundansväxling | Nej | Ja |
| Stöder lässkalning | Ja | Ja |
| Flera repliker | Ja | Nej |
| Kan finnas i samma region som den primära | Ja | Nej |
Funktioner som ger affärskontinuitet
Ur ett databasperspektiv finns det fyra stora potentiella avbrottsscenarier. I följande tabell visas funktioner för affärskontinuitet i SQL Database som du kan använda för att minimera ett potentiellt scenario med affärsstörningar:
| Scenario för avbrott i verksamheten | Funktion för affärskontinuitet |
|---|---|
| Lokala maskinvaru- eller programvarufel som påverkar databasnoden. | För att minska lokala maskinvaru- och programvarufel innehåller SQL Database en tillgänglighetsarkitektur som garanterar automatisk återställning från dessa fel med upp till 99,99 % tillgänglighets-SLA. |
| Skadade eller borttagna data orsakas vanligtvis av ett programfel eller ett mänskligt fel. Sådana fel är programspecifika och kan vanligtvis inte identifieras av databastjänsten. | För att skydda ditt företag mot dataförlust skapar SQL Database automatiskt fullständiga databassäkerhetskopior varje vecka, differentiella databassäkerhetskopieringar var 12:e eller 24:e timme och säkerhetskopior av transaktionsloggar var 5–10:e minut. Som standard lagras säkerhetskopior i geo-redundant lagring i sju dagar för alla tjänstnivåer. Alla tjänstnivåer utom Basic stöder en konfigurerbar kvarhållningsperiod för säkerhetskopiering för återställning till tidpunkt (PITR) på upp till 35 dagar. Du kan återställa en borttagen databas till den punkt där den togs bort om servern inte har tagits bort eller om du har konfigurerat långsiktig kvarhållning (LTR). |
| Sällsynt avbrott i datacenter eller tillgänglighetszoner, möjligen orsakat av en naturkatastrofhändelse, konfigurationsändring, programvarufel eller maskinvarukomponentfel. | För att minska avbrott på datacenter- eller tillgänglighetsnivå aktiverar du zonredundans för databasen eller den elastiska poolen för att använda Azure Tillgänglighetszoner och tillhandahålla redundans i flera fysiska zoner i en Azure-region. Om du aktiverar zonredundans säkerställer du att databasen eller den elastiska poolen är motståndskraftiga mot zonfel med upp till 99,995 % serviceavtal med hög tillgänglighet. |
| Sällsynt regionalt avbrott som påverkar alla tillgänglighetszoner och datacenter som består av den, eventuellt orsakad av katastrofala naturkatastrofer. | För att minimera ett regionomfattande avbrott aktiverar du haveriberedskap med något av alternativen: – Alternativ för kontinuerlig datasynkronisering som redundansgrupper (rekommenderas) eller aktiv geo-replikering som gör att du kan skapa repliker i en sekundär region för redundans. – Ställa in redundans för lagring av säkerhetskopiering till geo-redundant lagring för säkerhetskopiering så att geo-återställning används. |
Mål för återställningstid och återställningspunkter (RTO och RPO)
När du utvecklar din affärskontinuitetsplan ska du förstå den maximala godkända tiden innan programmet återställs helt efter den störande händelsen. Den tid som krävs för att ett program ska återställas helt kallas för mål för återställningstid (RTO). Förstå också den maximala perioden för de senaste datauppdateringarna (tidsintervall) som programmet kan tolerera att förlora när det återställs från en oplanerad störande händelse. Den potentiella dataförlusten kallas mål för återställningspunkt (RPO).
I följande tabell jämförs RPO och RTO för varje alternativ för affärskontinuitet:
| Alternativ för affärskontinuitet | RTO (stilleståndstid) | RPO (dataförlust) |
|---|---|---|
| Hög tillgänglighet (aktivera zonredundans) |
Vanligtvis mindre än 30 sekunder | 0 |
| Haveriberedskap (aktivera redundansgrupper eller aktiv geo-replikering) |
Vanligtvis mindre än 60 sekunder | Lika med eller större än 0 (beror på dataändringar före den störande händelsen som inte har replikerats) |
| Haveriberedskap (med geo-återställning) |
Vanligtvis minuter eller timmar | Vanligtvis minuter eller timmar |
Checklistor för affärskontinuitet
För normativa rekommendationer för att maximera tillgängligheten och uppnå högre affärskontinuitet, se:
Förbereda för ett regionstopp
Oavsett vilka funktioner för affärskontinuitet du använder måste du förbereda den sekundära databasen i en annan region. Om du inte förbereder dig korrekt tar det längre tid att ansluta dina program efter en redundansväxling eller återställning och kräver förmodligen även felsökning, vilket kan fördröja RTO. Följ checklistan för att förbereda sekundärt för ett regionstopp.
Återställa en databas inom samma Azure-region
Du kan använda automatiska databassäkerhetskopior för att återställa en databas till en tidpunkt tidigare. På så sätt kan du återställa från skadade data som orsakas av mänskliga fel. Med återställning till tidpunkt (PITR) kan du skapa en ny databas på samma server som representerar datatillståndet före den skadade händelsen. För de flesta databaser tar återställningsåtgärder mindre än 12 timmar. Det kan ta längre tid att återställa en mycket stor eller mycket aktiv databas. Mer information finns i databasens återställningstid.
Om den maximala kvarhållningsperioden för säkerhetskopiering som stöds för återställning till tidpunkt inte räcker för ditt program kan du utöka den genom att konfigurera en princip för långsiktig kvarhållning (LTR) för databaserna. Mer information finns i Långsiktig kvarhållning av säkerhetskopior.
Uppgradera ett program med minimal avbrottstid
Ibland måste ett program tas offline på grund av underhåll, till exempel en programuppgradering. Hantera programuppgraderingar beskriver hur du använder aktiv geo-replikering för att aktivera löpande uppgraderingar av ditt molnprogram för att minimera stilleståndstiden under uppgraderingar och tillhandahålla en återställningssökväg om något går fel.
Spara på kostnader med en 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 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 .
Nästa steg
Mer information om programdesign finns i Utforma ett program för haveriberedskap i molnet och strategier för återställning av elastiska pooler.
Granska vägledningen för haveriberedskap i Azure SQL Database och checklista för hög tillgänglighet och haveriberedskap i Azure SQL Database.