Aggiornamento della versione principale in Database di Azure per MySQL

Note

Questo articolo contiene riferimenti al termine slave, che Microsoft non usa più. Quando il termine verrà rimosso dal software, verrà rimosso anche dall'articolo.

Questo articolo descrive come aggiornare sul posto la versione principale di MySQL nel server flessibile di Database di Azure per MySQL. Questa funzionalità consente ai clienti di eseguire aggiornamenti delle versioni principali (ad esempio, da MySQL 5.7 a 8.0 o 8.0 a 8.4) senza spostare dati o modificare le stringhe di connessione dell'applicazione.

Importante

La durata del tempo di inattività varia in base alle dimensioni dell'istanza di database e al numero di tabelle contenute.
Quando si avvia un aggiornamento della versione principale per il server flessibile di Database di Azure per MySQL tramite l'API REST o l'SDK, evitare di modificare altre proprietà del servizio nella stessa richiesta. Le modifiche simultanee non sono consentite e possono causare risultati imprevisti o errori di richiesta. Eseguire modifiche alle proprietà in operazioni separate dopo il completamento dell'aggiornamento.
Alcuni carichi di lavoro potrebbero non presentare prestazioni migliorate dopo un aggiornamento della versione principale. È consigliabile valutare le prestazioni del carico di lavoro creando prima un server di replica (come server di test), quindi promuovendolo in un server autonomo e quindi eseguendo il carico di lavoro nel server di test prima di implementare l'aggiornamento in un ambiente di produzione.
L'aggiornamento della versione principale di MySQL è irreversibile. La distribuzione potrebbe non riuscire se la convalida rileva che il server è configurato con funzionalità rimosse o deprecate nella versione di destinazione. È possibile apportare le modifiche di configurazione necessarie nel server e riprovare a eseguire l'aggiornamento.

Prerequisiti

Le repliche in lettura con una versione precedente di MySQL devono essere aggiornate prima del server primario per la compatibilità della replica tra versioni di MySQL diverse. Altre informazioni sulla compatibilità della replica tra le versioni di MySQL.
Prima di aggiornare i server di produzione, è ora più semplice ed efficiente farlo con la funzionalità predefinita Convalida nel portale di Azure. Questo strumento controlla in modo preliminare la compatibilità dello schema del database con la versione di MySQL di destinazione, evidenziando potenziali problemi. Anche se è disponibile questa opzione pratica, è consigliabile usare lo strumento ufficiale di controllo dell'aggiornamento di Oracle MySQL per testare la compatibilità dello schema di database ed eseguire il test di regressione necessario per verificare la compatibilità delle applicazioni con le funzionalità rimosse/deprecate nella nuova versione di MySQL.
Attivare il backup su richiesta prima di eseguire un aggiornamento della versione principale nel server di produzione. I backup eseguiti prima dell'aggiornamento possono essere usati per eseguire il rollback alla versione precedente dal backup completo su richiesta.
Prima di procedere con l'aggiornamento della versione principale, assicurarsi che nel database non siano presenti transazioni XA attive o in sospeso, perché le transazioni XA in corso possono causare un errore del processo di aggiornamento. Prima di tutto, per evitare questo problema, verificare la presenza di transazioni XA nello stato "preparato" eseguendo XA RECOVER;. Per tutte le transazioni identificate, usare XA ROLLBACK '{xid}'; per eseguire il rollback di ogni transazione, sostituendo {xid} con l'ID transazione. Assicurarsi che venga eseguito il commit o il rollback di tutte le transazioni XA prima di avviare l'aggiornamento per mantenere la coerenza delle transazioni e ridurre il rischio di errori di aggiornamento.

Note

Quando si usa lo strumento ufficiale di Oracle per verificare la compatibilità dello schema, è possibile che vengano visualizzati alcuni avvisi che indicano token imprevisti nelle stored procedure, ad esempio:

mysql.az_replication_change_master - at line 3,4255: unexpected token 'REPLICATION'

mysql.az_add_action_history - PROCEDURE uses obsolete NO_AUTO_CREATE_USER sql_mode

È possibile ignorare questi avvisi in modo sicuro. Fanno riferimento a stored procedure predefinite precedute da mysql., che vengono usate per supportare le funzionalità di Azure MySQL. Questi avvisi non influiscono sulla funzionalità del database.

