Aggiornamento della versione principale in Database di Azure per MySQL - Server flessibile

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 sul posto dei server MySQL 5.7 a MySQL 8.0 senza alcun spostamento dei dati o la necessità di apportare modifiche alle stringhe di connessione dell'applicazione.

Prerequisiti

• Le repliche in lettura con MySQL versione 5.7 devono essere aggiornate prima che il server primario sia compatibile con le diverse versioni di MySQL. Per altre informazioni, vedere 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 MySQL 8.0, 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.

  Nota

  Quando si usa lo strumento ufficiale di Oracle per verificare la compatibilità dello schema, potrebbero essere 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 tranquillamente questi avvisi. Fanno riferimento alle stored procedure predefinite con il prefisso mysql., usate per supportare le funzionalità di Azure MySQL. Questi avvisi non influiscono sulla funzionalità del database.

• Attivare il backup su richiesta prima di eseguire un aggiornamento della versione principale nel server di produzione, che può essere usato per il rollback alla versione 5.7 dal backup su richiesta completo eseguito.
• 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. Per evitare questo problema, verificare prima di tutto 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.

Eseguire un aggiornamento pianificato della versione principale da MySQL 5.7 a MySQL 8.0 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. Ciò è dovuto al fatto che gli aggiornamenti delle versioni principali sono a elevato utilizzo di risorse, richiedendo CPU e memoria significative. Le istanze dello SKU con burst basati sul credito potrebbero avere difficoltà in base a 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:

1. Nel portale di Azureselezionare il server flessibile di Database di Azure per MySQL 5.7 esistente.

   Importante

   Anziché aggiornare direttamente l'ambiente di produzione, è consigliabile aggiornare prima la copia ripristinata del server. Vedere come eseguire il ripristino temporizzato.

2. Nella pagina Panoramica selezionare Aggiorna nella barra degli strumenti.

   Importante

   Prima di aggiornare, visitare il collegamento per l'elenco delle funzionalità rimosse in MySQL 8.0. Verificare i valori sql_mode deprecati e rimuoverli/deselezionarli dal server flessibile di Database di Azure per MySQL 5.7 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.

   

3. Convalida della compatibilità dello schema

   Prima di procedere con l'aggiornamento, eseguire lo strumento ufficiale di Oracle per controllo degli aggiornamenti MySQL per verificare che lo schema del database corrente sia compatibile con MySQL 8.0. Questo passaggio è fondamentale per garantire un processo di aggiornamento uniforme.

4. Decisione pre-aggiornamento

   Prima di procedere con l'aggiornamento, è necessario scegliere il livello di calcolo a cui si vuole eseguire l'aggiornamento della versione principale. Per impostazione predefinita, il sistema eseguirà l'aggiornamento dall'SKU con possibilità di burst all'SKU per utilizzo generico più semplice, ma è possibile scegliere di eseguire l'aggiornamento a un livello di calcolo superiore, se necessario.

   Nota

   Mentre il server opera nel livello "Utilizzo generico" durante l'aggiornamento, verranno addebitati solo i costi per le risorse "Utilizzo generico" effettive usate durante questo periodo.

5. Decisione post-aggiornamento

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

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

6. Aggiornamento versione principale

   Dopo l'aggiornamento del livello di calcolo, il sistema avvierà 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.

   Nota

   Se l'aggiornamento della versione principale non riesce, il livello di calcolo non verrà ripristinato automaticamente all'SKU con possibilità di burst precedente. Ciò consente ai clienti di continuare l'aggiornamento della versione principale senza dover eseguire di nuovo l'aggiornamento del livello di calcolo.

7. Reversione automatica

   In base alla decisione di pre-aggiornamento, il sistema manterrà l'SKU per utilizzo generico o ripristinerà automaticamente l'SKU con possibilità di burst dopo il completamento dell'aggiornamento.

   Nota

   Se si sceglie di ripristinare automaticamente l'SKU con possibilità di burst, il sistema ripristina l'SKU B2S per impostazione predefinita.

Eseguire un aggiornamento pianificato della versione principale da MySQL 5.7 a MySQL 8.0 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 5.7 tramite il portale di Azure, seguire questa procedura.

1. Nel portale di Azureselezionare il server flessibile di Database di Azure per MySQL 5.7 esistente.

   Importante

   Anziché aggiornare direttamente l'ambiente di produzione, è consigliabile aggiornare prima la copia ripristinata del server. Vedere come eseguire il ripristino temporizzato.

2. Nella pagina Panoramica selezionare Aggiorna nella barra degli strumenti.

   Importante

   Prima di aggiornare, visitare il collegamento per l'elenco delle funzionalità rimosse in MySQL 8.0. Verificare i valori sql_mode deprecati e rimuoverli/deselezionarli dal server flessibile di Database di Azure per MySQL 5.7 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.

   

3. Eseguire la convalida preliminare all'aggiornamento

   Prima di procedere con l'aggiornamento, selezionare il pulsante Convalida per verificare la compatibilità del server con MySQL 8.0.

   

   Importante

   Quando si usa la funzionalità "Convalida" per verificare la compatibilità dello schema del database con MySQL 8.0, tenere presente che ciò comporterà il blocco delle tabelle per valutare accuratamente l'intero schema. Questo processo potrebbe causare timeout delle query.
   Pertanto, è consigliabile non eseguire la convalida durante le ore lavorative di punta o quando il database riscontra un traffico elevato. La scelta di un periodo di bassa attività per la convalida può contribuire a ridurre al minimo l'impatto sulle operazioni.

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

   

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

