Dela via

Tillförlitlighet i Azure SQL Database

Den här artikeln beskriver tillförlitlighetsstöd i Azure SQL Database, som omfattar intraregional återhämtning via tillgänglighetszoner och distributioner i flera regioner.

När du använder Azure är tillförlitlighet ett delat ansvar. Microsoft tillhandahåller en rad funktioner för att stödja återhämtning och återställning. Du ansvarar för att förstå hur dessa funktioner fungerar inom alla tjänster som du använder och välja de funktioner du behöver för att uppfylla dina affärsmål och drifttidsmål.

Rekommendationer för produktionsdistribution

Mer information om hur du distribuerar Azure SQL Database för att stödja lösningens tillförlitlighetskrav och hur tillförlitlighet påverkar andra aspekter av din arkitektur finns i Metodtips för arkitektur för Azure SQL Database i Azure Well-Architected Framework.

Översikt över tillförlitlighetsarkitektur

SQL Database körs på den senaste stabila SQL Server Database-motorn i Windows-operativsystemet, inklusive alla tillämpliga korrigeringar.

SQL Database uppnår redundans genom att lagra tre kopior av dina data i ett enda datacenter i den primära regionen som standard. Den här metoden skyddar dina data om ett lokaliserat fel inträffar, till exempel ett småskaligt nätverksfel eller strömavbrott, och även under följande händelser:

  • Kundinitierade hanteringsåtgärder som resulterar i en kort stilleståndstid

  • Serviceunderhållsåtgärder

  • Problem och avbrott i datacenter, där datacentret har följande komponenter:

    • Rack, där datorerna som driver din tjänst körs

    • Fysiska datorer som är värdar för den virtuella datorn (VM) som kör SQL Database-motorn

  • Andra problem med SQL Database-motorn

  • Andra potentiella oplanerade lokaliserade avbrott

SQL Database använder Azure Service Fabric för att hantera replikeringen av databasen.

Redundans implementeras på olika sätt för olika tjänstnivåer i SQL Database. Mer information finns i Tillgänglighet via redundans – SQL Database.

Tillfälliga fel

Tillfälliga fel är kortvariga, intermittenta fel i komponenter. De förekommer ofta i en distribuerad miljö som molnet, och de är en normal del av åtgärderna. Tillfälliga fel korrigerar sig själva efter en kort tidsperiod. Det är viktigt att dina program kan hantera tillfälliga fel, vanligtvis genom att försöka igen.

Alla molnbaserade program bör följa vägledningen för tillfälliga felhantering i Azure när de kommunicerar med molnbaserade API:er, databaser och andra komponenter. Mer information finns i Rekommendationer för hantering av tillfälliga fel.

SQL Database hanterar automatiskt kritiska serviceuppgifter, till exempel korrigeringar, säkerhetskopieringar, Windows- och SQL Database-motoruppgraderingar. Den hanterar också automatiskt oplanerade händelser, till exempel underliggande maskinvaru-, programvaru- eller nätverksfel. SQL Database är utformat för att snabbt återställas från kritiska fel, vilket säkerställer att dina data alltid är tillgängliga. De flesta användare märker inte att uppgraderingar utförs kontinuerligt.

När en databas korrigeras eller redundansväxlar är stilleståndstiden inte störande om du använder logik för återförsök i ditt program.

Du kan testa programmets återhämtning till tillfälliga fel genom att följa vägledningen i Testa programfelåterhämtning.

Stöd för tillgänglig zon

Tillgänglighetszoner är fysiskt separata grupper av datacenter i varje Azure-region. När en zon misslyckas kan tjänsterna redundansväxla till en av de återstående zonerna.

Du kan skapa en zonredundant enkel databas eller elastisk pool. Zonredundans säkerställer att databasen är motståndskraftig mot en stor uppsättning fel, inklusive oåterkalleliga datacenterfel, utan några ändringar i programlogik.

