Tillförlitlighet i Azure Database for MySQL

Azure Database for MySQL är en fullständigt hanterad databastjänst som ger dig detaljerad kontroll och flexibilitet över databashanteringsfunktioner och konfigurationsinställningar. Tjänsten tillhandahåller funktioner för hög tillgänglighet (HA) och haveriberedskap (DR) baserat på dina krav.

När du använder Azure är reliability ett delat ansvar. Microsoft tillhandahåller en rad funktioner som stöder å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.

Den här artikeln beskriver hur du gör Azure Database for MySQL motståndskraftiga mot olika potentiella avbrott och problem, inklusive tillfälliga fel, avbrott i tillgänglighetszonen, regionstopp och serviceunderhåll. Den beskriver också hur du kan använda säkerhetskopior för att återställa från andra typer av problem och visar viktig information om Azure Database for MySQL serviceavtal (SLA).

Rekommendationer för produktionsdistribution

Azure Well-Architected Framework ger rekommendationer om tillförlitlighet, säkerhet, kostnad, åtgärder och prestanda. Information om hur dessa områden påverkar varandra och bidrar till en tillförlitlig Azure Database for MySQL lösning finns i Metodtips för arkitektur för Azure Database for MySQL.

Översikt över tillförlitlighetsarkitektur

I det här avsnittet beskrivs några av de viktiga aspekterna av hur tjänsten fungerar som är mest relevant ur ett tillförlitlighetsperspektiv. I avsnittet beskrivs den logiska arkitekturen, som innehåller några av de resurser och funktioner som du distribuerar och använder. Den diskuterar också den fysiska arkitekturen, som innehåller information om hur tjänsten fungerar under täcket.

Logisk arkitektur

När du arbetar med Azure Database for MySQL distribuerar du en server som representerar de beräknings- och lagringsresurser som krävs för att stödja databasservern. Du distribuerar en eller flera databaser till servern.

Du kan distribuera servrar på beräkningsnivåerna Burstable, General Purpose och Memory Optimized. Varje beräkningsnivå är optimerad för olika typer av arbetsbelastningar.

Mer information om den allmänna tjänstarkitekturen och distributionsmodellerna finns i Azure Database for MySQL översikt.

Fysisk arkitektur

  • Beräknings- och lagringsavgränsning: Azure Database for MySQL använder en beräknings- och lagringssepareringsarkitektur för att stödja HA. Databasmotorn körs på en virtuell dator (VM). Datafiler lagras i Azure Storage, som synkront underhåller tre kopior av data för att skydda mot maskinvarufel i lagringen. Beroende på serverns HA-konfiguration kan datafiler lagras i zonredundant lagring (ZRS) eller lokalt redundant lagring (LRS).

  • HA: Du kan också aktivera en HA-konfiguration på servern. När du aktiverar HA-konfigurationen etablerar och underhåller tjänsten en varm väntelägesreplikserver. Dataändringar på den primära servern replikeras synkront till väntelägesreplikservern för att säkerställa noll dataförlust vid fel på den primära servern.

    Arkitekturen separerar beräkningslagret från lagringslagret, vilket gör att tjänsten kan hantera olika typer av fel på rätt sätt. För högre återhämtning kan du sprida servrarna mellan tillgänglighetszoner.

    En väntelägesreplikserver distribueras i samma VM-konfiguration som den primära servern, inklusive virtuella kärnor, lagring och nätverksinställningar.

    Du kan växla mellan servrar genom att utföra en övergång. Använd oplanerade redundansväxlingar när den primära servern misslyckas och använd planerade redundansväxlingar när du behöver minimera programavbrott under en redundansväxling.

    Mer information finns i HA i Azure Database for MySQL.

  • Backups: Azure Database for MySQL skapar automatiskt serversäkerhetskopior. Mer information finns i Säkerhetskopiering och återställning.

Motståndskraft mot 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 Azure övergående felhantering när de kommunicerar med molnbaserade API:er, databaser och andra komponenter. Mer information finns i Rekommendationer för hantering av tillfälliga fel.

