Share via


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

SI APPLICA A: Database di Azure per MySQL - Server flessibile

Nota

Questo articolo contiene riferimenti al termine slave, che Microsoft non usa più. Quando il termine viene rimosso dal software, lo rimuoveremo da questo articolo.

Questo articolo descrive come aggiornare la versione principale di MySQL sul posto in Database di Azure per MySQL server flessibile. 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 applicazioni stringa di connessione.

Importante

  • L'aggiornamento della versione principale non è attualmente disponibile per i server versione 5.7 in base allo SKU burstable.
  • La durata del tempo di inattività varia in base alle dimensioni dell'istanza del database e al numero di tabelle in esso contenute.
  • Quando si avvia un aggiornamento della versione principale per Database di Azure per MySQL server flessibile 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.
  • 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. È possibile apportare le modifiche di configurazione necessarie nel server e ritentare l'aggiornamento.

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. Altre informazioni sulla compatibilità della replica tra le versioni di MySQL.
  • Prima di aggiornare i server di produzione, è ora più semplice ed efficiente con la funzionalità Convalida incorporata nel portale di Azure. Questo strumento controlla in modo preliminare la compatibilità dello schema del database con MySQL 8.0, evidenziando potenziali problemi. Sebbene sia disponibile questa opzione pratica, è consigliabile usare lo strumento ufficiale di verifica dell'aggiornamento di Oracle MySQL per testare la compatibilità dello schema del 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, che può essere usato per eseguire il rollback alla versione 5.7 dal backup completo su richiesta eseguito.

Eseguire un aggiornamento pianificato della versione principale da MySQL 5.7 a MySQL 8.0 usando il portale di Azure

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

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

    Importante

    È consigliabile eseguire prima l'aggiornamento in una copia ripristinata del server anziché aggiornare direttamente la produzione. Vedere come eseguire il ripristino temporizzato.

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

    Importante

    Prima di aggiornare il collegamento per l'elenco delle funzionalità rimosse in MySQL 8.0. Verificare i valori sql_mode deprecati e rimuoverli o deselezionarli dal server flessibile Database di Azure per MySQL corrente 5.7 usando il pannello Parametri server nel portale di Azure per evitare errori di distribuzione. sql_mode con valori NO_AUTO_CREATE_U edizione Standard R, NO_FIELD_OPTIONS, NO_KEY_OPTIONS e NO_TABLE_OPTIONS non sono più supportati in MySQL 8.0.

    Screenshot showing Azure Database for MySQL flexible server Upgrade.

  3. Eseguire la convalida preliminare all'aggiornamento

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

    Screenshot showing validate.

    Importante

    Quando si usa la funzionalità "Convalida" per verificare la compatibilità dello schema del database con MySQL 8.0, tenere presente che comporta il blocco delle tabelle per valutare accuratamente l'intero schema. Questo processo può 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 MySQL version to upgrade (Aggiorna versione di MySQL) verificare la versione principale di MySQL a cui si vuole eseguire l'aggiornamento, ad esempio 8.0.

    Screenshot showing Upgrade.

    Prima di poter aggiornare il server primario, è necessario aggiornare tutti i server di replica di lettura associati. Fino al completamento dell'operazione, 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.

    Screenshot showing upgrade.

    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 Database di Azure per MySQL server 5.7 usando 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 usa 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 Database di Azure per MySQL 5.7 a MySQL 8.0 in una replica in lettura usando il portale di Azure, seguire questa procedura.

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

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

Importante

Prima di aggiornare il collegamento per l'elenco delle funzionalità rimosse in MySQL 8.0. Verificare i valori sql_mode deprecati e rimuoverli/deselezionarli dal server flessibile Database di Azure per MySQL corrente 5.7 usando il pannello Parametri server nel portale di Azure per evitare errori di distribuzione.

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

    Viene visualizzata una notifica per verificare che l'aggiornamento sia riuscito.

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

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

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

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

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

  2. Creare una replica di lettura dal server primario.

  3. Aggiornare la replica di lettura alla versione 8.0.

  4. Dopo aver verificato che il server di replica esegue la 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 show replica status (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 è e il valore di Seconds_Behind_Master è 0, la replica funziona correttamente. Seconds_Behind_Master indica la ritardo della replica. Se il valore non è 0, la replica sta ancora elaborando gli aggiornamenti. Dopo aver verificato che il valore di Seconds_Behind_Master è, è possibile arrestare la replica.

  7. Alzare di livello la replica di lettura a primaria arrestando la replica.

  8. Impostare 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 (precedente) che esegue il server 8.0. Ogni server ha un stringa di connessione univoco. Aggiornare l'applicazione in modo che punti alla replica (precedente) anziché all'origine.

Nota

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

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 l'aggiornamento minimo della versione principale del tempo di inattività da MySQL 5.7 a MySQL 8.0 usando repliche in lettura. Il server non sarà disponibile durante il processo di aggiornamento, pertanto è consigliabile eseguire questa operazione durante la finestra di manutenzione pianificata. Il tempo di inattività stimato dipende dalle dimensioni del database, dalle dimensioni di archiviazione di cui è stato effettuato il provisioning (con provisioning di I/O) e dal numero di tabelle nel database. L'ora di aggiornamento è direttamente proporzionale al numero di tabelle nel server. Per stimare il tempo di inattività per l'ambiente 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 versione aggiornata (8.0). È consigliabile eseguire il backup su richiesta prima di eseguire l'aggiornamento della versione principale per un semplice rollback.

  • Attualmente si usa lo SKU burstable, Microsoft prevede di supportare l'aggiornamento della versione principale per questo SKU in futuro?

    Lo SKU con 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 lo SKU con burst, una soluzione temporanea consiste nell'eseguire l'aggiornamento allo SKU per utilizzo generico o business critical, eseguire l'aggiornamento e quindi tornare allo SKU con burst.

    Si noti che l'aggiornamento a uno SKU superiore può comportare una modifica dei prezzi e può comportare un aumento dei costi per la distribuzione. Tuttavia, poiché il processo di aggiornamento non richiede molto tempo, i costi aggiunti non devono essere significativi.

Passaggi successivi