För tjänstnivån Generell användning säkerställer zonredundans att både tillståndslösa beräkningskomponenter och tillståndskänsliga datalagringskomponenter i SQL Database är motståndskraftiga mot ett avbrott i tillgänglighetszonen.

För tjänstnivåerna Premium, Affärskritisk och Hyperskala placerar zonredundans repliker av DIN SQL-databas över flera Azure-tillgänglighetszoner i din primära region. För att eliminera en enskild felpunkt (SPOF) dupliceras även kontrollringen över flera tillgänglighetszoner.

Om du vill visa information om stöd för tillgänglighetszoner för andra tjänstnivåer måste du välja lämplig tjänstnivå i början av den här sidan.

Kravspecifikation

Tjänstnivåerna Basic och Standard stöder inte zonredundans.

Zonredundans är tillgängligt för databaser på tjänstnivåerna Affärskritisk, Generell användning och Hyperskala för den vCore-baserade inköpsmodellen, och endast Premium-tjänstnivån för den DTU-baserade inköpsmodellen.

För tjänstnivån Generell användning:

  • Zonredundant konfiguration är endast tillgänglig när standardseriemaskinvara (Gen5) har valts.

  • När du använder en zonredundant SQL-databas stöder endast specifika regioner anpassade underhållsfönster. Mer information finns i STÖD för SQL Database-regioner för underhållsperioder.

För tjänstnivåerna Premium och Affärskritisk:

För tjänstnivån Hyperskala:

Regioner som stöds

För tjänstnivåerna Premium, Generell användning och Affärskritisk är zonredundans tillgänglig i alla Azure-regioner som stöder tillgänglighetszoner.

För tjänstnivån Hyperskala är zonredundans tillgänglig i alla Azure-regioner som stöder tillgänglighetszoner. Dock är zonredundansstöd för Hyperskala premium-serie och premium-serie minnesoptimerad maskinvara tillgängligt i utvalda Azure-regioner.

Om du vill visa information om stöd för tillgänglighetszoner för andra tjänstnivåer måste du välja lämplig tjänstnivå i början av den här sidan.

Överväganden

  • Latens: Zonredundanta databaser har repliker i separata datacenter. Den tillagda nätverksfördröjningen kan öka transaktionsincheckningstiden och potentiellt påverka prestandan för vissa OLTP-arbetsbelastningar (onlinetransaktionsbearbetning). De flesta program är inte känsliga för den här extra svarstiden.

  • master databas: När en databas med en zonredundant konfiguration skapas på en logisk server blir även databasen master som är associerad med servern automatiskt zonredundant. Mer information om hur du kontrollerar om databasen master är zonredundant finns i Databaszonredundant tillgänglighet.

Om du vill visa information om stöd för tillgänglighetszoner för andra tjänstnivåer måste du välja lämplig tjänstnivå i början av den här sidan.

Kostnad

För tjänstnivån Generell användning tillkommer en extra kostnad för att aktivera zonredundans för SQL Database. Mer information finns i Priser – SQL Database.

Tjänstnivåerna Premium och Affärskritisk innehåller flera repliker av databasen. När du aktiverar zonredundans distribueras replikerna mellan tillgänglighetszoner. Den här distributionen innebär att det inte finns någon extra kostnad i samband med aktivering av zonredundans på sql-databasen när den är på tjänstnivån Premium eller Affärskritisk.

Om du aktiverar flera repliker av hyperskalans tjänstnivådatabas kan du aktivera zonredundans. När du aktiverar zonredundans distribueras replikerna mellan tillgänglighetszoner. Den här distributionen innebär att det inte finns någon extra kostnad för aktivering av zonredundans på SQL-databasen när den är på tjänstnivån Hyperskala, förutsatt att du har flera repliker.

Om du vill visa information om stöd för tillgänglighetszoner för andra tjänstnivåer måste du välja lämplig tjänstnivå i början av den här sidan.

Konfigurera stöd för tillgänglighetszoner