Dina program måste hantera tillfälliga anslutningsfel som kan inträffa under underhåll, skalningsåtgärder eller nätverksavbrott. Följ dessa rekommendationer:

  • När programmet stöter på tillfälliga fel försöker du utföra åtgärden igen med exponentiell backoff. Öka fördröjningen mellan återförsök och begränsa antalet försök. Om åtgärden fortsätter att misslyckas efter det maximala antalet återförsök behandlar du den som ett fel.

  • Använd när det är möjligt klientbibliotek som automatiskt hanterar återförsök.

  • Tillfälliga fel som uppstår under skrivåtgärder kräver mer noggrant övervägande. Överväg att göra skrivåtgärderna idempotenta så att du kan utföra dem flera gånger.

Motståndskraft mot fel i tillgänglighetszonen

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

Välj din typ av stöd för tillgänglighetszoner via HA-konfigurationen. När du aktiverar HA distribuerar Azure Database for MySQL en väntelägesreplikserver tillsammans med din primära server. Den här HA-modellen hjälper till att säkerställa att incheckade data aldrig går förlorade vid fel. Oavsett vilken driftsättningsmodell för HA du väljer lagrar tjänsten data synkront på både den primära replikservern och replikservern i vänteläge. Om den primära servern drabbas av ett avbrott växlar servern automatiskt över till standbyreplikservern.

Tjänsten lagrar data på Azure Files Premium Storage. Beroende på serverns HA-konfiguration använder den antingen ZRS eller LRS, som lagrar tre datakopior inom eller mellan tillgänglighetszoner.

Azure Database for MySQL stöder två konfigurationstyper för tillgänglighetszoner när du använder HA:

Om du konfigurerar servern utan HA körs den på en enda server. Om servern eller dess zon misslyckas är servern inte tillgänglig.

Requirements

  • Regionstöd: Azure Database for MySQL stöder olika konfigurationer av tillgänglighetszoner beroende på din Azure region. En fullständig lista över regioner, inklusive typer av stöd för tillgänglighetszoner och specifika överväganden för varje region, finns i Azure regioner.

  • Tjänstnivå: HA kräver nivåerna Generell användning eller Minnesoptimerad. Burstable-nivån stöder inte HA (zonredundant eller lokalredundant).

Kostnad

När du aktiverar HA skapar och betalar du för väntelägesservern till samma pris som den primära servern. Konfigurationen av tillgänglighetszonen påverkar inte kostnaden. Datareplikering medför inga avgifter inom eller mellan tillgänglighetszoner. Beroende på din lagringsvolym för säkerhetskopiering kan du också debiteras för lagring av säkerhetskopior. Detaljerad prisinformation finns i Azure Database for MySQL priser.

Överväganden

  • Primära nycklar: Använd primära nycklar i alla tabeller eftersom den här metoden minskar replikeringen och redundanstiden.

  • Begränsningar och kända problem: Granska listan över begränsningar och kända problem.

Konfigurera stöd för tillgänglighetszoner

Konfigurera HA-inställningarna för att konfigurera stöd för tillgänglighetszoner för en server.

Anmärkning

När du väljer vilka tillgänglighetszoner som ska användas väljer du faktiskt den logiska tillgänglighetszonen. Om du distribuerar andra arbetsbelastningskomponenter i en annan Azure prenumeration kan de använda ett annat logiskt tillgänglighetszonnummer för att få åtkomst till samma fysiska tillgänglighetszon. Mer information finns i Fysiska och logiska tillgänglighetszoner.

Beteende när alla zoner är felfria

