Dela via

Schemalagt underhåll i Azure Database for MySQL – flexibel server

  • Artikel

GÄLLER FÖR: Azure Database for MySQL – flexibel server

Azure Database for MySQL – flexibel server utför regelbundet underhåll för att hålla den hanterade databasen 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/stoppserver) under underhåll av Azure Database for MySQL – flexibel server. Att delta i dessa aktiviteter kan leda till oförutsägbara resultat, vilket kan påverka serverns prestanda och stabilitet. Vänta tills underhållet avslutas innan du utför serveråtgärder.

Underhållscykel

Rutinunderhåll

Vår standardunderhållscykel schemaläggs inte mindre ofta än var 30:e dag. Med den här perioden kan vi säkerställa systemstabilitet och prestanda samtidigt som du minimerar avbrott i dina tjänster.

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 underhåll utföras oftare. Dessa undantag görs för att skydda dina data och säkerställa kontinuerlig drift av dina tjänster.

Hitta underhållsinformation

Mer information om vad varje underhållsuppdatering innebär finns i vår viktig information. 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 kommer inte nödvändigtvis att genomgå underhåll 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äddarsytt efter de unika behoven i varje servermiljö och minimerar driftstoppen för din produktion.

Välj ett underhållsperiod

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 en tidsperiod för dig automatiskt. Oavsett vilket aviserar systemet dig sju dagar innan underhåll körs. Systemet meddelar dig också när underhåll startas 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
  • Som en push-avisering till en Azure-app
  • Som ett röstmeddelande

När du anger inställningar för underhållsschemat kan du välja en veckodag och en tidsperiod. Om du inte anger detta väljer systemet tider mellan 23:00 och 07:00 (i serverns tidszon). 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 ett underhåll har schemalagts för den flexibla servern och du uppdaterar schemaläggningsinställningarna fortsätter den aktuella distributionen som schemalagd och ändringen av schemaläggningsinställningarna träder i kraft när den har slutförts för nästa schemalagda underhåll.

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

  • Med anpassat schema kan du ange underhållsfönstret för servern genom att välja veckodag och en tidsperiod på en timme.
  • Med systemhanterat schema väljer systemet valfritt 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 burstbara SKU-instanser. Den här ändringen beror på behovet av att förenkla underhållsprocesser, säkerställa optimala prestanda och vår analys som anger att antalet användare som använder anpassade underhållsperioder på burstbara SKU:er är minimalt. Befintliga SKU-instanser med anpassade underhållsfönsterkonfigurationer påverkas inte. Användarna kommer dock inte att kunna ändra inställningarna för de anpassade underhållsperioderna framöver.

För kunder som behöver anpassade underhållsfönster rekommenderar vi att du uppgraderar till Generell användning eller Affärskritisk SKU:er för att fortsätta använda den här funktionen.

I sällsynta fall kan underhållshändelsen avbrytas av systemet eller misslyckas med att slutföras. Om uppdateringen misslyckas återställs uppdateringen och den tidigare versionen av binärfilerna återställs. I sådana misslyckade uppdateringsscenarier kan det hända att servern fortfarande startas om under underhållsfönstret. Om uppdateringen avbryts eller misslyckas skapar systemet ett meddelande om avbruten eller misslyckad underhållshändelse som meddelar dig. Nästa försök att utföra underhåll schemaläggs enligt dina aktuella schemaläggningsinställningar och du får ett meddelande om det 5 dagar i förväg.

Nära noll driftstopp (allmänt tillgänglig förhandsversion)

Azure Database for MySQL – flexibel server med funktionen "Nära noll driftstoppsunderhåll" är en banbrytande utveckling för SERVRAR med hög tillgänglighet (HÖG tillgänglighet). Den här funktionen är utformad för att avsevärt minska underhållsavbrotten, vilket säkerställer att underhållsavbrott i de flesta fall förväntas vara mellan 40 och 60 sekunder. 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 inom intervallet 40 till 60 sekunder.

Begränsningar och förutsättningar

För att uppnå den optimala prestanda som utlovas av den här funktionen bör vissa villkor och begränsningar noteras:

  • 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, vilket påverkar stilleståndstiden.
  • Låg arbetsbelastning under underhållstider: Underhållsperioder bör sammanfalla med tider med låg arbetsbelastning på servern för att säkerställa att stilleståndstiden förblir minimal. Vi rekommenderar att du använder funktionen för anpassat underhållsperiod för att schemalägga underhåll under låg belastning.
  • Avbrottsgarantier: Vi strävar efter att hålla underhållsavbrotten så låga som möjligt, men vi garanterar inte att det alltid kommer att vara mindre än 60 sekunder under alla omständigheter. Olika faktorer, till exempel hög arbetsbelastning eller specifika serverkonfigurationer, kan leda till längre stilleståndstid. I värsta fall kan stilleståndstiden likna en fristående server.

Omplanerat underhåll

Funktionen underhållsomläggning ger dig större kontroll över tidpunkten för underhållsaktiviteter på din Azure Database for MySQL – flexibel serverinstans. När du har fått ett underhållsmeddelande kan du schemalägga om det till en mer bekväm tid, oavsett om det var system eller anpassad hanterad.

Schemalägg om parametrar och meddelanden

Omläggningen är inte begränsad till fasta tidsluckor. Det beror på de tidigaste och senaste tillåtna tiderna i den aktuella underhållscykeln, som vanligtvis sträcker sig från den första till den sista dagen i underhållsperioden för regionen. När du har schemalagt om skickas ett meddelande ut för att bekräfta ändringarna enligt standardpolicyerna för meddelanden.

Beaktanden och begränsningar

Tänk på följande när du använder den här funktionen:

  • Kravbegränsningar: Ditt omplanerade underhåll kan avbrytas på grund av ett stort antal underhållsaktiviteter som inträffar samtidigt i samma region.
  • Inlåsningsperiod: Omläggning är inte tillgänglig 15 minuter före den ursprungligen schemalagda underhållstiden för att upprätthålla tjänstens tillförlitlighet.
  • Schemalägg om begränsning Om för många servrar i samma region är schemalagda för underhåll under samma tid kan omläggningsbegäranden misslyckas. Användarna får ett felmeddelande om detta inträffar och uppmanas 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 ett underhåll kan schemaläggas om, så länge som underhållet inte har angetts i tillståndet "Förberedelse" kan du alltid schemalägga om ditt underhåll till en annan tid.

Kommentar

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

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.

Vanliga frågor

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

S: Starttiderna för underhåll skiljer sig åt mellan regioner, så servrar i olika regioner kan få underhållsmeddelanden vid olika tidpunkter.

F: Varför fick vissa servrar i samma region underhållsmeddelanden medan andra inte gjorde det?

S: Detta kan bero på att servrarna som inte tog emot meddelanden har skapats på senare tid och systemet har fastställt att de ännu inte kräver underhåll.

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

S: Nej, det är inte tillåtet att avregistrera sig från schemalagt underhåll. Du kan dock använda funktionen för underhållsomläggning för att justera tidsinställningen eller aktivera funktionen hög tillgänglighet (HA) för att minimera stilleståndstiden. Som En PaaS-databasprodukt är det viktigt att utföra underhåll i tid för att säkerställa säkerheten och tillförlitligheten i databasen.

Nästa steg