För tjänstnivåerna Generell användning, Premium och Affärskritisk:

  • Nya resurser: Du kan konfigurera en databas så att den är zonredundant när du skapar den. Mer information finns i Snabbstart: Skapa en enkel databas – SQL Database.

  • Befintliga resurser: Du kan konfigurera om en befintlig databas så att den är zonredundant. Mer information finns i Aktivera zonredundans – SQL Database.

    Alla SQL Database-skalningsåtgärder, inklusive aktivering av zonredundans, är onlineåtgärder och kräver minimal till ingen stilleståndstid. Mer information finns i Skala databasresurser dynamiskt med minimal stilleståndstid.

  • Inaktivera zonredundans: Du kan inaktivera zonredundans. Den här processen är en onlineåtgärd som liknar en vanlig uppgradering av servicenivåmål. I slutet av processen migreras databasen från en zonredundant ring till en ring med en zon.

För tjänstnivån Hyperskala:

  • Nya resurser: För Hyperskala-databaser och elastiska pooler måste zonredundans konfigureras när databasen skapas. Mer information finns i Skapa en zonredundant Hyperskala-databas.

  • Migrera eller inaktivera zonredundans: Om du vill aktivera eller inaktivera zonredundans i en befintlig Hyperskala-databas eller elastisk pool måste du distribuera om den. Processen lägger till en sekundär replik för hög tillgänglighet och placerar den i en annan tillgänglighetszon.

    Mer information finns i Distribuera om en zonredundant Hyperskala-databas – SQL Database

Om du vill visa information om stöd för tillgänglighetszoner för andra tjänstnivåer måste du välja lämplig tjänstnivå i början av den här sidan.

Normala åtgärder

I det här avsnittet beskrivs vad du kan förvänta dig när databaser konfigureras för zonredundans och alla tillgänglighetszoner används.

För tjänstnivån Generell användning:

  • Trafikroutning mellan zoner: Begäranden dirigeras till en nod som kör sql-databasens beräkningslager. När zonredundans är aktiverat kan den här noden finnas i valfri tillgänglighetszon.

  • Datareplikering mellan zoner: Data och loggfiler replikeras synkront mellan tillgänglighetszoner med hjälp av ZRS. Skrivåtgärder anses inte vara slutförda förrän data har replikerats i alla tillgänglighetszoner. Den här synkrona replikeringen säkerställer stark konsistens och noll dataförlust vid zonfel. Det kan dock leda till något högre skrivfördröjning jämfört med lokalt redundant lagring (LRS).

För tjänstnivåerna Premium och Affärskritisk:

  • Trafikroutning mellan zoner: Repliker distribueras mellan tillgänglighetszoner och en av dessa repliker är avsedd som den primära repliken. Begäranden dirigeras till databasens primära replik.

  • Datareplikering mellan zoner: Den primära repliken skickar ständigt ändringar till de sekundära replikerna sekventiellt för att säkerställa att data sparas på ett tillräckligt antal sekundära repliker innan de genomför varje transaktion. Den här processen garanterar att om den primära repliken eller en läsbar sekundär replik av någon anledning blir otillgänglig är en fullständigt synkroniserad replik alltid tillgänglig för redundans. När zonredundans är aktiverat finns dessa repliker i olika tillgänglighetszoner. Processen kan dock leda till något högre skrivfördröjning på grund av nätverksfördröjningen i bläddringszoner.

För tjänstnivån Hyperskala:

  • Trafikroutning mellan zoner: Databasrepliker distribueras mellan tillgänglighetszoner och en av dessa repliker har angetts som den primära repliken. Begäranden dirigeras till databasens primära replik.

  • Datareplikering mellan zoner: Den primära databasrepliken skickar ändringar via en zonredundant loggtjänst som replikerar alla ändringar synkront mellan tillgänglighetszoner. Sidservrar finns i varje tillgänglighetszon och lagrar databasens tillstånd. Den här processen garanterar att om den primära repliken eller en läsbar sekundär replik av någon anledning blir otillgänglig är en fullständigt synkroniserad replik alltid tillgänglig för redundans. Processen kan dock resultera i något högre skrivfördröjning jämfört med LRS.

