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.

Importante

Evitare tutte le operazioni del server (modifiche, modifiche alla configurazione, avvio/arresto) durante la manutenzione di Database di Azure per MySQL. L'interazione con queste attività può causare 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

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.

Note

Non tutti i server devono necessariamente essere sottoposti a manutenzione durante gli aggiornamenti pianificati, sia routine che critica. 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, sia adatta alle esigenze specifiche di ogni ambiente server e riduce al minimo i tempi di inattività di produzione.

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 del Canary virtuale

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 Canary virtuale.

Registrazione di Canary virtuale

Database di Azure per MySQL offre ai clienti la flessibilità necessaria per gestire la partecipazione al programma Canary virtuale. 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.

Importante

A partire dal 31 agosto 2024, Azure Database per MySQL non supporta più finestre di manutenzione personalizzate per le istanze Burstable-tier. Questa modifica consente di semplificare i processi di manutenzione e garantire prestazioni ottimali. Inoltre, l'analisi ha indicato che il numero di utenti che usano finestre di manutenzione personalizzate nei livelli burstable è minimo.

Le istanze esistenti del livello burstable con finestre di manutenzione personalizzate non sono interessate. Tuttavia, gli utenti non possono più modificare queste impostazioni per le finestre di manutenzione personalizzate.

Per i clienti che necessitano di finestre di manutenzione personalizzate, è consigliabile eseguire l'aggiornamento al livello Utilizzo generico o Business Critical.

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.

Stato della manutenzione

Per i singoli server, è possibile visualizzare lo stato di manutenzione nel pannello manutenzione di Azure MySQL nel portale di Azure. Lo stato di manutenzione indica se la manutenzione è pianificata, in corso, completata o annullata.

Per i clienti che gestiscono più server flessibili di Database di Azure per MySQL, è possibile usare Azure Resource Graph per eseguire query in blocco tra sottoscrizioni e gruppi di risorse. Ciò è particolarmente utile per controllare la cronologia di manutenzione, identificare le risorse interessate e tenere traccia degli eventi di manutenzione nel tempo. Di seguito è riportata la query Kusto che recupera lo stato di manutenzione, l'ora di inizio e di fine e l'ID di rilevamento per tutti i server flessibili MySQL nella sottoscrizione del cliente. Ciò consente ai clienti di monitorare le attività di manutenzione negli ultimi tre mesi in modo scalabile e automatizzato:


ServiceHealthResources
| where type == "microsoft.resourcehealth/events/impactedresources"
| extend TrackingId = split(split(id, "/events/", 1)[0], "/impactedResources", 0)[0]
| extend p = parse_json(properties)
| project subscriptionId, TrackingId, resourceName= p.resourceName, resourceGroup=p.resourceGroup, resourceType=p.targetResourceType, status= p.status, maintenanceStartTime=todatetime(p.maintenanceStartTime),  maintenanceEndTime=todatetime( p.maintenanceEndTime), details = p, id
| where resourceType == "Microsoft.DBforMySQL/flexibleServers" 
| order by maintenanceEndTime

È anche possibile passare alla scheda Risorse interessate di Integrità dei servizi di Azure per visualizzare lo stato di manutenzione per tutte le risorse di Azure, inclusi i server flessibili di Database di Azure per MySQL. Si noti che lo stato di manutenzione visualizzato in Integrità dei servizi di Azure rappresenta lo stato complessivo dell'evento di manutenzione a livello di area e potrebbe non riflettere lo stato dei singoli server.

Manutenzione del tempo di inattività quasi nullo

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.

Condizioni e limitazioni

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

Durata del tempo di inattività: nella maggior parte dei casi, il tempo di inattività durante la manutenzione varia da 10 a 30 secondi.
Chiavi primarie in tutte le tabelle: garantire che ogni tabella disponga di una chiave primaria sia fondamentale. L'assenza di chiavi primarie può aumentare significativamente i ritardi nella replica e influire sul tempo 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 limiti

Tenere presenti i punti seguenti relativi alla funzionalità:

Disponibilità del livello: la riprogrammazione della manutenzione non è disponibile per il livello di calcolo con possibilità di 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 geografica 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.

Note

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

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.

Commenti e suggerimenti

Questa pagina è stata utile?

Last updated on 2025-10-10