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 azure database for MySQL– flexibelt serverunderhåll. 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.

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.

Viktigt!

Vanligtvis är tiden mellan schemalagda underhållshändelser för en server minst 30 dagar.

I händelse av en kritisk nödsituationsuppdatering, till exempel en allvarlig säkerhetsrisk, kan dock meddelandefönstret vara kortare än sju dagar. Den kritiska uppdateringen kan tillämpas på servern även om ett lyckat schemalagt underhåll har utförts under de senaste 30 dagarna.

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!

Tidigare behölls ett 7-dagars distributionsgap mellan systemhanterade och anpassade hanterade scheman. På grund av de växande underhållskraven och införandet av underhållsomläggningsfunktionen (offentlig förhandsversion) kan vi inte längre garantera denna 7-dagars lucka.

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.

Omplanerat underhåll (offentlig förhandsversion)

Viktigt!

Underhållsomläggningsfunktionen är för närvarande i förhandsversion. Det är föremål för begränsningar och pågående utveckling. Vi värdesätter din feedback för att förbättra den här funktionen. Observera att den här funktionen inte är tillgänglig för servrar som använder den burstbara SKU:n.

Funktionen för underhållsomläggning ger dig större kontroll över tidpunkten för underhållsaktiviteter på din flexibla Azure Database for MySQL-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. 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.

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.

Nästa steg