Översikt över affärskontinuitet med Azure SQL Database
gäller för:
Azure SQL DatabaseSQL-databas i Fabric
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.
Överblick
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 framgångsrikt bort data eller raderar 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 en Platform-as-a-Service (PaaS) erbjuder Azure SQL Database-tjänsten tillgänglighet som en standardfunktion med ett branschledande tillgänglighetsavtal 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%.
Katastrofåterställning
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:
- Aktiv geo-replikering låter dig skapa en ständigt synkroniserad, sekundär databas som kan läsas för en primär databas i valfri region.
- Failover-grupper, förutom att tillhandahålla kontinuerlig synkronisering mellan en primär och sekundär databas, får du dessutom möjligheten att hantera replikering och failover för vissa, eller alla, databaser på en logisk server till en sekundär logisk server i en annan region. Failover-grupper tillhandahåller skriv- och läsbara samt skrivskyddade lyssnarslutpunkter som förblir densamma, så det krävs inte att applikationsanslutningssträngarna uppdateras efter en failover.
- Geo-återställning möjliggör återställning från ett regionalt avbrott genom att använda geo-replikerade säkerhetskopior när du inte kan komma åt din databas i den primära regionen, genom att skapa en ny databas på en befintlig server i valfri 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 | Failover-grupper | |
|---|---|---|
| Kontinuerlig datasynkronisering mellan primär och sekundär | Ja | Ja |
| Växla över flera databaser samtidigt | Nej | Ja |
| Anslutningssträngen förblir oförändrad efter redundansväxling | Nej | Ja |
| Stödjer skalning för läsning | Ja | Ja |
| flera repliker | Ja | Nej |
| Kan finnas i samma region som primär | 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 undvika 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 en viss tidpunkt (PITR) på upp till 35 dagar. Du kan återställa en borttagen databas till den punkt då 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 över flera fysiska zoner i en Azure-region. Om zonredundans aktiveras ser du till att databasen eller den elastiska poolen är motståndskraftiga mot zonfel med upp till 99,995% serviceavtal med hög tillgänglighet. |
| Sällsynta regionala avbrott som påverkar alla tillgänglighetszoner och datacenter som ingår i den, som möjligen orsakats av katastrofala naturhändelser. | För att minska 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 säkerhetskopieringslagring till geo-redundant säkerhetskopieringslagring för att använda geo-återställning. |
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 (med zonredundans) |
Vanligtvis mindre än 30 sekunder | 0 |
| Haveriberedskap (Använda redundansgrupper med kundhanterad redundansprincip 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) |
| Katastrofåterställning (med geoåterställning) |
Vanligtvis minuter eller timmar, beroende på Azure Storage-replikering | Vanligtvis minuter eller timmar, beroende på storleken på databassäkerhetskopian |
Checklistor för affärskontinuitet
För normativa rekommendationer för att maximera tillgängligheten och uppnå högre affärskontinuitet, se:
- checklista för tillgänglighet
- checklista för hög tillgänglighet
- checklista för katastrofåterställning
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 ordentligt kan det ta längre tid att återställa dina applikationer efter en redundansväxling eller återställning, vilket förmodligen även kräver felsökning och kan fördröja RTO. Följ checklistan för att förbereda beredskap 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 korrumperande händelsen. Information om återställningstider finns i RTO och RPO.
Om den maximala kvarhållningsperioden för säkerhetskopiering som stöds för återställning till en specifik tidpunkt inte är tillräcklig för ditt program, kan du förlänga den genom att konfigurera en policy för långsiktig lagring (LTR) för databaserna. Mer information finns i Långsiktig kvarhållning av säkerhetskopior.
Uppgradera ett program med minimal stilleståndstid
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 in kostnader med en standbyreplika
Om din sekundära replik används endast för katastrofåterställning (DR) och inte har några läs- eller skrivbelastningar, kan du spara på licenskostnaderna genom att ange databasen till väntläget när du konfigurerar en ny aktiv geo-replikeringsrelation.
Granska licensfri standby-replika för att lära dig mer.
Nästa steg
Mer information om applikationsdesign finns i Utforma en applikation för haveriberedskap i molnet och haveriberedskapsstrategier för elastiska pooler.
Läs riktlinjer för haveriberedskap i Azure SQL Database och checklista för hög tillgänglighet och haveriberedskap i Azure SQL Database.