Dela via

Tillförlitlighet i Azure Database for MySQL

Azure Database for MySQL är en fullständigt hanterad databastjänst som är utformad för att ge dig detaljerad kontroll och flexibilitet över databashanteringsfunktioner och konfigurationsinställningar. Tjänsten tillhandahåller funktioner för hög tillgänglighet och haveriberedskap 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 en mängd 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

Mer information om hur du distribuerar Azure Database for MySQL för att stödja lösningens tillförlitlighetskrav och hur tillförlitlighet påverkar andra aspekter av arkitekturen finns i Architecture best practices for Azure Database for MySQL in the Azure Well-Architected Framework.

Ö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å flera beräkningsnivåer: Burstable, Generell användning och Minnesoptimerad, som var och en är optimerad för olika typer av arbetsbelastningar.

Mer information om den allmänna tjänstarkitekturen och distributionsmodellerna finns i Vad är Azure Database for MySQL?.

Fysisk arkitektur

  • Beräknings- och lagringsseparation: Azure Database för MySQL använder en arkitektur med separat beräkning och lagring för att stödja hög tillgänglighet. Databasmotorn körs på en virtuell dator. Datafiler lagras i Azure Storage, som synkront underhåller tre kopior av data för att skydda mot maskinvarufel i lagringen. Beroende på serverns konfiguration med hög tillgänglighet kan datafiler lagras i zonredundant lagring (ZRS) eller lokalt redundant lagring (LRS).

  • Hög tillgänglighet: Du kan också aktivera en konfiguration med hög tillgänglighet på servern. När du aktiverar konfigurationen med hög tillgänglighet etablerar och underhåller tjänsten en varm reservdrift-replikserver. 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 så 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. Det finns två typer av redundans: oplanerade redundansväxlingar som används när den primära servern misslyckas och planerade redundansväxlingar, som används i andra scenarier där du behöver minimera programavbrott under en redundansväxling.

    Mer information finns i Hög tillgänglighet 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 fortfarande misslyckas efter de maximala återförsöken behandlar du den som ett fel.
  • Använd dä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 dina skrivoperationer idempotenta, så att de kan utföras säkert 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.

Du kan välja din typ av stöd för tillgänglighetszoner genom konfigurationen med hög tillgänglighet . När du aktiverar hög tillgänglighet distribueras en reservreplikserver tillsammans med den primära servern. Den här modellen med hög tillgänglighet hjälper till att säkerställa att incheckade data aldrig går förlorade vid fel. Oavsett vilken distributionsmodell med hög tillgänglighet du väljer, synkroniseras data till både den primära och standby replikserven. Om det uppstår ett avbrott på den primära servern växlar den automatiskt över till reservreplikservern.

