Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
gäller för:
Azure SQL DatabaseSQL-databas i Fabric
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.
För förebyggande 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
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 konfigurationsändringar, programvarufel eller maskinvarufel.
Hög 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%.
Aktivera zonredundans för att uppnå hög tillgänglighet i Azure-molnmiljön. Med zonredundans använder databasen eller den elastiska poolen Azure-tillgänglighetszoner för att säkerställa motståndskraft 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 aktiv geo-replikering och failover-grupper, två alternativ för haveriberedskap i 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 failover | 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 |
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. Två vanliga sätt att kvantifiera affärskrav kring haveriberedskap är:
- Mål för återställningstid (RTO): Den tid som krävs för att ett program ska återställas helt efter en oplanerad störande händelse.
- Mål för återställningspunkt (RPO): Den tidsperiod för dataförlust som kan tolereras från en oplanerad störande händelse.
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 (använder geoåterställning) |
Vanligtvis minuter eller timmar, beroende på Azure Storage-replikering | Vanligtvis minuter eller timmar, beroende på storleken på databassäkerhetskopian |
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 Azure 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ällsynta avbrott i datacenter eller tillgänglighetszoner, som kan orsakas av en naturkatastrofhändelse, konfigurationsändring, programvarufel eller maskinvarufel. | 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. Genom att aktivera zonredundans säkerställs att databasen eller den elastiska poolen är motståndskraftig mot zonfel med upp till 99,995% SLA för hög tillgänglighet. |
| Sällsynt regionalt avbrott som påverkar alla tillgänglighetszoner och datacentren som omfattar dem, eventuellt orsakad av en katastrofal naturhändelse. | 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. |
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 sekundären för ett regionalt avbrott.
Å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 tidpunktsåterställning (PITR) kan du skapa en ny databas på samma server som representerar datatillståndet före händelsen som orsakade korruption. 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 viss tidpunkt inte räcker för ditt program kan du utöka den genom att konfigurera en policy för långsiktig kvarhållning (LTR). Mer information finns i Långsiktig kvarhållning.
Uppgradera ett program med minimal stilleståndstid
Ibland måste ett program tas offline på grund av underhåll, till exempel en programuppgradering. Du kan hantera löpande uppgraderingar av molnprogram med hjälp av aktiv geo-replikering i SQL Database. Geo-replikering kan också ge en återställningssökväg om något går fel.
Spara på kostnader med en standby-kopia
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.