I det här avsnittet beskrivs vad du kan förvänta dig när du konfigurerar servrar med HA och stöd för tillgänglighetszoner, och alla tillgänglighetszoner är i drift.

  • Åtgärd mellan zoner: MySQL-klientprogram ansluter till den primära servern med hjälp av databasserverns fullständigt kvalificerade domännamn (FQDN). Undvik att använda IP-adressen för den primära servern eftersom IP-adressen kan ändras, inklusive under redundansväxlingar.

    Azure Database for MySQL använder en aktiv-passiv konfiguration där den primära servern hanterar alla databasanslutningar och frågor i den primära tillgänglighetszonen. Replikservern i vänteläge hanterar inte klienttrafik under normala driftförhållanden.

  • Datareplikering mellan zoner: Skrivningar bekräftas på den primära servern och skrivs synkront till loggarna på sekundärservern med hjälp av ZRS. Den primära servern väntar inte på att väntelägesservern ska tillämpa loggarna, men eftersom loggarna finns i ZRS är de tillgängliga även om ett replik- eller zonfel inträffar.

    Effekterna av replikering skiljer sig beroende på konfigurationen av tillgänglighetszonen som servern använder:

    • Zonredundant: Eftersom servrarna finns i separata zoner garanterar den här metoden noll dataförlust vid ett zonfel. Den här situationen kallas också för att uppnå ett återställningspunktmål (RPO) på noll vid zonfel.

      Replikering mellan zoner kan dock medföra en liten mängd extra svarstider. I genomsnitt kan du förvänta dig 5% till 10% ökad svarstid för programskrivningar och incheckningar, men effekten varierar beroende på arbetsbelastning, vald SKU och region.

    • Lokal redundans: Ingen trafik replikeras mellan zoner.

    Anmärkning

    Systemet replikerar alla ändringar i realtid till väntelägesreplikservern, inklusive oavsiktliga användarfel som en oavsiktlig borttagning av en tabell eller felaktiga datauppdateringar. På grund av den omedelbara replikeringen kan du inte använda väntelägesrepliken för återställning. Om du vill återhämta dig från användarfel måste du göra en återställning till en specifik tidpunkt från en säkerhetskopia. Mer information finns i Säkerhetskopiering och återställning.

Beteende vid ett zonfel

Det här avsnittet beskriver vad du kan förvänta dig när du konfigurerar servrar med stöd för HA och tillgänglighetszoner, och det uppstår ett avbrott i tillgänglighetszonen.

  • Detection och svar: Azure kontrollerar regelbundet hälsotillståndet för både primära servrar och väntelägesservrar. Om hälsoövervakning upptäcker att en primär server inte kan nås efter flera pingar initierar tjänsten en automatisk redundansväxling till väntelägesservern. Algoritmen för hälsoövervakning använder flera datapunkter för att undvika falska positiva situationer.

    Om ett zonfel inträffar skiljer sig beteendet beroende på vilken konfiguration av tillgänglighetszonen som servern använder:

    • Zone-redundant: Azure Database for MySQL identifierar automatiskt fel i tillgänglighetszonen genom att kontinuerligt övervaka flera serverslutpunkter. Mer information finns i Så här fungerar automatisk redundansidentifiering på HA-aktiverade servrar.

      Information om möjliga ha-statustyper finns i Övervaka HA. När en zon misslyckas initierar Azure en oplanerad redundansväxling till väntelägesservern utan att du behöver vidta åtgärder.

    • Lokalt redundant: Både primära servrar och väntelägesservrar är inte tillgängliga om tillgänglighetszonen som är värd för en lokal redundant server blir otillgänglig. I det här scenariot tillhandahåller tjänsten inte automatisk redundans. Du ansvarar för att identifiera zonavbrottet och utföra återställningsåtgärder, till exempel återställa zonredundanta säkerhetskopieringar till en separat server i en annan tillgänglighetszon eller region.

  • Anmälan: Microsoft meddelar dig inte automatiskt när en zon är nere. Du kan dock använda Azure Resource Health för att övervaka hälsotillståndet för en enskild resurs, och du kan konfigurera Resource Health aviseringar för att meddela dig om problem. Du kan också använda Azure Service Health för att förstå tjänstens övergripande hälsotillstånd, inklusive eventuella zonfel, och du kan konfigurera Service Health-aviseringar för att meddela dig om problem.

    Azure Database for MySQL genererar en Azure Resource Health-händelse när en oplanerad failover inträffar.

  • Aktiva begäranden: När en tillgänglighetszon blir otillgänglig kan pågående begäranden till servrar i den berörda zonen avslutas. Applikationer måste försöka dessa förfrågningar igen. Om klienterna hanterar tillfälliga fel på rätt sätt genom att försöka igen efter en kort tidsperiod undviker de vanligtvis betydande påverkan.

  • Förväntad dataförlust: Mängden dataförlust beror på serverns konfiguration av tillgänglighetszonen.

    • Zonredundant: Ingen dataförlust förväntas under zonredundans på grund av synkron replikering mellan de primära servrarna och väntelägesservrarna i olika zoner.

    • Lokalt redundant: Data på servrar i den berörda zonen är inte tillgängliga förrän zonen återställs.

  • Förväntad stilleståndstid: Mängden stilleståndstid beror på konfigurationen av tillgänglighetszonen som servern använder.

    • Zonredundant: Redundansväxlingen slutförs vanligtvis inom 60 till 120 sekunder. Om klienterna hanterar tillfälliga fel på rätt sätt genom att försöka igen efter en kort tidsperiod undviker de vanligtvis betydande påverkan.

    • Lokalt redundant: Servrar i en berörd zon är inte tillgängliga förrän tillgänglighetszonen återställs.

  • Omfördelning: Hur trafiken omdirigeras beror på vilken konfiguration av tillgänglighetszonen som servern använder.

    • Zonredundant: Efter redundansväxlingen blir väntelägesservern den nya primära servern och börjar acceptera nya anslutningar. Azure upprättar automatiskt en väntelägesserver i den ursprungliga primära zonen när den har återställts. Mer information finns i Oplanerad redundans.

    • Lokalt redundant: När en zon inte är tillgänglig är servern inte tillgänglig. Om du har en separat server som du har skapat i en annan tillgänglighetszon eller region ansvarar du för att omdirigera trafik till den servern.