Eseguire un aggiornamento pianificato della versione principale usando il portale di Azure per i server SKU con possibilità di burst

L'esecuzione di un aggiornamento della versione principale per un livello di calcolo dell'SKU con possibilità di burst di Database di Azure per MySQL richiede un flusso di lavoro specializzato. Gli aggiornamenti delle versioni principali sono a elevato utilizzo di risorse, richiedendo CPU e memoria significative. Le istanze dello SKU con possibilità di burst, basate sul credito, potrebbero avere difficoltà in questi requisiti, causando potenzialmente l'esito negativo del processo di aggiornamento. Pertanto, quando si aggiorna un SKU con possibilità di burst, il sistema aggiorna prima il livello di calcolo a un SKU per utilizzo generico per garantire che siano disponibili risorse sufficienti per l'aggiornamento.

Per eseguire un aggiornamento della versione principale per un livello di calcolo dell'SKU con possibilità di burst di Database di Azure per MySQL tramite il portale di Azure, seguire questa procedura:

Nel portale di Azure selezionare l'istanza del server flessibile di Database di Azure per MySQL esistente.

Importante

Anziché aggiornare direttamente l'ambiente di produzione, è consigliabile aggiornare prima la copia ripristinata del server. Vedere come eseguire il ripristino temporizzato.
Nella pagina Panoramica selezionare Aggiorna nella barra degli strumenti.

Importante

Prima dell'aggiornamento, visitare il collegamento per l'elenco delle funzionalità rimosse nella versione mySQL di destinazione. Verificare i valori deprecati sql_mode e rimuoverli o deselezionarli dal server flessibile di Database di Azure per MySQL corrente usando il pannello Parametri del server nel portale di Azure per evitare errori di distribuzione. sql_mode con i valori NO_AUTO_CREATE_USER, NO_FIELD_OPTIONS, NO_KEY_OPTIONS e NO_TABLE_OPTIONS non è più supportata in MySQL 8.0 e versioni successive.
Convalida della compatibilità dello schema

Prima di procedere con l'aggiornamento, eseguire lo strumento ufficiale di verifica dell'aggiornamento di MySQL di Oracle per verificare che lo schema del database corrente sia compatibile con la versione mySQL di destinazione. Questo passaggio è fondamentale per garantire un processo di aggiornamento uniforme.
Decisione pre-aggiornamento

Prima dell'aggiornamento, è necessario scegliere il livello di calcolo da aggiornare per eseguire l'aggiornamento della versione principale. Per impostazione predefinita, il sistema esegue l'aggiornamento dallo SKU con possibilità di burst allo SKU per utilizzo generico più semplice, ma è possibile eseguire l'aggiornamento a un livello di calcolo superiore, se necessario. Mentre il server opera nel livello "Utilizzo generico" durante l'aggiornamento, vengono addebitati solo i costi per le risorse "Utilizzo generico" effettive usate durante questo periodo.
Decisione post-aggiornamento

Decidere se conservare lo SKU per utilizzo generico o ripristinare lo SKU con possibilità di burst dopo l'aggiornamento. Questa scelta viene richiesta durante i passaggi di aggiornamento iniziali.

Il sistema aggiornerà automaticamente il livello di calcolo dallo SKU con possibilità di burst allo SKU per utilizzo generico selezionato che supporta l'aggiornamento della versione principale.
Aggiornamento versione principale

Dopo l'aggiornamento del livello di calcolo, il sistema avvia il processo di aggiornamento della versione principale. Monitorare lo stato di avanzamento dell'aggiornamento tramite il portale di Azure. Il processo di aggiornamento potrebbe richiedere del tempo a seconda delle dimensioni e dell'attività del database. Si noti che se l'aggiornamento della versione principale non riesce, il livello di calcolo non verrà ripristinato automaticamente allo SKU con possibilità di burst precedente. Ciò consente ai clienti di continuare l'aggiornamento della versione principale senza eseguire di nuovo l'aggiornamento del livello di calcolo.
Reversione automatica

In base alla decisione di pre-aggiornamento, il sistema mantiene lo SKU per utilizzo generico o ripristina automaticamente lo SKU con possibilità di burst dopo l'aggiornamento. Se si ripristina automaticamente lo SKU con possibilità di burst, il sistema ripristina lo SKU B2S per impostazione predefinita.

Eseguire un aggiornamento pianificato della versione principale usando il portale di Azure per server SKU per utilizzo generico e business critical

