Manutenzione pianificata in Database di Azure per MySQL

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

Ciclo di manutenzione

Le sezioni seguenti descrivono i tipi 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, in modo da poter comprendere e preparare eventuali modifiche che influiscono sull'ambiente.

Manutenzione di routine

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

Manutenzione critica

In alcuni scenari, ad esempio la necessità di distribuire aggiornamenti o correzioni di sicurezza urgenti fondamentali per mantenere la disponibilità e l'integrità dei dati, è possibile eseguire la manutenzione più frequentemente. Queste eccezioni consentono di proteggere i dati e garantire il funzionamento continuo dei servizi.

Manutenzione Virtual Canary (anteprima)

Virtual Canary è un programma di manutenzione sperimentale che offre l'accesso anticipato agli aggiornamenti. Consente ai clienti di testare la compatibilità dei carichi di lavoro con le nuove versioni di Database di Azure per MySQL e fornire commenti e suggerimenti sulle nuove funzionalità.

A differenza della manutenzione di routine, Virtual Canary non segue il divario minimo di 30 giorni o il periodo di notifica di 7 giorni. Questo programma consente ai clienti di convalidare in modo proattivo le nuove funzionalità e contribuire in anticipo ai miglioramenti del prodotto. I server di livello burst, comunemente usati per ambienti non di produzione, vengono registrati automaticamente nel programma di prova Canary virtuale.

Registrazione Canary virtuale

Database di Azure per MySQL offre ai clienti la flessibilità necessaria per gestire la partecipazione al programma Virtual Canary. I clienti possono acconsentire esplicitamente o rifiutare il programma in base alle esigenze per l'allineamento ai requisiti operativi.

Per verificare se il server è registrato nel programma Canary virtuale, usare il comando seguente. Se il risultato include "patchStrategy": "VirtualCanary", il server viene registrato nel programma.

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

Per registrare un server nel programma Canary virtuale, eseguire il comando seguente:

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

Per lasciare il programma Canary virtuale e ripristinare i criteri di manutenzione standard, usare questo comando:

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

Finestre 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 sette giorni prima che esegua qualsiasi manutenzione. Il sistema ti informa anche quando inizia la manutenzione e quando si conclude con successo.

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.
• Inviato in un SMS ai dispositivi mobili.
• Inviate tramite push di notifica a un'app di Azure.
• Inviate tramite messaggio vocale.

Quando si specificano le preferenze per la pianificazione della manutenzione, è possibile scegliere un giorno della settimana e un intervallo di tempo. Se non si specificano le preferenze, il sistema sceglie le ore tra le 11.00 e le 7.00 nell'ora geografica 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 la manutenzione è pianificata per il server flessibile e si aggiornano le preferenze di pianificazione, l'implementazione corrente procede come pianificato. La modifica alle impostazioni di pianificazione diventa effettiva dopo il completamento corretto della manutenzione programmata successiva.

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

• Con una pianificazione personalizzata, è possibile specificare la finestra di manutenzione per il server scegliendo il giorno della settimana e un intervallo di un'ora.
• Con una pianificazione gestita dal sistema, il sistema seleziona qualsiasi finestra di un'ora tra le 11.00 e le 7.00 nell'ora geografica del server.

In rari casi, un evento di manutenzione può essere annullato dal sistema o potrebbe non riuscire a completare correttamente. Se un evento di manutenzione ha esito negativo, l'aggiornamento viene ripristinato e viene ripristinata la versione precedente dei file binari. Negli scenari di aggiornamenti non riusciti, è comunque possibile che si verifichi un riavvio del server durante la finestra di manutenzione.

Se un evento di manutenzione viene annullato o ha esito negativo, il sistema invia una notifica. Il tentativo successivo di eseguire la manutenzione è pianificato in base alle impostazioni correnti. Si riceve una notifica relativa al tentativo successivo di cinque giorni in anticipo.

Manutenzione con quasi zero interruzioni (anteprima)

La funzionalità di manutenzione con tempo di inattività quasi nullo offerta dal Database di Azure per MySQL rappresenta uno sviluppo rivoluzionario per i server con alta disponibilità. Questa funzionalità è progettata per ridurre notevolmente i tempi di inattività di manutenzione. Questa funzionalità è fondamentale per le aziende che richiedono disponibilità elevata e interruzioni minime nelle operazioni del database.

Precise aspettative di tempo di inattività

• Durata del 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 di durata (TTL) DNS intrinseco 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.