Zonåterställning

Zonens återställningsbeteende beror på konfigurationen av tillgänglighetszonen som servern använder.

  • Zonredundant: När tillgänglighetszonen återställs återskapar Azure Database for MySQL automatiskt väntelägesservern i den återställda zonen och synkroniserar den med den aktuella primära servern. Den återställda zonen fungerar sedan som väntelägesplats. Tjänsten flyttar inte automatiskt tillbaka den primära rollen till den ursprungliga zonen för att undvika onödiga störningar. Om du vill returnera den primära till den ursprungliga zonen kan du initiera en planerad redundansväxling manuellt.

  • Lokalt redundant: När zonen är felfri är servrar i zonen tillgängliga igen. Du ansvarar för zonåterställningsprocedurer och datasynkronisering som dina arbetsbelastningar kräver.

Test för zonfel

Alternativen för testning av zonfel beror på konfigurationen av tillgänglighetszonen som din instans använder.

Motståndskraft mot regionomfattande fel

Azure Database for MySQL stöder läsrepliker mellan regioner, som du kan använda för att underhålla en synkroniserad kopia av databasen i en annan region för snabbare återställning.

Du kan också använda geo-redundanta säkerhetskopior i regioner som stöds för att tillhandahålla återställning mellan regioner. Säkerhetskopieringar innebär dock vanligtvis mer stilleståndstid och dataförlust än replikering. Mer information finns i Säkerhetskopiering och återställning.

Läsrepliker mellan regioner

Distribuera läsrepliker för att skydda dina databaser mot regionala fel. Varje läsreplik är en separat Azure Database för MySQL-server. När du placerar en läsreplik i en andra Azure region kan databasservern ge motståndskraft mot ett regionomfattande problem. Du kan distribuera upp till 10 läsrepliker som valfritt kan finnas i olika Azure-regioner.

MySQL-teknik för fysisk replikering uppdaterar läsrepliker asynkront från källservern i den primära regionen, vilket innebär att replikerna kan ligga efter källan. Skrivskyddade repliker mellan regioner kan eventuellt hantera skrivskyddade arbetsbelastningar för att minska svarstiden för globalt distribuerade program eller för att avlasta lästrafik från källservern. Mer information om funktioner och överväganden för läsrepliker finns i Läsrepliker.

Diagram som visar en läsreplik i en sekundär Azure region, där programmet dirigerar läs- och skrivtrafik till källservern.

Om den primära regionen slutar fungera kan du manuellt växla över så att den sekundära repliken blir den primära servern. Om du vill utföra en manuell redundansväxling stoppar du replikeringsprocessen, vilket gör att läsrepliken omvandlas till en läs- och skrivbar server. På grund av den asynkrona replikeringen kan redundans leda till dataförlust. Programmet måste ansluta till den nya primära servern och du ansvarar för omkonfigurationen av programmet.