Per eseguire un aggiornamento della versione principale di un server flessibile di Database di Azure per MySQL tramite il portale di Azure, seguire questa procedura.

Nel portale di Azure selezionare l'istanza del server flessibile di Database di Azure per MySQL esistente.

Importante

Anziché aggiornare direttamente l'ambiente di produzione, è consigliabile aggiornare prima la copia ripristinata del server. Vedere come eseguire il ripristino temporizzato.
Nella pagina Panoramica selezionare Aggiorna nella barra degli strumenti.

Importante

Prima dell'aggiornamento, visitare il collegamento per l'elenco delle funzionalità rimosse nella versione mySQL di destinazione. Verificare i valori deprecati sql_mode e rimuoverli o deselezionarli dal server flessibile di Database di Azure per MySQL corrente usando il pannello Parametri del server nel portale di Azure per evitare errori di distribuzione. sql_mode con i valori NO_AUTO_CREATE_USER, NO_FIELD_OPTIONS, NO_KEY_OPTIONS e NO_TABLE_OPTIONS non è più supportata in MySQL 8.0 e versioni successive.
Eseguire la convalida preliminare all'aggiornamento

Prima di procedere con l'aggiornamento, selezionare il pulsante Convalida per verificare la compatibilità del server con la versione mySQL di destinazione.
Note

La convalida online non è attualmente supportata per l'aggiornamento della versione principale da 8.0 a 8.4. Il cliente consiglia di usare lo strumento della community per eseguire la convalida preliminare dell'aggiornamento. La convalida online per il supporto da 8.0 a 8.4 verrà distribuita nel prossimo futuro.
Quando si usa la funzionalità "Convalida" per valutare lo schema del database per garantire la compatibilità con la versione di MySQL di destinazione, prendere nota delle considerazioni seguenti:
- Blocco di tabelle durante la convalida: il processo di convalida prevede il blocco delle tabelle per esaminare accuratamente l'intero schema. Ciò può causare timeout delle query se il database è sottoposto a un carico elevato. Raccomandazione: evitare l'esecuzione della convalida durante gli orari di ufficio di punta o quando il database gestisce traffico elevato. Pianificare invece la convalida durante periodi di bassa attività per ridurre l'impatto sulle operazioni.
- Potenziale di sospensione a causa di set di risultati di grandi dimensioni: in alcuni casi, in particolare con database complessi contenenti molti oggetti, il risultato della convalida potrebbe diventare troppo grande per essere elaborato o visualizzato all'interno del flusso di lavoro online. Questo potrebbe comportare che l'operazione di "Convalida" sembri bloccarsi o rimanere in corso indefinitamente. Raccomandazione: se si verifica questo problema, è consigliabile eseguire la convalida in locale usando lo strumento ufficiale di verifica dell'aggiornamento lato client di Oracle, ad esempio quello incluso in MySQL Shell. Questo approccio evita limitazioni delle dimensioni dei risultati sul lato piattaforma e fornisce un output di convalida più dettagliato e affidabile.
- Casi d'uso consigliati per la convalida online: la funzionalità "Convalida" online è progettata per schemi semplici o moderatamente complessi. Per gli ambienti di produzione su larga scala, ad esempio quelli con migliaia di tabelle, viste, routine o altri oggetti dello schema, è consigliabile usare lo strumento di verifica dell'aggiornamento lato client di Oracle per eseguire il controllo della compatibilità. In questo modo, lo schema completo viene analizzato in modo completo ed evita potenziali problemi correlati alle dimensioni dei risultati o ai timeout di convalida.
Nella barra laterale Aggiorna, nella casella di testo Versione MySQL da aggiornare verificare la versione principale di MySQL a cui si vuole eseguire l'aggiornamento (ad esempio 8.0 o 8.4).

Prima di poter aggiornare il server primario, è necessario aggiornare tutti i server di replica di lettura associati. Fino a quando non viene completato, l'aggiornamento è disabilitato.
Nel server primario selezionare il messaggio di conferma per verificare che tutti i server di replica siano stati aggiornati e quindi selezionare Aggiorna.

L'aggiornamento è abilitato per impostazione predefinita nei server di replica in lettura e autonomi.

Eseguire un aggiornamento pianificato della versione principale usando l'interfaccia della riga di comando di Azure