Om du vill visa information om stöd för tillgänglighetszoner för andra tjänstnivåer måste du välja lämplig tjänstnivå i början av den här sidan.

Avslappningsupplevelse

Det här avsnittet beskriver vad du kan förvänta dig när databaser konfigureras för zonredundans och det uppstår ett avbrott i tillgänglighetszonen.

  • Identifiering och svar: SQL Database ansvarar för att identifiera och svara på ett fel i en tillgänglighetszon. Du behöver inte göra något för att påbörja en zone-failover.

  • Aktiva begäranden: När en tillgänglighetszon kopplas från avslutas alla begäranden som bearbetas i den felaktiga tillgänglighetszonen och måste göras om. Mer information om hur du gör dina program motståndskraftiga mot dessa typer av problem finns i vägledningen för tillfällig felhantering.

  • Omdistribution av trafik: För tjänstnivån Generell användning flyttar SQL Database databasmotorn till en annan tillståndslös beräkningsnod som finns i en annan tillgänglighetszon och har tillräckligt med ledig kapacitet. När redundansväxlingen är klar omdirigeras nya anslutningar automatiskt till den nya primära beräkningsnoden.

    Mer information finns i Tjänstnivå för generell användning.

  • Omdistribution av trafik: För tjänstnivåerna Premium och Affärskritisk väljer SQL Database en replik i en annan tillgänglighetszon för att bli den primära repliken. När en sekundär replik blir den nya primära repliken skapas en annan sekundär replik för att säkerställa att klustret har tillräckligt många repliker för att upprätthålla ett kvorum. När redundansväxlingen är klar omdirigeras nya anslutningar automatiskt till den nya primära repliken (eller läsbar sekundär replik baserat på anslutningssträngen).

    Mer information finns i tjänstnivåerna Premium och Affärskritisk.

  • Omdistribution av trafik: För tjänstnivån Hyperskala, om den primära repliken gick förlorad på grund av zonavbrottet, befordrar SQL Database en av replikerna med hög tillgänglighet i en annan zon till den nya primära repliken.

    För mer information, se Hyperskala-tjänstnivå.

  • Förväntad stilleståndstid: Det kan finnas en liten mängd stilleståndstid under en redundansväxling i tillgänglighetszonen. Stilleståndstiden är vanligtvis mindre än 30 sekunder, vilket programmet bör tolerera om det följer vägledningen för övergående felhantering.

  • Förväntad dataförlust: Ingen dataförlust förväntas under en redundansväxling i tillgänglighetszonen.

Om du vill visa information om stöd för tillgänglighetszoner för andra tjänstnivåer måste du välja lämplig tjänstnivå i början av den här sidan.

Zonåterställning

När tillgänglighetszonen återställs skapar Azure Service Fabric automatiskt databasrepliker i den återställda tillgänglighetszonen, tar bort alla tillfälliga repliker som skapats i de andra tillgänglighetszonerna och återupptar normal trafikroutning till databasen. För att undvika avbrott återställer inte den primära repliken automatiskt den ursprungliga zonen efter zonåterställningen.

Testa för zonfel

SQL Database-plattformen hanterar trafikroutning, redundans och zonåterställningsprocedurer för zonredundanta databaser. Eftersom den här funktionen är helt hanterad behöver du inte initiera eller verifiera felprocesser i tillgänglighetszonen. Du kan dock verifiera applikationens hantering av fel och failover genom att följa processen som beskrivs i Testa programmotståndskraft mot fel.

Stöd för flera regioner

Det här avsnittet innehåller en översikt över två relaterade men separata funktioner som kan användas för geo-replikering i flera regioner av SQL Database:

  • Aktiv geo-replikering replikerar en enskild databas till en synkroniserad sekundär databas.

  • Redundansgrupper bygger på aktiv geo-replikering och gör att du kan redundansväxla en grupp databaser.