Diagram som visar en läsreplik i en andra Azure-region som har växlats över för att bli den primära servern, och programmet dirigerar nu läs- och skrivtrafik till den sekundära regionen.

Anmärkning

Det här avsnittet sammanfattar en del av den viktiga informationen om hur läsrepliker kan stödja motståndskraft mot regionomfattande fel. Du kan också använda läsrepliker för att förbättra prestanda och stödja storskaliga geografiskt distribuerade användarbaser.

Requirements

  • Region support: Du kan skapa läsrepliker mellan regioner i alla regioner som stöder Azure Database for MySQL. Du är inte begränsad till Azure parkopplade regioner.

  • Beräkningsnivåer: Beräkningsnivåerna Allmänt ändamål och Minnesoptimerad stöder läsrepliker. Nivån Burstable stöder inte läsrepliker.

Överväganden

  • Konfigurationsskillnader: När du skapar en replik ärver den flera inställningar från källservern, inklusive beräkningsgenerering, virtuella kärnor och lagring. Du kan anpassa dessa värden på den lästa repliken när du har skapat den, men det är bäst att använda lika med eller större värden för att säkerställa att repliken kan hålla jämna steg med ändringar i källan.

  • Övervaka replikeringsfördröjning: Den asynkrona replikeringsprocessen kräver en replikeringsfördröjning som kan variera beroende på flera faktorer. När replikeringsfördröjningen är mycket hög kan servern få problem. Det är viktigt att övervaka replikeringsfördröjningen så att du kan åtgärda problem innan de eskaleras. Mer information finns i Övervaka replikering.

  • HA: Läsrepliker kan inte ha HA aktiverat, och när de växlas över till att bli den primära servern har de inte heller HA. Du ansvarar för att konfigurera HA efter att ha växlat över till en replik.

Kostnad

Läsrepliker medför beräknings- och lagringskostnader samt avgifter för dataöverföring mellan regioner för replikering. Detaljerad prisinformation finns i prissättningen för Azure Database for MySQL och bandbredd.

Konfigurera stöd för flera regioner

Beteende när alla regioner är felfria

I det här avsnittet beskrivs vad du kan förvänta dig när du konfigurerar servern med en läsreplik i en annan region och alla regioner fungerar:

  • Trafikroutning mellan regioner: Under normala åtgärder bör programmet dirigera läs-och skrivtrafik till källservern i den primära regionen. Du kan valfritt dirigera läsbegäranden till din läsreplik.

  • Datareplikering mellan regioner: Läsrepliker mellan regioner använder asynkron replikering för att minimera påverkan på källserverns prestanda. Mängden replikeringsfördröjning beror på flera faktorer, inklusive skrivbelastningen och svarstiden mellan källservern och replikerna. Replikeringsfördröjningen är vanligtvis minst flera minuter, men det kan ta mycket längre tid. Mer information finns i Övervaka replikering och detaljerade instruktioner finns i Övervaka replikering i Azure-portalen.

Beteende under ett regionfel