Per eseguire un aggiornamento della versione principale di un server flessibile di Database di Azure per MySQL tramite l'interfaccia della riga di comando di Azure, seguire questa procedura.

Installare l'interfaccia della riga di comando di Azure per Windows o usare l'interfaccia della riga di comando di Azure in Azure Cloud Shell per eseguire i comandi di aggiornamento.

Questo aggiornamento richiede la versione dell'interfaccia della riga di comando di Azure 2.40.0 o successiva. Se si sta usando Azure Cloud Shell, la versione più recente è già installata. Eseguire az version per trovare la versione e le librerie dipendenti installate. Per eseguire l'aggiornamento all'ultima versione, eseguire az upgrade.
Dopo aver eseguito l'accesso, eseguire il comando az mysql server upgrade.
```
az mysql flexible-server upgrade --name {your mysql server name} --resource-group {your resource group} --subscription {your subscription id} --version {target major version}
```
Sostituire {target major version} con la versione a cui si vuole eseguire l'aggiornamento, ad esempio 8 o 8.4.
Nella richiesta di conferma digitare y per confermare o n per arrestare il processo di aggiornamento e quindi premere INVIO.

Eseguire un aggiornamento della versione principale in un server di replica in lettura usando il portale di Azure

Per eseguire un aggiornamento della versione principale di un server di replica in lettura del server flessibile di Database di Azure per MySQL tramite il portale di Azure, seguire questa procedura.

selezionare il server di replica in lettura del server flessibile di Database di Azure per MySQL esistente nel portale di Azure.
Nella pagina Panoramica selezionare Aggiorna nella barra degli strumenti.

Importante

Prima dell'aggiornamento, visitare il collegamento per l'elenco delle funzionalità rimosse nella versione mySQL di destinazione. Verificare i valori deprecati sql_mode e rimuoverli o deselezionarli dal server flessibile di Database di Azure per MySQL corrente usando il pannello Parametri del server nel portale di Azure per evitare errori di distribuzione.
Nella sezione Aggiornamento selezionare Aggiorna per aggiornare un server di replica flessibile di Database di Azure per MySQL alla versione principale di destinazione. Viene visualizzata una notifica per verificare che l'aggiornamento sia riuscito.
Nella pagina Panoramica verificare che il server di replica in lettura del server flessibile di Database di Azure per MySQL esegua la versione di destinazione.
Passare al server primario ed eseguire un aggiornamento della versione principale.

Eseguire un aggiornamento della versione principale con tempi di inattività minimi usando le repliche in lettura

Per eseguire un aggiornamento della versione principale di un server flessibile di Database di Azure per MySQL con un tempo di inattività minimo usando server di replica in lettura, seguire questa procedura.

Nel portale di Azure selezionare l'istanza del server flessibile di Database di Azure per MySQL esistente.
Creare una replica in lettura dal server primario.
Aggiornare la replica di lettura alla versione principale di destinazione.
Dopo aver confermato che il server di replica è in esecuzione nella versione target, arrestare la connessione dell'applicazione al server primario.
Controllare lo stato della replica per assicurarsi che la replica abbia raggiunto il database primario in modo che tutti i dati siano sincronizzati e che non vengano eseguite nuove operazioni sul database primario.
Verificare con il comando mostra stato replica nel server di replica per visualizzare lo stato della replica.
```
SHOW SLAVE STATUS\G
```
Se lo stato di Slave_IO_Running e Slave_SQL_Running è sì e il valore di Seconds_Behind_Master è 0, la replica funziona correttamente. Seconds_Behind_Master indica il ritardo della replica. Se il valore non è 0, significa che la replica sta ancora elaborando gli aggiornamenti. Dopo aver verificato che il valore di Seconds_Behind_Master è 0, è possibile arrestare la replica.
Promuovere la replica in lettura al livello primario arrestando la replica.
Impostare il parametro server read_only su 0 (OFF) per iniziare a scrivere nella replica primaria alzata di livello.
Puntare l'applicazione alla nuova replica primaria (precedente) che esegue la versione di destinazione. Ogni server ha una stringa di connessione univoca. Aggiornare l'applicazione in modo che punti alla replica (precedente) anziché all'origine.

Note

Questo scenario comporta solo tempi di inattività durante i passaggi da 4 a 7.

Commenti e suggerimenti

Questa pagina è stata utile?

Last updated on 2025-09-29