Data lagras på Azure Files Premium Storage. Beroende på serverns konfiguration med hög tillgänglighet använder den antingen zonredundant lagring eller lokalt redundant lagring (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 hög tillgänglighet:

  • Zonredundant hög tillgänglighet: Zonredundans ger den högsta nivån av zonresiliens genom att distribuera en primär server i en tillgänglighetszon och en väntelägesreplikserver i en annan tillgänglighetszon. Väntelägesreplikservern använder liknande beräknings-, lagrings- och nätverkskonfiguration som den primära. En zonredundant konfiguration ger fysisk isolering av hela stacken mellan primära servrar och väntelägesservrar.

    Du väljer tillgänglighetszonerna för de primära servrarna och väntelägesservrarna.

    Vi rekommenderar zonredundanta distributioner för produktionsservrar.

    Skrivåtgärder kan uppleva en liten ökning av fördröjning vid bekräftelse eftersom tjänsten replikerar data synkront till standby-servern. I genomsnitt kan du förvänta dig 5–10 procent ökad svarstid för programskrivningar och incheckningar, men effekten varierar beroende på arbetsbelastning, vald SKU och region.

  • Lokal redundant hög tillgänglighet: De primära servrarna och väntelägesservrarna använder samma tillgänglighetszon. Om ett avbrott uppstår på den primära servern, men zonen fortfarande är felfri, redundansväxlar servern automatiskt till väntelägesservern.

    En lokal redundant distribution ger dig hög tillgänglighet i en enda tillgänglighetszon. Den skyddar dig mot fel på nodnivå och hjälper även till med att minska programavbrott under planerade och oplanerade driftstopp. Det skyddar dock inte mot ett avbrott i den zonen. I regioner med tillgänglighetszoner kallas den här typen av konfiguration ibland även zonindelad eller enskild zon.

    Vi rekommenderar lokal-redundant hög tillgänglighet endast i specifika scenarier:

    • När du har ovanligt svarstidskänsliga program har du verifierat behovet av att minimera svarstiden mellan din primära och sekundära replik, och du har planerat zonresiliens själv med hjälp av andra arkitekturmetoder.
    • När du distribuerar till en region som inte stöder tillgänglighetszoner fungerar regionen effektivt som en enda zon, vilket gör lokal redundant hög tillgänglighet till det enda alternativet för hög tillgänglighet.

    Eftersom servrarna finns i samma zon kan det minska skrivfördröjningen för program som du distribuerar i den zonen.

Om du konfigurerar servern utan hög tillgänglighet körs den på en enda server. Om servern eller dess zon slutar fungera är servern inte tillgänglig.

Requirements

  • Regionsstöd: Azure Database for MySQL har olika stöd för konfigurationer av tillgänglighetszoner mellan Azure-regioner. En fullständig lista över regioner och typer av stöd för tillgänglighetszoner och eventuella specifika överväganden för den regionen finns i Azure regioner.

  • Tjänstnivå: Hög tillgänglighet kräver nivåerna Generell användning eller Minnesoptimerad. Nivån Burstable stöder inte hög tillgänglighet (zonredundant eller lokalredundant).

Kostnad

När du aktiverar hög tillgänglighet skapas och faktureras väntelägesservern med samma hastighet som den primära servern. Konfigurationen av tillgänglighetszonen påverkar inte kostnaden. Det finns inga avgifter för datareplikering 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 prissättning.

Överväganden

  • Primärnycklar: Vi rekommenderar att du använder 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

Om du vill konfigurera stöd för tillgänglighetszoner för en server konfigurerar du inställningarna för hög tillgänglighet.

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 servrar konfigureras med stöd för hög tillgänglighet och tillgänglighetszon 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 alla databasanslutningar och frågor hanteras av den primära servern 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 överförs synkront till loggar till standbysystemet 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–10 procent ökad svarstid för programskrivningar och incheckningar, men effekten varierar beroende på arbetsbelastning, vald SKU och region.

    • Lokalt redundant: 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

I det här avsnittet beskrivs vad du kan förvänta dig när servrar konfigureras med hög tillgänglighet och stöd för tillgänglighetszoner, och det inträffar ett avbrott i en tillgänglighetszon.

  • 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.

    I händelse av ett zonfel 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 statustyper för hög tillgänglighet finns i Övervaka hög tillgänglighet. 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.

  • Notification: 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 redundansväxling inträffar.

  • Aktiva begäranden: När en tillgänglighetszon blir otillgänglig kan eventuella 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–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 påverkad 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.

    • Zone-redundant: Efter failover blir den tidigare standby-servern 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. Fullständig 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.

  • Zone-redundant: 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. 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. Du kan initiera en planerad redundansväxling manuellt om du vill returnera den primära till den ursprungliga zonen.

  • Lokalt redundant: När zonen är felfri är servrar i zonen tillgängliga igen. Du ansvarar för alla procedurer för zonåterställning 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 cross-region läsrepliker, 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

Du kan distribuera läsrepliker för att skydda dina databaser mot fel på regionnivå. Varje läsreplik är en separat Azure Database for 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 tio läsrepliker, som kan finnas i olika Azure-regioner. MySQL:s uppdateringar av den fysiska replikeringstekniken läser repliker asynkront från källservern i den primära regionen, och de kan fördröja 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.

Om den primära regionen går ned kan du manuellt växla över så att den sekundära repliken blir den primära servern. Det gör du genom att stoppa replikeringsprocessen, vilket gör att läsrepliken blir en skrivrättighetsserver. På grund av den asynkrona replikeringen kan redundans leda till dataförlust. Ditt program måste sedan ansluta till den nya primära servern och du ansvarar för omkonfigurationen av programmet.

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. Mer information finns i Läsa repliker.

Requirements

  • Region support: Du kan skapa läsrepliker över 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å läsrepliken när den har skapats. Det är dock bäst att använda lika stora eller större värden för att se till att repliken kan hålla jämna steg med förändringarna i källan.

  • Övervaka replikeringsfördröjning: Den asynkrona replikeringsprocessen kräver en replikeringsfördröjning, som kan variera beroende på ett antal 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.

  • Hög tillgänglighet: Läsrepliker kan inte ha hög tillgänglighet aktiverat, och när de skiftas för att bli den primära servern har de fortfarande inte hög tillgänglighet. Du ansvarar för att konfigurera hög tillgänglighet när du har 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. För detaljerad prisinformation, se Azure Database för MySQL-prissättning och bandbreddsprissättning.

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 servern har konfigurerats med en läsreplik i en annan region och alla regioner fungerar:

  • Trafikroutning mellan regioner: I 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ällserverprestanda. Mängden replikeringsfördröjning beror på ett antal 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 servern har konfigurerats med en läsreplik i en annan region 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 oreplikerade data.

    Viktigt!

    Du är ansvarig för att utlösa failover. Azure redundansväxlar inte till att läsa repliker automatiskt, även om det uppstår ett regionfel.

    Failover kräver att du:

    1. Stoppa replikeringen. Det här är en oåterkallelig procedur 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ärenheten.

    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. Den här processen resulterar i permanent förlust av oreplikerade 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 2 minuter efter att den har utlösts. Du ansvarar för att omkonfigurera dina program för att ansluta till den nya primära servern, och den tid det tar för dig att utföra omkonfigurationen bidrar också till den totala stilleståndstiden.

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

    Anmärkning

    Efter att du har bytt över en läsreplik till att bli den primära servern, är hög tillgänglighet inte aktiverad på servern. Du måste aktivera hög tillgänglighet manuellt eller inkludera den i din automatisering.

Regionåterställning

När regionen återhämtar sig ansvarar du för eventuella återgångsaktiviteter för att återuppta verksamheten 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, ungefär lika med replikeringsfördröjningen.
  • Utför övergången och acceptera förlusten av oreplikerad 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 failoverprocedurer för läsrepliker för att säkerställa att dina processer är giltiga och att funktionerna uppfyller dina RTO- och RPO-krav.

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 leda till dataförlust och kräver manuell återställning efter fel.

Som en del av din strategi för haveriberedskap kör du regelbundet fullständiga återställningstest. Dessa övningar bör omfatta dataverifiering, testning av programfunktioner och dokumenterade återställningsprocedurer.

Säkerhetskopiering och återställning

Azure Database for MySQL utför automatiskt säkerhetskopior som möjliggör återställning till en specifik tidpunkt och hjälper till att skydda mot oavsiktlig korruption och borttagning av data. Microsoft hanterar säkerhetskopieringar fullständigt, avbryter inte serverns tillgänglighet och inkluderar både fullständiga säkerhetskopior och säkerhetskopior av transaktionsloggar.

  • Lagring av säkerhetskopior: Om servern har konfigurerats med zonredundant hög tillgänglighet lagras säkerhetskopior i zonredundant lagring (ZRS). För servrar som konfigurerats utan hög tillgänglighet eller med lokal redundant hög tillgänglighet lagras säkerhetskopior i lokalt redundant lagring (LRS).

    I Azure-regioner med par kan du vid serverns skapande konfigurera geo-redundant säkerhetskopieringslagring (GRS) för att replikera säkerhetskopior till den Azure-parade regionen och därigenom bidra till ytterligare skydd mot regionfel. Säkerhetskopior replikeras asynkront.

    Standardperioden för kvarhållning av säkerhetskopior är 7 dagar, med möjlighet att utöka kvarhållningen upp till 35 dagar. Alla säkerhetskopior krypteras.

  • Återställa: Punkt i tid-återställning gör det möjligt att återställa databasen vid vilken tidpunkt som helst under säkerhetskopieringsperioden. Återställningsprocessen skapar en ny databasserver med ett nytt servernamn som tillhandahålls av användaren, som du sedan kan använda as-is eller kopiera data från.

    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.

    Den här funktionen är användbar 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åll med nästan noll driftstopp: Om servern har hög tillgänglighet aktiverad och uppfyller andra kriterier för berättigande slutförs underhållsåtgärder ofta inom 10–30 sekunder. Om du har hög tillgänglighet aktiverad använder underhållsåtgärder vanligtvis löpande uppdateringar för att minimera stilleståndstiden. Periodiska underhållsaktiviteter såsom delversionsuppgraderingar sker först på standby-replikan. För att minska stilleståndstiden höjs vänteläget upp till primärt så att arbetsbelastningarna kan fortsätta medan underhållsaktiviteterna tillämpas på den återstående noden. Den här sekvenseringen gäller om servern använder zonredundant eller lokal redundant hög tillgänglighet. 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 under omstarter av underhåll. Information om hur du gör dina program motståndskraftiga mot dessa typer av problem finns i Vägledning om motståndskraft mot tillfälliga fel .

  • Aktivera virtuellt kanarieunderhåll 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 din arbetsbelastning inte påverkas av kommande uppdateringar 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 konfigurerade med hög tillgänglighet med zonredundans.
  • Servrar som konfigurerats med lokal redundant hög tillgänglighet.
  • Servrar som konfigurerats utan hög tillgänglighet.

Relaterat innehåll

  • Last updated on