Condividi tramite

Manutenzione pianificata in Database di Azure per MySQL - Server flessibile

  • Articolo

Il server flessibile di Database di Azure per MySQL esegue la manutenzione periodica per mantenere il database gestito sicuro, stabile e aggiornato. Durante la manutenzione, il server ottiene nuove funzionalità, aggiornamenti e patch.

Importante

Evitare tutte le operazioni del server (modifiche, modifiche alla configurazione, avvio/arresto del server) durante la manutenzione del server flessibile di Database di Azure per MySQL. L'impegno in queste attività può portare a risultati imprevedibili, che potrebbero influire sulle prestazioni e sulla stabilità del server. Attendere il completamento della manutenzione prima di eseguire operazioni del server.

Ciclo di manutenzione

Manutenzione di routine

Il nostro ciclo di manutenzione standard non è pianificato meno frequentemente di ogni 30 giorni. Questo periodo consente di garantire stabilità e prestazioni del sistema riducendo al minimo le interruzioni dei servizi.

Manutenzione critica

In alcuni scenari, ad esempio la necessità di distribuire correzioni di sicurezza urgenti o aggiornamenti critici per mantenere la disponibilità e l'integrità dei dati, la manutenzione potrebbe essere eseguita più frequentemente. Queste eccezioni vengono effettuate per proteggere i dati e garantire il funzionamento continuo dei servizi.

Individuare i dettagli di manutenzione

Per informazioni specifiche su ciò che comporta ogni aggiornamento di manutenzione, vedere le note sulla versione. Queste note forniscono informazioni complete sugli aggiornamenti applicati durante la manutenzione, consentendo di comprendere e preparare eventuali modifiche che interessano l'ambiente.

Nota

Non tutti i server verranno necessariamente sottoposti a manutenzione durante gli aggiornamenti pianificati, sia routine che critici. Il team di Azure MySQL usa criteri specifici per determinare quali server richiedono manutenzione. Questo approccio selettivo garantisce che la manutenzione sia efficiente e essenziale, adattata alle esigenze specifiche di ogni ambiente server e ridurre al minimo i tempi di inattività della produzione.

Selezionare una finestra di manutenzione

È possibile pianificare la manutenzione durante un giorno specifico della settimana e in un intervallo di tempo all'interno di tale giorno. In alternativa, è possibile consentire al sistema di scegliere automaticamente un giorno e un intervallo di tempo. In entrambi i casi, il sistema avvisa l'utente sette giorni prima dell'esecuzione di qualsiasi manutenzione. Il sistema inoltre invierà informazioni all'avvio della manutenzione e al termine dell'operazione.

Le notifiche relative alla manutenzione pianificata imminente possono essere:

  • Inviate via e-mail a un indirizzo specifico
  • Inviate via e-mail al ruolo di Azure Resource Manager
  • Inviate con SMS a un dispositivo mobile
  • un push di notifica a un'app di Azure
  • un messaggio vocale

Quando si specificano le preferenze per il programma di manutenzione, è possibile scegliere un giorno della settimana e un intervallo di tempo. Se non lo si fa, il sistema sceglierà un'ora tra le 23:00 e le 07:00 nell'ora dell'area del server. È possibile definire programmi differenti per ogni server flessibile nella sottoscrizione di Azure.

Le impostazioni di pianificazione possono essere aggiornate in qualsiasi momento. Se è prevista una manutenzione pianificata per il server flessibile e si aggiornano le preferenze di pianificazione, l'implementazione corrente procederà come pianificato e la modifica delle impostazioni di pianificazione diventerà effettiva al completamento corretto per la manutenzione pianificata successiva.

È possibile definire una pianificazione gestita dal sistema o una pianificazione personalizzata per ogni server flessibile nella sottoscrizione di Azure.

  • Con la pianificazione personalizzata, è possibile specificare la finestra di manutenzione per il server scegliendo il giorno della settimana e un intervallo di tempo di un'ora.
  • Con la pianificazione gestita dal sistema, il sistema sceglierà qualsiasi finestra di un'ora tra le 11:00 e le 7:00 nell'ora geografica del server.

Importante

A partire dal 31 agosto 2024, Database di Azure per MySQL non supporterà più finestre di manutenzione personalizzate per le istanze di SKU con possibilità di burst. Questa modifica è dovuta alla necessità di semplificare i processi di manutenzione, garantire prestazioni ottimali e alla nostra analisi che indica che il numero di utenti che usano finestre di manutenzione personalizzate su SKU con possibilità di burst è minimo. Le istanze di SKU con possibilità di burst esistenti con configurazioni personalizzate della finestra di manutenzione rimarranno invariate; tuttavia, gli utenti non potranno modificare queste impostazioni personalizzate della finestra di manutenzione in futuro.

Per i clienti che richiedono finestre di manutenzione personalizzate, è consigliabile eseguire l'aggiornamento a SKU per utilizzo generico o business critical per continuare a usare questa funzionalità.

In rari casi, l'evento di manutenzione può essere annullato dal sistema o potrebbe non riuscire a completare correttamente. Se l'aggiornamento non riesce, l'aggiornamento viene ripristinato e viene ripristinata la versione precedente dei file binari. In questi scenari di aggiornamento non riusciti, è comunque possibile che si verifichi il riavvio del server durante la finestra di manutenzione. Se l'aggiornamento viene annullato o non riuscito, il sistema creerà una notifica relativa all'evento di manutenzione annullata o non riuscita notificando l'utente. Il prossimo tentativo di eseguire la manutenzione verrà pianificato in base alle impostazioni di pianificazione correnti e si riceverà una notifica su di esso 5 giorni in anticipo.