Aktiv geo-replikering skapar en kontinuerligt synkroniserad läsbar sekundär databas (som ibland kallas geo-sekundär eller geo-replik) i alla regioner för en enskild primär databas. Aktiv geo-replikering kan skapa sekundära databaser i samma region, men den här konfigurationen ger inte skydd mot ett regionfel. När du använder aktiv geo-replikering för att uppnå geo-redundans letar du upp den sekundära databasen i en annan region än den primära databasen.

Stöd för regioner

Aktiv geo-replikering kan aktiveras i alla Azure-regioner och kräver inte att du använder Azure-regionpar.

Tips/Råd

SQL Database följer en säker distributionspraxis där Azure strävar efter att inte distribuera uppdateringar till kopplade regioner samtidigt. Om du konfigurerar aktiv geo-replikering till att använda icke-kopplade regioner anger du olika underhållsperioder för servrarna i varje region. Den här metoden minskar risken för att båda regionerna får anslutningsproblem som orsakas av underhåll samtidigt.

Kravspecifikation

När du använder aktiv geo-replikering bör du tänka på följande krav:

  • Både den primära och den geo-sekundära måste ha samma tjänstnivå och bör ha samma beräkningsnivå, beräkningsstorlek och redundans för lagring av säkerhetskopior.

  • Både den primära och den geo-sekundära bör ha samma brandväggsregler för IP-adresser.

Aktiv geo-replikering stöds för databaser i olika Azure-prenumerationer.

Överväganden

  • Aktiv geo-replikering är utformad för att tillhandahålla redundans för en enskild databas. Om du behöver failover för flera databaser bör du överväga att använda failover-grupper i stället.

  • Eftersom geo-replikering är asynkron är dataförlust möjlig när en redundansväxling inträffar. Om du behöver eliminera dataförlust från asynkron replikering under redundansväxlingar konfigurerar du programmet så att det blockerar den anropande tråden tills den senast genomförda transaktionen överförs och härdas i transaktionsloggen för den sekundära databasen. Den här metoden kräver anpassad utveckling och minskar programmets prestanda. Mer information finns i Förhindra förlust av kritiska data.

  • Mer information finns i Aktiv geo-replikering.

Kostnad

Sekundära databaser faktureras som separata databaser.

Om du inte använder en sekundär databas för läs- eller skrivarbetsbelastningar bör du överväga om du kan ange den som en standby-replik för att minska kostnaderna.

Konfigurera stöd för flera regioner

Normala åtgärder

I det här avsnittet beskrivs vad du kan förvänta dig när en databas är konfigurerad för aktiv geo-replikering och alla regioner är i drift.

  • Trafikroutning mellan regioner: Programmet måste konfigureras för att skicka skrivskyddade begäranden till den primära databasen. Du kan också skicka skrivskyddade begäranden till en sekundär databas, vilket minskar effekten av skrivskyddade arbetsbelastningar på din primära databas.

  • Datareplikering mellan regioner: Replikering mellan de primära och sekundära databaserna sker asynkront, vilket innebär att det kan uppstå en fördröjning mellan den tidpunkt då en ändring tillämpas på den primära databasen och när den replikeras till den sekundära databasen.

    När du utför en redundansväxling bestämmer du hur du ska hantera risken för dataförlust.

Region-down-upplevelse

Det här avsnittet beskriver vad du kan förvänta dig när en databas har konfigurerats för aktiv geo-replikering och det uppstår ett avbrott i din primära region:

  • Identifiering och svar: Du ansvarar både för att identifiera avbrott i en databas eller region och för att utlösa redundans.

  • Aktiva begäranden: Alla aktiva begäranden under redundansväxlingen avslutas och måste göras om.

  • Förväntad dataförlust: Om din primära databas är tillgänglig kan du utföra en redundansväxling utan dataförlust. Redundansväxlingsprocessen synkroniserar data mellan de primära och sekundära databaserna innan roller byts ut.

    Om din primära databas inte är tillgänglig kan du behöva utföra en tvingad redundansväxling, vilket resulterar i dataförlust. Du kan uppskatta mängden dataförlust genom att övervaka replikeringsfördröjningen. Mer information finns i Övervaka SQL Database med mått och aviseringar.

  • Förväntad stilleståndstid: Det är vanligtvis upp till 60 sekunders stilleståndstid under en redundansväxling. Se till att programmet hanterar tillfälliga fel så att det kan återställas från korta perioder av driftstopp. Hur snabbt du konfigurerar om programmet för att ansluta till den nya primära databasen påverkar även den stilleståndstid som du upplever.

  • Omdistribution av trafik: Du ansvarar för att konfigurera om programmet så att det skickar begäranden till den nya primära databasen. Om du behöver ha transparent redundans kan du överväga att använda redundansgrupper.