Condizioni e limitazioni

Per ottenere prestazioni ottimali offerte da questa funzionalità, tenere presente queste condizioni e limitazioni:

• Chiavi primarie in tutte le tabelle: garantire che ogni tabella disponga di una chiave primaria sia fondamentale. La mancanza di chiavi primarie può aumentare significativamente i ritardi nella replica e influire sul periodo di inattività.
• Carico di lavoro ridotto durante i tempi di manutenzione: i periodi di manutenzione devono coincidere con i tempi di basso carico di lavoro nel server per ridurre al minimo i tempi di inattività. È consigliabile usare la finestra di manutenzione personalizzata per pianificare la manutenzione durante le ore di minore attività.
• Garanzie di tempo di inattività: anche se ci impegniamo a mantenere il tempo di inattività di manutenzione il più basso possibile, non è garantito che sia inferiore a 60 secondi in tutte le circostanze. Vari fattori, ad esempio carichi di lavoro elevati o configurazioni server specifiche, possono aumentare il tempo di inattività. Nello scenario peggiore, il tempo di inattività potrebbe essere simile a quello di un server autonomo.

Riprogrammazione della manutenzione

La funzionalità di riprogrammazione della manutenzione offre un maggiore controllo sulle tempistiche delle attività di manutenzione nel server flessibile di Database di Azure per MySQL. Dopo aver ricevuto una notifica di manutenzione, è possibile riprogrammarla in modo più pratico, indipendentemente dal fatto che fosse gestita dal sistema o gestita personalizzata.

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

Riprogrammazione di parametri e notifiche

La riprogrammazione non è limitata alle fasce orarie fisse. Dipende dai tempi più recenti consentiti nel ciclo di manutenzione corrente. Il ciclo si estende in genere dal primo giorno all'ultimo giorno della finestra di manutenzione per l'area. Quando si riprogramma, si riceve una notifica per confermare le modifiche, in base ai criteri di notifica standard.

Considerazioni e limitazioni

Tenere presenti i punti seguenti relativi alla funzionalità:

• Disponibilità del livello: la riprogrammazione della manutenzione non è disponibile per il livello di calcolo con burst. Questa funzionalità è destinata ai server nell'ambiente di produzione, mentre il livello burstable è progettato per scopi non di produzione.
• Vincoli di domanda: la manutenzione programmata potrebbe essere annullata se si verificano contemporaneamente un numero elevato di attività di manutenzione nella stessa area.
• Periodo di blocco: la riprogrammazione non è disponibile 15 minuti prima del tempo di manutenzione pianificato inizialmente, per mantenere l'affidabilità del servizio.
• Limitazione della riprogrammazione: se troppi server nella stessa area sono pianificati per la manutenzione durante lo stesso periodo, la riprogrammazione delle richieste potrebbe non riuscire. Se si verifica questo errore, viene visualizzata una notifica di errore che consiglia di scegliere un intervallo di tempo alternativo. È improbabile che la manutenzione pianificata venga annullata correttamente.

Non esiste alcuna limitazione sul numero di volte in cui un evento di manutenzione può essere riprogrammato. Finché un evento di manutenzione non è entrato nello stato di preparazione , è sempre possibile riprogrammarlo in un'altra volta.

Domande frequenti

Perché alcuni server hanno ricevuto notifiche di manutenzione mentre altre no?

Le ore di inizio della manutenzione variano in diverse aree. I server in aree diverse potrebbero ricevere notifiche di manutenzione in momenti diversi.

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

È possibile che i server che non hanno ricevuto le notifiche siano stati creati più di recente e che il sistema abbia stabilito che non hanno ancora bisogno di manutenzione.

È possibile rifiutare esplicitamente la manutenzione pianificata?

No, non è consentito rifiutare esplicitamente la manutenzione pianificata. Tuttavia, è possibile usare la funzionalità di riprogrammazione della manutenzione per regolare la tempistica. In alternativa, è possibile abilitare la funzionalità a disponibilità elevata per ridurre al minimo i tempi di inattività. Poiché Database di Azure per MySQL è un prodotto di database PaaS (Platform as a Service), l'esecuzione di una manutenzione tempestiva consente di garantire la sicurezza e l'affidabilità del database.

Contenuto correlato

• Modificare la pianificazione della manutenzione
• Ricevere notifiche sulla manutenzione imminente
• Configurare gli avvisi relativi ai prossimi eventi di manutenzione pianificata