Manutenzione quasi zero tempo di inattività (anteprima pubblica)

La funzionalità "Manutenzione tempo di inattività quasi zero" del server flessibile di Database di Azure per MySQL è uno sviluppo innovativo per i server abilitati perla disponibilità elevata (disponibilità elevata). Questa funzionalità è progettata per ridurre notevolmente i tempi di inattività di manutenzione, assicurandosi che nella maggior parte dei casi il tempo di inattività della manutenzione sia compreso tra 40 e 60 secondi. Questa funzionalità è fondamentale per le aziende che richiedono disponibilità elevata e interruzioni minime nelle operazioni del database.

Precise aspettative di tempo di inattività

  • Durata tempo di inattività: nella maggior parte dei casi, il tempo di inattività durante la manutenzione varia da 10 a 30 secondi.
  • Considerazioni aggiuntive: dopo un evento di failover, è previsto un periodo TTL (Time-To-Live) DNS di circa 30 secondi. Questo periodo non è controllato direttamente dal processo di manutenzione, ma è una parte standard del comportamento DNS. Quindi, dal punto di vista di un cliente, il tempo di inattività totale riscontrato durante la manutenzione potrebbe essere compreso tra 40 e 60 secondi.

Limitazioni e prerequisiti

Per ottenere prestazioni ottimali promesse da questa funzionalità, è necessario tenere presente alcune condizioni e limitazioni:

  • Chiavi primarie in tutte le tabelle: garantire che ogni tabella abbia una chiave primaria sia fondamentale. La mancanza di chiavi primarie può aumentare significativamente il ritardo della replica, influenzando il tempo di inattività.
  • Basso carico di lavoro durante i tempi di manutenzione: i periodi di manutenzione devono coincidere con i tempi di basso carico di lavoro nel server per garantire che il tempo di inattività rimanga minimo. È consigliabile usare la funzionalità Finestra di manutenzione personalizzata per pianificare la manutenzione durante le ore di minore attività.
  • Garanzie di tempo di inattività: mentre ci impegniamo a mantenere il tempo di inattività di manutenzione il più basso possibile, non garantiamo che sia sempre inferiore a 60 secondi in tutte le circostanze. Diversi fattori, ad esempio carichi di lavoro elevati o configurazioni server specifiche, possono causare tempi di inattività più lunghi. Nello scenario peggiore, il tempo di inattività potrebbe essere simile a quello di un server autonomo.

Ripianificazione della manutenzione:

La funzionalità Riprogrammazione della manutenzione garantisce un maggiore controllo sulla tempistica delle attività di manutenzione nell'istanza del server flessibile di Database di Azure per MySQL. Dopo aver ricevuto una notifica di manutenzione, è possibile riprogrammarla in un momento più conveniente, indipendentemente dal fatto che fosse gestito dal sistema o personalizzato.

Riprogrammare parametri e notifiche

La riprogrammazione non è limitata alle fasce orarie fisse; dipende dai tempi più recenti consentiti nel ciclo di manutenzione corrente, che in genere va dal primo all'ultimo giorno della finestra di manutenzione per l’area. Dopo la riprogrammazione, verrà inviata una notifica per confermare le modifiche, seguendo i criteri di notifica standard.

Considerazioni e limitazioni

Quando si usa questa funzionalità, tenere presente quanto segue:

  • Vincoli di domanda: la manutenzione programmata potrebbe essere annullata a causa di un numero elevato di attività di manutenzione che si verificano simultaneamente nella stessa area.
  • Periodo di blocco: la riprogrammazione non è disponibile 15 minuti prima del tempo di manutenzione inizialmente pianificato per mantenere l'affidabilità del servizio.
  • Riprogrammare la limitazione se troppi server nella stessa area sono pianificati per la manutenzione durante lo stesso tempo, le richieste di riprogrammazione potrebbero non riuscire. Gli utenti riceveranno una notifica di errore se ciò si verifica e si consiglia di scegliere una fascia oraria alternativa. È improbabile che la manutenzione pianificata venga annullata correttamente.

Non esiste alcuna limitazione sul numero di volte in cui una manutenzione può essere riprogrammata, purché la manutenzione non sia entrata nello stato "In preparazione", è sempre possibile riprogrammare la manutenzione in un altro momento.

Nota

È consigliabile monitorare attentamente le notifiche durante la fase di anteprima per supportare potenziali modifiche.

Usare questa funzionalità per evitare interruzioni durante le operazioni critiche del database. È consigliabile inviare commenti e suggerimenti man mano che si continua a sviluppare questa funzionalità.

Domande frequenti

D: Perché alcuni dei server hanno ricevuto notifiche di manutenzione mentre altri no?

R: Gli orari di inizio della manutenzione variano in diverse aree, quindi i server in aree diverse potrebbero ricevere notifiche di manutenzione in momenti diversi.

D: Perché alcuni server nella stessa area hanno ricevuto notifiche di manutenzione mentre altri no?

R: Ciò potrebbe essere dovuto al fatto che i server che non hanno ricevuto notifiche sono stati creati più di recente e il sistema ha determinato che non richiedono ancora manutenzione.

D: È possibile rifiutare esplicitamente la manutenzione pianificata?

R: No, rifiutare esplicitamente la manutenzione pianificata non è consentito. È tuttavia possibile usare la funzionalità di riprogrammazione della manutenzione per regolare la tempistica o abilitare la funzionalità Disponibilità elevata per ridurre al minimo i tempi di inattività. Come prodotto di database PaaS, è essenziale eseguire una manutenzione tempestiva per garantire la sicurezza e l'affidabilità del database.

Contenuto correlato