Schemalagt underhåll i Azure Database for MySQL

2025-05-08

Azure Database for MySQL utför regelbundet underhåll för att hålla din hanterade databas säker, stabil och uppdaterad. Under underhållet får servern nya funktioner, uppdateringar och korrigeringar.

Viktigt!

Undvik alla serveråtgärder (ändringar, konfigurationsändringar, start/stopp) under Underhåll av Azure Database for MySQL. Att delta i dessa aktiviteter kan leda till oförutsägbara resultat som kan påverka serverns prestanda och stabilitet. Vänta tills underhållet avslutas innan du utför serveråtgärder.

Underhållscykel

I följande avsnitt beskrivs underhållstyperna. För specifika detaljer om vad varje underhållsuppdatering innebär, hänvisa till versionsinformationen. Dessa anteckningar innehåller omfattande information om de uppdateringar som tillämpas under underhåll, så att du kan förstå och förbereda dig för eventuella ändringar som påverkar din miljö.

Kommentar

Alla servrar måste inte nödvändigtvis underhållas under schemalagda uppdateringar, oavsett om de är rutinmässiga eller kritiska. Azure MySQL-teamet använder specifika kriterier för att avgöra vilka servrar som kräver underhåll. Den här selektiva metoden säkerställer att underhåll är både effektivt och viktigt, skräddarsys efter de unika behoven i varje servermiljö och minimerar produktionsavbrott.

Rutinunderhåll

Vår standardunderhållscykel är inte mindre frekvent än var 30:e dag. Den här perioden hjälper till att säkerställa systemstabilitet och prestanda samtidigt som avbrott i dina tjänster minimeras.

Kritiskt underhåll

I vissa scenarier, till exempel behovet av att distribuera brådskande säkerhetskorrigeringar eller uppdateringar som är viktiga för att upprätthålla tillgänglighet och dataintegritet, kan vi utföra underhåll oftare. Dessa undantag hjälper dig att skydda dina data och säkerställa kontinuerlig drift av dina tjänster.

Virtuellt kanarieunderhåll

Virtual Canary är ett experimentellt underhållsprogram som ger tidig åtkomst till uppdateringar. Det gör det möjligt för kunder att testa arbetsbelastningskompatibilitet med nya Azure Database for MySQL-versioner och ge feedback om nya funktioner.

Till skillnad från rutinunderhåll följer Virtual Canary inte det minsta gapet på 30 dagar eller meddelandeperioden på 7 dagar. Det här programmet hjälper kunder att proaktivt validera nya funktioner och bidra med tidig feedback för produktförbättringar. Burstable-nivåservrar, som ofta används för icke-produktionsmiljöer, registreras automatiskt i programmet Virtual Canary.

Registrering för virtuell Canary

Azure Database for MySQL ger kunderna flexibilitet att hantera sitt deltagande i programmet Virtual Canary. Kunder kan välja att delta i eller ut ur programmet efter behov för att anpassa sig till deras driftskrav.

Om du vill kontrollera om servern har registrerats i programmet Virtuell kanariefågel använder du följande kommando. Om resultatet innehåller "patchStrategy": "VirtualCanary"registreras servern i programmet.

az mysql flexible-server show --resource-group {resourcegroupname} --name {servername} --query "maintenancePolicy"

Om du vill registrera en server i programmet Virtual Canary kör du följande kommando:

az mysql flexible-server update --resource-group {resourcegroupname} --name {servername} --maintenance-policy-patch-strategy VirtualCanary

Om du vill lämna programmet Virtual Canary och återgå till standardunderhållsprincipen använder du följande kommando:

az mysql flexible-server update --resource-group {resourcegroupname} --name {servername} --maintenance-policy-patch-strategy Regular

Underhållsperioder

Du kan schemalägga underhåll under en viss veckodag och en tidsperiod under den dagen. Eller så kan du låta systemet välja en dag och ett tidsfönster åt dig automatiskt. Hur som helst aviserar systemet dig sju dagar innan det kör något underhåll. Systemet meddelar dig också när underhållet startar och när det har slutförts.