5. Nel server primario selezionare il messaggio di conferma per verificare che tutti i server di replica siano stati aggiornati e quindi selezionare Aggiorna.

   

   Nei server di replica in lettura e autonomi l'Aggiornamento è abilitato per impostazione predefinita.

Eseguire un aggiornamento pianificato della versione principale da MySQL 5.7 a MySQL 8.0 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 5.7 tramite l'interfaccia della riga di comando di Azure, seguire questa procedura.

1. 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 2.40.0 o successiva dell'interfaccia della riga di comando di Azure. 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 alla versione più recente, eseguire az upgrade.

2. 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 8
   

3. 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 da MySQL 5.7 a MySQL 8.0 in un server di replica in lettura usando il portale di Azure

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

1. Nel portale di Azure selezionare il server di replica in lettura del server flessibile di Database di Azure per MySQL 5.7 esistente.

2. Nella pagina Panoramica selezionare Aggiorna nella barra degli strumenti.

1. Nella sezione Aggiorna selezionare Aggiorna per aggiornare un server di replica in lettura flessibile di Database di Azure per MySQL 5.7 in lettura a MySQL 8.0.

   Viene visualizzata una notifica per confermare che l'aggiornamento è riuscito.

2. Nella pagina Panoramica verificare che il server di replica in lettura del server flessibile di Database di Azure per MySQL sia in esecuzione con la versione 8.0.

3. Passare ora al server primario ed eseguire l'aggiornamento della versione principale.

Eseguire l'aggiornamento della versione principale con tempo di inattività minimo da MySQL 5.7 a MySQL 8.0 usando le repliche in lettura

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

1. Nel portale di Azure selezionare il server flessibile di Database di Azure per MySQL 5.7 esistente.

2. Creare una replica in lettura dal server primario.

3. Aggiornare la replica in lettura alla versione 8.0.

4. Dopo aver confermato che il server di replica è in esecuzione nella versione 8.0, arrestare la connessione dell'applicazione al server primario.

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

6. 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 è **, è possibile arrestare la replica.

7. Promuovere la replica in lettura al livello primario arrestando la replica.

8. Impostare il parametro server read_only su 0 (OFF) per iniziare a scrivere nella replica primaria alzata di livello.

9. Puntare l'applicazione alla nuova replica primaria (replica precedente) che esegue il server 8.0. Ogni server ha una stringa di connessione univoca. Aggiornare l'applicazione in modo che punti alla replica (precedente) anziché all'origine.

Domande frequenti

• Questo causerà un tempo di inattività del server e, in tal caso, quanto tempo?

  Per avere tempi di inattività minimi durante gli aggiornamenti, seguire i passaggi indicati in Eseguire un aggiornamento della versione principale con tempi di inattività minimi da MySQL 5.7 a MySQL 8.0 usando repliche in lettura. Durante il processo di aggiornamento il server sarà non disponibile, pertanto è consigliabile eseguire questa operazione in occasione della finestra di manutenzione pianificata. Il tempo di inattività stimato dipende dalle dimensioni del database, dalle dimensioni dell’archiviazione di cui è stato effettuato il provisioning (operazioni di I/O al secondo di cui è stato effettuato il provisioning) e dal numero delle tabelle nel database. Il tempo di aggiornamento è direttamente proporzionale al numero di tabelle nel server. Per stimare il tempo di inattività per l'ambiente del server, è consigliabile eseguire prima l'aggiornamento alla copia ripristinata del server.

• Cosa accade ai backup dopo l'aggiornamento?

  Tutti i backup (automatizzati/su richiesta) eseguiti prima dell'aggiornamento della versione principale, se usati per il ripristino, verranno sempre ripristinati in un server con la versione precedente (5.7). Tutti i backup (automatizzati/su richiesta) eseguiti dopo l'aggiornamento della versione principale verranno ripristinati nel server con la versione aggiornata (8.0). È consigliabile eseguire il backup su richiesta prima di eseguire l'aggiornamento della versione principale per un semplice rollback.

• Attualmente uso lo SKU con possibilità di burst, Microsoft prevede di supportare l'aggiornamento della versione principale per questo SKU in futuro?

  L'SKU con possibilità di burst non è in grado di supportare l'aggiornamento della versione principale a causa della limitazione delle prestazioni di questo SKU.

  Se è necessario eseguire un aggiornamento della versione principale nell'istanza del server flessibile di Database di Azure per MySQL e attualmente si usa l'SKU con possibilità di burst, una soluzione temporanea consiste nell'eseguire l'aggiornamento all'SKU per utilizzo generico o business critical, eseguire l'aggiornamento e quindi tornare all'SKU con possibilità di burst.

  L'aggiornamento a uno SKU superiore potrebbe comportare una modifica dei prezzi e potrebbe comportare un aumento dei costi per la distribuzione. Tuttavia, poiché il processo di aggiornamento non richiede molto tempo, i costi aggiuntivi non saranno significativi.

Contenuto correlato

• come configurare la manutenzione pianificata
• MySQL versione 8.0