Det här avsnittet beskriver vad du kan förvänta dig när du konfigurerar en server för stöd för läsreplik mellan regioner och det uppstår ett avbrott i den primära regionen.

  • Identifiering och svar: Du ansvarar för att identifiera ett avbrott i den primära regionen och manuellt utlösa en redundansväxling. Den här åtgärden kan leda till förlust av data som inte har replikerats.

    Viktigt!

    Du är ansvarig för att utlösa failover. Azure växlar inte över till läsrepliker automatiskt, även om ett regionbortfall inträffar.

    Redundans kräver att du vidtar följande steg:

    1. Stoppa replikeringen. Den här proceduren är oåterkallelig och servern kan inte göras till en replik igen. Processen resulterar i dataförlust. Mer information om konsekvenserna av den här åtgärden finns i Stoppa replikering.

    2. Konfigurera om programmet så att det använder den nya primära servern.

    Mer information finns i Failover.

  • Notification: Microsoft meddelar dig inte automatiskt när en region är nere. Du kan dock använda Azure Service Health för att förstå tjänstens övergripande hälsotillstånd, inklusive eventuella regionfel, och du kan konfigurera Service Health-aviseringar för att meddela dig om problem.

  • Aktiva begäranden: Alla aktiva anslutningar till källregionen tas bort om källservern inte är tillgänglig. Program måste försöka upprätta anslutningar till den nya primära servern igen när redundansväxlingen har slutförts.

  • Förväntad dataförlust: Under ett regionstopp måste du utföra en redundansväxling som stoppar replikeringen. Denna process resulterar i permanent förlust av icke-replicerade data.

    Mängden dataförlust beror på replikeringsfördröjningen vid tidpunkten för avbrottet. Replikeringsfördröjningen är vanligtvis minst flera minuter, men det kan ta mycket längre tid. Mer information finns i Övervaka replikering.

  • Förväntad stilleståndstid: Att stoppa replikeringen slutförs vanligtvis inom två minuter efter att du har utlöst åtgärden. Du ansvarar för att konfigurera om dina program för att ansluta till den nya primära servern. Den tid det tar för dig att utföra omkonfigurationen bidrar också till din totala stilleståndstid.

  • Omdistribution av trafik: Du ansvarar för att konfigurera om dina program för att ansluta till den nya primära servern.

    Anmärkning

    När du har redundansväxlat en läsreplik så att den blir den primära servern är HA inte aktiverat på servern. Du måste aktivera HA manuellt eller inkludera den i din automatisering.

Regionåterställning

När regionen återhämtar sig ansvarar du för återflyttningsaktiviteterna för att återuppta driften i den primära regionen. Microsoft flyttar inte den primära servern automatiskt. Du kan skapa en ny läsreplik i det primära området och sedan utföra en annan failover-process för att återställa driften i det primära området. Överväg någon av följande metoder, beroende på om ditt program kan tolerera driftstopp eller dataförlust:

  • Ta programmet offline och vänta tills replikeringen kommer ikapp alla ändringar. Den här metoden kräver programavbrott som är ungefär samma som replikeringsfördröjningen.

  • Utför redundansväxlingen och acceptera förlusten av icke-replikerade data.

Kom ihåg att du också ansvarar för att konfigurera om dina program för att ansluta till den nya primära servern efter behov.

Test för regionfel

Testa regelbundet redundansväxlingsprocedurer för läsrepliker för att säkerställa att dina processer är giltiga och att kapaciteten uppfyller dina krav på återställningstid (RTO) och RPO.

Du kan när som helst använda en läsreplik som primär server, trots att alla regioner är felfria. Vi rekommenderar att du utför dessa tester i en icke-produktionsmiljö eftersom det kan orsaka dataförlust och kräver manuell återställning efter fel.

Som en del av din DR-strategi kör du regelbundet fullständiga återställningstest. Dessa övningar omfattar dataverifiering, testning av programfunktioner och dokumenterade återställningsprocedurer.

Säkerhetskopiering och återställning

Azure Database for MySQL säkerhetskopierar dina data automatiskt, så att du kan återställa dem till valfri tidpunkt inom kvarhållningsperioden för säkerhetskopior. Det här skyddet hjälper dig att undvika oavsiktlig skada och borttagning av data. Microsoft hanterar säkerhetskopiorna fullständigt utan att störa serverns tillgänglighet. Säkerhetskopiorna omfattar både fullständiga säkerhetskopior och säkerhetskopior av transaktionsloggar.

  • Lagring av säkerhetskopior: Om du konfigurerar servern med zonredundant HA lagrar systemet säkerhetskopior i ZRS. För servrar som konfigurerats utan HA eller med lokalt redundant HA lagrar systemet säkerhetskopior i LRS.

    I Azure regioner som har par kan du konfigurera geo-redundant lagring (GRS) för säkerhetskopior när du skapar servern. Den här metoden replikerar säkerhetskopior till Azures parkopplade region för extra skydd mot regionsfel. Systemet replikerar säkerhetskopior asynkront.

    Standardperioden för kvarhållning av säkerhetskopior är 7 dagar, men du kan utöka kvarhållningen upp till 35 dagar. Alla säkerhetskopior krypteras.

  • Återställ: Med återställning till en viss tidpunkt (PITR) kan du återställa din databas till valfri tidpunkt inom lagringsperioden för säkerhetskopior. Återställningsprocessen skapar en ny databasserver med ett nytt servernamn som tillhandahålls av användaren. Du kan använda den nya servern as-is eller kopiera data från den.

    När du återställer en geo-redundant säkerhetskopia skapar du en ny server i den kopplade regionen. I vissa regioner kan du använda Universell Geo-Restore för att återställa en geo-redundant säkerhetskopia till en region som inte är den primära regionens parkopplade region.

    Använd den här funktionen för att återställa från oavsiktliga dataändringar, programfel eller testscenarier.