Meddelanden om kommande schemalagt underhåll kan vara:

Skickas via e-post till en specifik adress.
Skickas via e-post till en Azure Resource Manager-roll.
Skickas i ett sms (SMS) till mobila enheter.
Skickas som ett meddelande till en Azure-app.
Levereras som ett röstmeddelande.

När du anger inställningar för underhållsschemat kan du välja en dag i veckan och ett tidsfönster. Om du inte anger inställningar väljer systemet tider mellan 23:00 och 07:00 i serverns regiontid. Du kan definiera olika scheman för varje flexibel server i din Azure-prenumeration.

Du kan uppdatera schemaläggningsinställningarna när som helst. Om underhåll schemaläggs för den flexibla servern och du uppdaterar schemaläggningsinställningarna fortsätter den aktuella distributionen som schemalagd. Ändringen av schemaläggningsinställningarna träder i kraft när den slutförs för nästa schemalagda underhåll.

Du kan definiera ett systemhanterat schema eller ett anpassat schema för varje flexibel server i din Azure-prenumeration:

Med ett anpassat schema kan du ange underhållsfönstret för servern genom att välja veckodag och en tidsperiod på en timme.
Med ett systemhanterat schema väljer systemet ett entimmesfönster mellan 23:00 och 07:00 under serverns regiontid.

Viktigt!

Från och med den 31 augusti 2024 har Azure Database for MySQL inte längre stöd för anpassade underhållsfönster för Burstable-nivåinstanser. Den här ändringen förenklar underhållsprocesserna och säkerställer optimala prestanda. Vår analys visade också att antalet användare som använder anpassade underhållsfönster på Burstable-nivåer är minimalt.

Befintliga burstable-nivåinstanser med anpassade underhållsfönster påverkas inte. Användarna kan dock inte längre ändra de här inställningarna för anpassade underhållsperioder.

För kunder som behöver anpassade underhållsfönster rekommenderar vi att du uppgraderar till nivån Generell användning eller Affärskritisk.

I sällsynta fall kan en underhållshändelse avbrytas av systemet eller misslyckas. Om en underhållshändelse misslyckas återställs uppdateringen och den tidigare versionen av binärfilerna återställs. I scenarier med misslyckade uppdateringar kan du fortfarande få en omstart av servern under underhållsfönstret.

Om en underhållshändelse avbryts eller misslyckas skickar systemet ett meddelande till dig. Nästa försök att utföra underhåll schemaläggs enligt dina aktuella inställningar. Du får ett meddelande om nästa försök fem dagar i förväg.

Underhåll nära noll stilleståndstid (förhandsversion)

Underhållsfunktionen för Azure Database for MySQL nära noll driftstopp är en banbrytande utveckling för servrar med hög tillgänglighet. Den här funktionen är utformad för att avsevärt minska underhållsavbrott. Den här funktionen är avgörande för företag som kräver hög tillgänglighet och minimala avbrott i sin databasverksamhet.

Exakta förväntningar på stilleståndstid

Stilleståndstid: I de flesta fall varierar stilleståndstiden under underhåll från 10 till 30 sekunder.
Ytterligare överväganden: Efter en redundanshändelse finns det en inbyggd TTL-period (time to live) för DNS på cirka 30 sekunder. Den här perioden styrs inte direkt av underhållsprocessen, men är en standarddel av DNS-beteendet. Så ur kundens perspektiv kan den totala stilleståndstiden under underhåll vara 40 till 60 sekunder.

Villkor och begränsningar

Observera följande villkor och begränsningar för att uppnå den optimala prestanda som den här funktionen erbjuder:

Primära nycklar i alla tabeller: Att se till att varje tabell har en primärnyckel är viktigt. Brist på primära nycklar kan avsevärt öka replikeringsfördröjningen och påverka stilleståndstiden.
Låg arbetsbelastning under underhållstider: Underhållsperioder bör sammanfalla med tider med låg arbetsbelastning på servern för att minimera stilleståndstiden. Vi rekommenderar att du använder fönstret för anpassat underhåll för att schemalägga underhåll under låg belastning.
Avbrottsgarantier: Även om vi strävar efter att hålla underhållsavbrotten så låga som möjligt garanterar vi inte att det kommer att vara mindre än 60 sekunder under alla omständigheter. Olika faktorer, till exempel hög arbetsbelastning eller specifika serverkonfigurationer, kan öka stilleståndstiden. I värsta fall kan stilleståndstiden likna en fristående server.

Schemaläggning av underhåll

Funktionen för underhållsomläggning ger dig större kontroll över tidpunkten för underhållsaktiviteter på din flexibla Azure Database for MySQL-server. När du har fått ett meddelande om underhåll kan du schemalägga om det till en mer bekväm tid, oavsett om det var systemhanterat eller hanterat på ett anpassat sätt.

Använd den här funktionen för att undvika störningar under kritiska databasåtgärder. Vi rekommenderar din feedback när vi fortsätter att utveckla den här funktionen.

Schemaläggning av parametrar och meddelanden

Omläggningen är inte begränsad till fasta tidsintervall. Det beror på de tidigaste och senaste tillåtna tiderna i den aktuella underhållscykeln. Cykeln sträcker sig vanligtvis från den första dagen till den sista dagen i underhållsfönstret för regionen. När du schemaläggs om får du ett meddelande för att bekräfta ändringarna enligt standardpolicyerna för meddelanden.

Beaktanden och begränsningar

Tänk på följande punkter om funktionen:

Nivåtillgänglighet: Omplanering av underhåll är inte tillgängligt för Burstable-beräkningsnivån. Den här funktionen är avsedd för servrar i produktionsmiljön, medan nivån Burstable är utformad för icke-produktionsändamål.
Kravbegränsningar: Ditt omplanerade underhåll kan avbrytas om ett stort antal underhållsaktiviteter utförs samtidigt i samma region.
Inlåsningsperiod: Omplanering är inte tillgänglig 15 minuter före den ursprungligen schemalagda underhållstiden för att upprätthålla tjänstens tillförlitlighet.
Omplaneringsbegränsning: Om för många servrar i samma region schemaläggs för underhåll under samma tid kan omläggningsbegäranden misslyckas. Om det här felet inträffar får du ett felmeddelande som råder dig att välja ett alternativt tidsintervall. Underhåll som har schemalagts om kommer sannolikt inte att avbrytas.

Det finns ingen begränsning för hur många gånger en underhållshändelse kan schemaläggas om. Så länge en underhållshändelse inte har angetts i förberedelsetillståndet kan du alltid schemalägga om den till en annan gång.

Kommentar

Vi rekommenderar att du övervakar meddelanden noggrant under förhandsversionsfasen för att hantera potentiella justeringar.

Vanliga frågor

Varför fick vissa av mina servrar underhållsmeddelanden medan andra inte gjorde det?

Starttiderna för underhåll skiljer sig åt mellan olika regioner. Servrar i olika regioner kan få underhållsmeddelanden vid olika tidpunkter.

Varför tog vissa servrar i samma region emot underhållsmeddelanden medan andra inte gjorde det?

Det är möjligt att servrarna som inte tog emot meddelanden har skapats på senare tid och systemet har fastställt att de ännu inte behöver underhåll.

Kan jag avregistrera mig från schemalagt underhåll?

Nej, det är inte tillåtet att välja bort schemalagt underhåll. Du kan dock använda funktionen för underhållsschemaläggning för att justera tidsinställningen. Eller så kan du aktivera funktionen för hög tillgänglighet för att minimera stilleståndstiden. Eftersom Azure Database for MySQL är en paaS-databasprodukt (plattform som en tjänst) hjälper underhåll i tid till att säkerställa säkerheten och tillförlitligheten i databasen.

Dela via