Regionåterställning

När den primära regionen har återställts kan du manuellt utföra en återgång till den primära regionen genom att utföra en annan övergång.

Testning för regionfel

Du kan simulera ett regionstopp genom att utlösa en manuell redundans när som helst. Du kan utlösa en redundansväxling (ingen dataförlust) eller en tvingad redundansväxling.

Backups

Gör säkerhetskopior av dina databaser för att skydda mot olika risker, inklusive dataförlust. Säkerhetskopior kan återställas för att återställas från oavsiktlig dataförlust, skada eller andra problem. Säkerhetskopior skiljer sig från zonredundans, aktiv geo-replikering eller redundansgrupper och de har olika syften. Mer information finns i Redundans, replikering och säkerhetskopiering.

SQL Database tillhandahåller automatiska säkerhetskopior av dina databaser. Mer information om säkerhetskopieringsfrekvensen, som kan påverka mängden dataförlust om du behöver återställa från en säkerhetskopia, finns i Automatiserade säkerhetskopior i SQL Database.

Lagring för säkerhetskopior

Du kan välja att lagra dina automatiserade säkerhetskopior i LRS eller ZRS. Om du använder en region som är kopplad kan du välja att replikera dina automatiserade säkerhetskopior till den kopplade regionen med hjälp av geo-redundant lagring. Den här funktionen möjliggör geo-återställning av dina säkerhetskopior till den kopplade regionen. Mer information finns i Automatiserade säkerhetskopieringar i SQL Database.

Om du använder en icke-kopplad region, eller om du behöver replikera säkerhetskopior till en annan region än den kopplade regionen, bör du överväga att exportera databasen och lagra den exporterade filen i ett lagringskonto som använder replikering av blobobjekt för att replikera till ett lagringskonto i en annan region. Mer information finns i Exportera en databas.

Tillförlitlighet under tjänstunderhåll

När SQL Database utför underhåll på dina databaser och elastiska pooler kan det automatiskt redundansväxla databasen för att använda en sekundär replik. Klientprogram kan observera korta anslutningsstörningar när en redundansväxling inträffar. Klientprogrammen bör följa vägledningen för tillfällig felhantering för att minimera effekterna.

Med SQL Database kan du ange ett underhållsperiod som vanligtvis används för tjänstuppgraderingar och andra underhållsåtgärder. Om du konfigurerar ett underhållsfönster kan du minimera eventuella biverkningar, till exempel automatiska redundansväxlingar, under kontorstid. Du kan också få förhandsmeddelanden om planerat underhåll.

Plattformen underhåller automatiskt de gatewayer som används för bearbetning av anslutningar till SQL Database. Uppgraderingar eller underhållsåtgärder kan också orsaka korta anslutningsstörningar som klienter kan försöka igen.

Mer information finns i underhållsfönstret i SQL Database.

Serviceavtal

Serviceavtalet (SLA) för SQL Database beskriver den förväntade tillgängligheten för tjänsten och den förväntade återställningspunkten och återställningstiden för aktiv geo-replikering. Den beskriver också de villkor som måste uppfyllas för att uppnå dessa förväntningar. För att förstå dessa villkor är det viktigt att du granskar serviceavtalen för onlinetjänster.

När du distribuerar en zonredundant databas eller elastisk pool och använder en tjänstnivå som stöds är serviceavtalet för drifttid högre.

Relaterat innehåll