För de flesta lösningar bör du inte enbart förlita dig på säkerhetskopior. Använd i stället de andra funktionerna som beskrivs i den här guiden för att stödja dina återhämtningskrav. Säkerhetskopior skyddar dock mot vissa risker som andra metoder inte gör. Mer information finns i Vad är redundans, replikering och säkerhetskopiering?.

Mer information finns i Backup och återställning i Azure Database for MySQL.

Motståndskraft mot serviceunderhåll

Azure Database for MySQL hanterar automatiskt kritiska serviceuppgifter, inklusive korrigering av den underliggande maskinvaran, operativsystemet och databasmotorn. Tjänsten innehåller säkerhetsuppdateringar, programuppdateringar och delversionsuppgraderingar som en del av planerat underhåll. Mer information finns i Planerat underhåll i Azure Database for MySQL.

Följ dessa rekommendationer för att säkerställa att servern förblir tillgänglig under underhållsperioder:

  • Undvik hanteringsåtgärder under underhållsperioder. Utför inte serverhanteringsåtgärder medan underhåll pågår eftersom dessa åtgärder kan påverka serverns tillförlitlighet.

  • Använd underhållsläge nära noll stilleståndstid. Om servern har HA aktiverat och uppfyller andra kriterier för berättigande slutförs underhållsåtgärden vanligtvis inom 10 till 30 sekunder. Om du aktiverar HA använder underhållsåtgärder vanligtvis löpande uppdateringar för att minimera stilleståndstiden. Periodiska underhållsaktiviteter, till exempel delversionsuppgraderingar, sker först på väntelägesrepliken. För att minska stilleståndstiden höjs väntelägesservern upp till primär så att arbetsbelastningar kan fortsätta att köras medan underhållsaktiviteterna tillämpas på den återstående noden. Den här sekvenseringen gäller om servern använder zonredundant eller lokalt redundant HA. Mer information finns i Underhållsläge nära noll stilleståndstid.

  • Konfigurera anpassade underhållsfönster. Du kan konfigurera underhållsschemat så att det är systemhanterat eller definiera ett anpassat underhållsfönster för att minimera påverkan på din verksamhet. Du kan också schemalägga om planerade underhållsåtgärder. Schemalägg underhåll under perioder med låg aktivitet för att minimera påverkan på verksamheten. Mer information finns i Hantera schemalagda underhållsinställningar för Azure Database for MySQL.

  • Implementera logik för återförsök. Se till att dina program kan hantera korta anslutningsavbrott som kan inträffa vid omstart av underhåll. Information om hur du gör dina program motståndskraftiga mot dessa typer av problem finns i Motståndskraft mot tillfälliga fel.

  • Aktivera underhåll för Virtual Canary på utvecklings- och testservrar. Virtual Canary-underhåll ger tidig åtkomst till uppdateringar. Genom att aktivera den på utvecklings- och testservrar kan du kontrollera att kommande uppdateringar inte påverkar din arbetsbelastning innan de når dina produktionsservrar. Mer information finns i Underhåll av virtuell kanariefågel.

Serviceavtal

Serviceavtalet (SLA) för Azure tjänster beskriver den förväntade tillgängligheten för varje tjänst och de villkor som din lösning måste uppfylla för att uppnå den tillgänglighetsförväntningen. Mer information finns i SLAs for online služby.

Azure Database for MySQL tillhandahåller olika tillgänglighets serviceavtal baserat på serverns konfiguration:

  • Servrar som konfigurerats med zonredundant HA.
  • Servrar som konfigurerats med lokalt redundant HA.
  • Servrar som konfigurerats utan HA.

Relaterat innehåll

  • Last updated on