Esegui l'upgrade della versione principale del database in loco

Questa pagina descrive come eseguire l'upgrade della versione principale del database eseguendo l'upgrade in situ dell'istanza Cloud SQL anziché eseguire la migrazione dei dati.

Introduzione

I fornitori di software per database rilasciano periodicamente nuove versioni principali che contengono nuove funzionalità, miglioramenti delle prestazioni e della sicurezza. Cloud SQL importa le nuove versioni dopo il loro rilascio. Quando Cloud SQL offre il supporto per una nuova versione principale, puoi eseguire l'upgrade delle istanze per mantenere aggiornato il database.

Puoi eseguire l'upgrade della versione del database di un'istanza in situ o tramite la migrazione dei dati. Gli upgrade in situ sono un modo più semplice per eseguire l'upgrade della versione principale dell'istanza. Non è necessario eseguire la migrazione dei dati o modificare le stringhe di connessione dell'applicazione. Con gli upgrade in place, puoi mantenere il nome, l'indirizzo IP e altre impostazioni della tua istanza attuale dopo l'upgrade. Gli upgrade in situ non richiedono lo spostamento dei file di dati e possono essere completati più rapidamente. In alcuni casi, il tempo di riposo è inferiore a quello necessario per la migrazione dei dati.

Pianificare un upgrade della versione principale

1. Scegli una versione principale di destinazione.

   gcloud

   Per informazioni su come installare e iniziare a utilizzare gcloud CLI, consulta Installare gcloud CLI. Per informazioni su come avviare Cloud Shell, consulta Utilizzare Cloud Shell.

   Per controllare le versioni del database che puoi scegliere come target per un upgrade in situ sulla tua istanza:

   1. Esegui questo comando.

   gcloud sql instances describe INSTANCE_NAME
      

   Sostituisci INSTANCE_NAME con il nome dell'istanza.

   2. Nell'output del comando, individua la sezione etichettata upgradableDatabaseVersions.
   3. Ogni sottosezione restituisce una versione del database disponibile per l'upgrade. In ogni sottosezione, controlla i seguenti campi.
   • majorVersion: la versione principale che puoi scegliere come target per l'upgrade in situ.
   • name: la stringa della versione del database che include la versione principale. Per Cloud SQL per MySQL, questo campo include anche la versione minore del database.
   • displayName: il nome visualizzato della versione del database.

   REST v1

   Per controllare quali versioni del database di destinazione sono disponibili per un upgrade in place della versione principale, utilizza il metodo instances.get dell'API Cloud SQL Admin.

   Prima di utilizzare i dati della richiesta, apporta le seguenti sostituzioni:

   • INSTANCE_NAME: il nome dell'istanza.

   Metodo HTTP e URL:

   GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME

   Per inviare la richiesta, espandi una di queste opzioni:

   curl (Linux, macOS o Cloud Shell)

   Esegui questo comando:

   curl -X GET \
        -H "Authorization: Bearer $(gcloud auth print-access-token)" \
        "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME"

   PowerShell (Windows)

   Esegui questo comando:

   $cred = gcloud auth print-access-token
   $headers = @{ "Authorization" = "Bearer $cred" }
   
   Invoke-WebRequest `
       -Method GET `
       -Headers $headers `
       -Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME" | Select-Object -Expand Content

   Dovresti ricevere una risposta JSON simile alla seguente:

   
   upgradableDatabaseVersions:
   
   {
     major_version: "MYSQL_8_0"
     name: "MYSQL_8_0_36"
     display_name: "MySQL 8.0.36"
   }
   
   

   REST v1beta4

   Per controllare quali versioni del database di destinazione sono disponibili per l'upgrade in situ della versione principale di un'istanza, utilizza il metodo instances.get dell'API Cloud SQL Admin.

   Prima di utilizzare i dati della richiesta, apporta le seguenti sostituzioni:

   • INSTANCE_NAME: il nome dell'istanza.

   Metodo HTTP e URL:

   GET https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME

   Per inviare la richiesta, espandi una di queste opzioni:

   curl (Linux, macOS o Cloud Shell)

   Esegui questo comando:

   curl -X GET \
        -H "Authorization: Bearer $(gcloud auth print-access-token)" \
        "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME"

   PowerShell (Windows)

   Esegui questo comando:

   $cred = gcloud auth print-access-token
   $headers = @{ "Authorization" = "Bearer $cred" }
   
   Invoke-WebRequest `
       -Method GET `
       -Headers $headers `
       -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME" | Select-Object -Expand Content

   Dovresti ricevere una risposta JSON simile alla seguente:

   
   upgradableDatabaseVersions:
   
   {
     major_version: "MYSQL_8_0"
     name: "MYSQL_8_0_36"
     display_name: "MySQL 8.0.36"
   }
   
   

   Per l'elenco completo delle versioni del database supportate da Cloud SQL, consulta Versioni del database e criteri di versione.

2. Prendi in considerazione le funzionalità offerte in ogni versione principale del database e risolvi le incompatibilità.

   • MySQL 8.4
   • MySQL 8.0
   • MySQL 5.7

   Le nuove versioni principali introducono modifiche incompatibili che potrebbero richiedere la modifica del codice dell'applicazione, dello schema o delle impostazioni del database. Prima di eseguire l'upgrade dell'istanza di database, consulta le note di rilascio della versione principale di destinazione per determinare le incompatibilità da risolvere.

   Dopo l'upgrade a una versione successiva, il valore predefinito di alcune variabili di sistema potrebbe cambiare. Ad esempio, il valore predefinito di character_set_server in MySQL 5.6 e MySQL 5.7 è utf8. Quando esegui l'upgrade a MySQL 8.0, il valore predefinito character_set_server diventa utf8mb4. Per ripristinare utf8, devi modificare manualmente il valore del flag di database impostandolo sul valore precedente. Per ulteriori informazioni, consulta Configurare i flag di database. La maggior parte delle modifiche ai valori predefiniti viene eseguita dalla community MySQL (scopri di più in Eseguire l'upgrade dei valori predefiniti del server).

3. Se esegui l'upgrade da MySQL 8.0 a 8.4, devi prima eseguire l'upgrade delle istanze a MySQL 8.0.37 o versioni successive prima di poter eseguire l'upgrade a MySQL 8.4. Per eseguire l'upgrade della versione secondaria, consulta Eseguire l'upgrade della versione secondaria del database.

4. Esegui il precontrollo per gli upgrade.

   • Se stai eseguendo l'upgrade da MySQL 5.7 a 8.0, esegui un precontrollo per gli upgrade da MySQL 5.7 a 8.0. Puoi utilizzare l'utilità Upgrade Checker nella shell MySQL.

   • Se esegui l'upgrade da MySQL 8.0 a 8.4, esegui un precontrollo per gli upgrade da MySQL 8.0 a 8.4. Puoi utilizzare l'utilità Upgrade Checker nella shell MySQL.

     Se vengono rilevati problemi durante il controllo preliminare, risolvili prima di procedere con l'upgrade. Cloud SQL non supporta il controllo preliminare durante un upgrade della versione principale. Anche un tentativo di eseguire l'upgrade di un'istanza che non ha superato il controllo preliminare potrebbe non riuscire.

5. Controlla lo spazio su disco e i tipi di macchine delle istanze.

   Un upgrade di una versione principale richiede risorse aggiuntive, come spazio su disco, per memorizzare le tabelle di cui è stato eseguito l'upgrade. Se lo spazio su disco non è sufficiente, l'upgrade non riesce e viene eseguito il rollback. Per un upgrade da MySQL 5.7 a 8.0, è necessaria memoria aggiuntiva per convertire i vecchi metadati nel nuovo dizionario di dati. Prima di eseguire un upgrade della versione principale, assicurati di avere più di 100.000 byte di memoria per ogni tabella. Puoi aumentare temporaneamente la memoria modificando il tipo di macchina.

6. Per gli upgrade da MySQL 5.7 a MySQL 8.0, controlla le modifiche alle concessioni degli utenti in MySQL 8.0

   Cloud SQL per MySQL versione 8.0 utilizza un flag chiamato partial_revokes, che è impostato su ON per impostazione predefinita. A differenza di MySQL 5.7, questo flag rimuove la possibilità di utilizzare caratteri jolly nei comandi GRANT del database. Per assicurarti che gli utenti del database abbiano accesso agli schemi del database corretti, modifica i privilegi degli utenti del database prima di eseguire l'upgrade a MySQL 8.0. Aggiorna i privilegi dell'utente in modo da utilizzare il nome completo degli schemi di database richiesti anziché i caratteri jolly.

   Per ulteriori informazioni sul funzionamento di questo flag in MySQL 8.0, consulta partial_revokes in MySQL 8.0.

7. Prova l'upgrade con una simulazione.

   Esegui una simulazione della procedura di upgrade end-to-end in un ambiente di test prima di eseguire l'upgrade del database di produzione. Puoi clonare l'istanza per creare una copia identica dei dati su cui testare la procedura di upgrade.

   Oltre a verificare che l'upgrade venga completato correttamente, esegui dei test per assicurarti che l'applicazione si comporti come previsto nel database di cui è stato eseguito l'upgrade.

8. Decidi un orario per l'upgrade.

   L'upgrade richiede che l'istanza non sia disponibile per un determinato periodo di tempo. Pianifica l'upgrade in un periodo di tempo in cui l'attività del database è ridotta.

Prepararsi per un upgrade della versione principale

Prima di eseguire l'upgrade, completa i seguenti passaggi:

1. SOLO per gli upgrade da MySQL 5.7 a 8.0: controlla e correggi i problemi di incompatibilità rilevati durante la procedura di precontrollo. I problemi comuni rilevati possono includere:

   1. Aggiunta di nuove parole chiave riservate, come RANKS, GROUPS, FUNCTION, in stored procedure, trigger e altri oggetti del database. Per ulteriori informazioni, consulta la sezione Parole chiave e parole riservate.
   2. Caratteri UTF non validi nelle definizioni delle tabelle.
   3. Transizioni XA non committate che devono essere committate (utilizzando l'istruzione XA COMMIT) o annullate (utilizzando l'istruzione XA ROLLBACK).
   4. Il vincolo della chiave esterna nei nomi più lunghi di 64 caratteri.
   5. Tipo di dati spaziali nell'indice misto delle colonne. Per ulteriori informazioni, consulta Tipo di dati spaziali.

   Per saperne di più, consulta Preparare l'installazione per l'upgrade e Eseguire l'upgrade a MySQL 8.0?.

   SOLO per gli upgrade da MySQL 8.0 a MySQL 8.4: controlla e correggi i problemi di incompatibilità rilevati durante la procedura di precontrollo. Un problema comune potrebbe essere:

   • Terminologia di replica obsoleta. I termini MASTER e SLAVE sono completamente rimossi da MySQL 8.4. Se utilizzi ancora comandi o configurazioni con questi termini, devi sostituirli o rimuoverli. Per ulteriori informazioni sulla rimozione e sulla sostituzione di questi termini, consulta Novità di MySQL 8.4 rispetto a MySQL 8.0.
   • Aggiorna il plug-in di autenticazione dei tuoi account utente esistenti in modo da utilizzare il plug-in di autenticazione caching_sha2_password anziché il plug-in mysql_native_password deprecato.
     
     Per modificare gli account utente del database esistenti in modo che utilizzino il plug-in di autenticazione caching_sha2_password, utilizza il seguente comando:

          ALTER USER 'username'@'%'
          IDENTIFIED WITH caching_sha2_password BY 'user_password';
          

     Sostituisci username e user_password con i valori dell'account utente che stai aggiornando.

2. Controllare lo spazio su disco e il tipo di macchina dell'istanza

   Gli upgrade delle versioni principali richiedono spazio su disco e memoria aggiuntivi per archiviare le tabelle di cui è stato eseguito l'upgrade e il nuovo dizionario di dati. La mancanza dello spazio su disco richiesto causa il fallimento dell'upgrade e rollback della versione originale. Cloud SQL consiglia di avere almeno 100.000 in memoria per ogni tabella.

   Nota: puoi aumentare temporaneamente la memoria modificando il tipo di macchina prima di eseguire l'upgrade alla versione principale. Per saperne di più, consulta Modificare il tipo di macchina.

3. Esegui l'upgrade delle repliche di lettura.

   Se utilizzi le repliche di lettura, devi eseguire l'upgrade di tutte le repliche di lettura prima di eseguire l'upgrade dell'istanza principale. Se viene eseguito l'upgrade della replica, ma non dell'istanza principale, la replica potrebbe non funzionare se l'istanza principale utilizza istruzioni o funzioni non più supportate in una versione successiva di MySQL utilizzata dalla replica. Per evitare questi problemi, Cloud SQL consiglia di:

   1. Esegui l'upgrade della principale immediatamente dopo l'upgrade delle repliche.
   2. Evita di eseguire query incompatibili con la nuova versione nell'istanza principale finché l'upgrade non è stato completato correttamente.
   3. (Facoltativo) Metti in pausa tutte le istruzioni WRITE nell'istanza principale fino al completamento dell'upgrade.
   4. (Facoltativo) Rimuovi tutte le repliche prima di eseguire l'upgrade della principale e ricreale al termine dell'upgrade.

   Se la replica si interrompe, viene eseguito il rollback della replica alla versione dell'istanza principale. Puoi eseguire di nuovo l'upgrade della replica, ma se il problema persiste, consulta le domande frequenti.

Esegui l'upgrade della versione principale del database in loco

Quando avvii un'operazione di upgrade, Cloud SQL controlla innanzitutto la configurazione dell'istanza per assicurarsi che sia compatibile con l'upgrade. Dopo aver verificato la configurazione, Cloud SQL rende l'istanza non disponibile, esegue un backup prima dell'upgrade, esegue l'upgrade, rende l'istanza disponibile ed esegue un backup dopo l'upgrade.

resource "google_sql_database_instance" "instance" {
  name             = "mysql-instance"
  region           = "us-central1"
  database_version = "MYSQL_8_0"
  settings {
    tier = "db-n1-standard-2"
  }
  # set `deletion_protection` to true, will ensure that one cannot accidentally delete this instance by
  # use of Terraform whereas `deletion_protection_enabled` flag protects this instance at the GCP level.
  deletion_protection = false
}

Quando effettui una richiesta di upgrade in situ, Cloud SQL esegue innanzitutto un controllo pre-upgrade. Se Cloud SQL determina che l'istanza non è pronta per un upgrade, la richiesta di upgrade non va a buon fine e viene visualizzato un messaggio che suggerisce come risolvere il problema. Vedi anche Risolvere i problemi di un upgrade della versione principale.

Backup dell'upgrade automatico

Quando esegui un upgrade di una versione principale, Cloud SQL esegue automaticamente due backup on demand, chiamati backup di upgrade:

• Il primo backup dell'upgrade è il backup pre-upgrade, che viene eseguito immediatamente prima dell'avvio dell'upgrade. Puoi utilizzare questo backup per ripristinare la tua istanza di database allo stato della versione precedente.
• Il secondo backup dell'upgrade è il backup post-upgrade, che viene eseguito subito dopo che sono consentite nuove scritture nell'istanza del database di cui è stato eseguito l'upgrade.

Quando visualizzi l'elenco dei backup, i backup dell'upgrade sono elencati con il tipo On-demand. I backup di upgrade sono etichettati in modo da poterli identificare rapidamente. Ad esempio, se esegui l'upgrade da MySQL 5.7 a MySQL 8.0, il backup pre-upgrade è etichettato come Pre-upgrade backup, MYSQL_5_7 to MYSQL_8_0. e il backup post-upgrade come Post-upgrade backup, MYSQL_8_0 from MYSQL_5_7.. Se esegui l'upgrade da MySQL 8.0 a MySQL 8.4, il backup pre-upgrade è etichettato come Pre-upgrade backup, MYSQL_8_0 to MYSQL_8_4. e il backup post-upgrade come Post-upgrade backup, MYSQL_8_4 from MYSQL_8_0..

Come per gli altri backup on demand, i backup di upgrade rimangono visibili finché non li elimini o non elimini l'istanza. Se hai attivato il PITR, non puoi eliminare i backup dell'upgrade mentre si trovano nel periodo di conservazione. Se devi eliminare i backup dell'upgrade, devi disattivare la copia incrementale a livello di blocco o attendere che i backup dell'upgrade non siano più inclusi nel periodo di conservazione.

Completare l'upgrade della versione principale

1. Esegui i test di accettazione.

   Esegui test per verificare che il sistema di cui è stato eseguito l'upgrade funzioni come previsto.

2. (Facoltativo) Aggiorna i privilegi utente.

   Se hai eseguito l'upgrade a MySQL 8.0, tieni presente che MySQL ha modificato i sistemi di sicurezza e gestione degli account. Per ulteriori informazioni, consulta Novità di MySQL 8.0.

   Ciò potrebbe causare il fatto che gli utenti creati nella versione MySQL 5.7 dell'istanza non abbiano gli stessi privilegi degli utenti creati direttamente in MySQL 8.0. Ad esempio, un utente che ha eseguito l'upgrade da MySQL 5.7 potrebbe non disporre dei privilegi CREATE ROLE e DROP ROLE perché questi privilegi non esistevano in MySQL 5.7. Cloud SQL consiglia di reimpostare i privilegi utente dopo l'upgrade delle versioni per risolvere eventuali problemi relativi ai privilegi utente.

   Se hai eseguito l'upgrade da MySQL 8.0 a MySQL 8.4, sono presenti ulteriori modifiche ai privilegi utente, tra cui l'aggiunta di privilegi introdotti in MySQL 8.4 e la rimozione dei privilegi esistenti in MySQL 8.0. Per ulteriori informazioni, consulta Privilegi utente di MySQL 8.4 (cloudsqlsuperuser).

   Puoi aggiornare i privilegi utente in MySQL 8.0 o MySQL 8.4 nel seguente modo:

   1. Crea un utente a cui è stato concesso il ruolo cloudsqlsuperuser.

   2. Utilizza l'utente creato per revocare tutti i privilegi precedenti a un utente di cui è stato eseguito l'upgrade con:

      REVOKE ALL PRIVILEGES ON *.* FROM user@host

   3. Concedi all'utente di cui è stato eseguito l'upgrade i privilegi previsti.

3. (Facoltativo) Crea un backup.

   Sebbene Cloud SQL crei automaticamente un backup dopo l'upgrade dell'istanza principale, Cloud SQL consiglia di creare un backup autonomamente per poter recuperare il database, se necessario.

4. (Facoltativo) Se hai eseguito l'upgrade a Cloud SQL per MySQL 8.4, aggiornate anche tutti i connettori, i client e le shell MySQL a MySQL 8.4.

Risolvere i problemi di un upgrade della versione principale

Cloud SQL restituisce un messaggio di errore se provi a eseguire un comando di upgrade non valido, ad esempio se l'istanza contiene flag di database non validi per la nuova versione.

Se la richiesta di upgrade non va a buon fine, controlla la sintassi della richiesta. Se la richiesta ha una struttura valida, prova a esaminare i seguenti suggerimenti.

Visualizza i log di upgrade

Se si verificano problemi con una richiesta di upgrade valida, Cloud SQL pubblica i log degli errori in projects/PROJECT_ID/logs/cloudsql.googleapis.com%2Fmysql.err. Ogni voce di log contiene un'etichetta con l'identificatore dell'istanza per aiutarti a identificare l'istanza con l'errore di upgrade. Cerca questi errori di upgrade e risolvili.

Per visualizzare i log degli errori:

1. Nella console Google Cloud, vai alla pagina Istanze Cloud SQL.

   Vai a Istanze Cloud SQL

2. Per aprire la pagina Panoramica di un'istanza, fai clic sul nome dell'istanza.

3. Nel riquadro Operazioni e log della pagina Panoramica dell'istanza, fai clic sul link Visualizza i log degli errori MySQL.

   Viene visualizzata la pagina Esplora log.

4. Visualizza i log come segue:

   • Per elencare tutti i log di errore in un progetto, seleziona il nome del log nel filtro Nome log.

   Per ulteriori informazioni sui filtri delle query, consulta la sezione Query avanzate.

   • Per filtrare i log degli errori di upgrade per una singola istanza, inserisci la seguente query nella casella Cerca in tutti i campi, dopo aver sostituito DATABASE_ID

   con l'ID progetto seguito dal nome dell'istanza in questo formato: project_id:instance_name.

   resource.type="cloudsql_database"
   resource.labels.database_id="DATABASE_ID"
   logName : "projects/PROJECT_ID/logs/cloudsql.googleapis.com%2Fmysql.err"

   Ad esempio, per filtrare i log degli errori di upgrade in base a un'istanza denominata shopping-db in esecuzione nel progetto buylots, utilizza il seguente filtro query:

    resource.type="cloudsql_database"
    resource.labels.database_id="buylots:shopping-db"
    logName : "projects/buylots/logs/cloudsql.googleapis.com%2Fmysql.err"

Ripristinare la versione principale precedente

Se il sistema di database di cui è stato eseguito l'upgrade non funziona come previsto, potrebbe essere necessario ripristinare l'istanza alla versione precedente. A tal fine, ripristina il backup pre-upgrade in un'istanza di recupero Cloud SQL, ovvero una nuova istanza che esegue la versione pre-upgrade.

Per ripristinare la versione precedente, svolgi i seguenti passaggi:

1. Identifica il backup precedente all'upgrade.

   Consulta Backup automatici dell'upgrade.

2. Crea un'istanza di ripristino.

   Crea una nuova istanza Cloud SQL utilizzando la versione principale su cui era in esecuzione Cloud SQL quando è stato eseguito il backup precedente all'upgrade. Imposta gli stessi flag e le stesse impostazioni dell'istanza utilizzate dall'istanza originale.

3. Ripristina il backup precedente all'upgrade.

   Ripristina il backup precedente all'upgrade nell'istanza di recupero. L'operazione potrebbe richiedere diversi minuti.

4. Aggiungi le repliche di lettura.

   Se utilizzavi repliche di lettura, aggiungile singolarmente.

5. Collega l'applicazione.

   Dopo aver recuperato il sistema di database, aggiorna l'applicazione con i dettagli dell'istanza di recupero e delle relative repliche di lettura. Puoi riprendere la pubblicazione del traffico nella versione precedente del database.

Limitazioni

Questa sezione elenca le limitazioni per un upgrade in situ della versione principale.

• Non puoi eseguire un upgrade in situ della versione principale su una replica esterna.
• L'upgrade delle istanze da MySQL 5.7 ad 8.0 con più di 512.000 tabelle potrebbe richiedere molto tempo e scadere.
• L'upgrade delle istanze da MySQL 8.0 a 8.4 con più di 512.000 tabelle potrebbe richiedere molto tempo e scadere.

• Quando esegui l'upgrade da MySQL 8.0 a 8.4, se hai eseguito l'upgrade di una replica a MySQL 8.4, ma non dell'istanza principale, è possibile creare un nuovo account utente in un'istanza principale di cui non è stato eseguito l'upgrade con il plug-in di autenticazione mysql_native_password deprecato. Per evitare questa situazione, assicurati di eseguire l'upgrade dell'istanza principale immediatamente dopo l'upgrade delle repliche oppure crea solo nuovi account utente nell'istanza principale utilizzando il seguente comando.

  CREATE USER USERNAME'@'% IDENTIFIED WITH caching_sha2_password BY 'PASSWORD';

  Sostituisci USERNAME e PASSWORD con i valori appropriati.

Domande frequenti

Quando esegui l'upgrade della versione principale del database, potrebbero essere visualizzate le seguenti domande.

La mia istanza non è disponibile durante un upgrade?

Sì. L'istanza rimane non disponibile per un determinato periodo di tempo mentre Cloud SQL esegue l'upgrade.

Quanto tempo richiede un upgrade?

L'upgrade di una singola istanza richiede in genere meno di 10 minuti. Se la configurazione dell'istanza utilizza un numero ridotto di vCPU o memoria, l'upgrade potrebbe richiedere più tempo.

Se l'istanza ospita troppi database o tabelle oppure i database sono molto grandi, l'upgrade potrebbe richiedere ore o addirittura scadere perché il tempo di upgrade corrisponde al numero di oggetti nei database. Se hai più istanze di cui eseguire l'upgrade, il tempo totale dell'upgrade aumenta proporzionalmente.

Posso monitorare ogni passaggio della procedura di upgrade?

Sebbene Cloud SQL ti consenta di monitorare se un'operazione di upgrade è ancora in corso, non puoi monitorare i singoli passaggi di ogni upgrade.

Posso annullare l'upgrade dopo averlo avviato?

No, non puoi annullare un upgrade una volta avviato. Se l'upgrade non va a buon fine, Cloud SQL recupera automaticamente l'istanza nella versione precedente.

Cosa succede alle mie impostazioni durante un upgrade?

Quando esegui un upgrade in situ della versione principale, Cloud SQL conserva le impostazioni del database, tra cui il nome dell'istanza, l'indirizzo IP, i valori dei flag configurati in modo esplicito e i dati utente. Tuttavia, il valore predefinito delle variabili di sistema potrebbe cambiare. Ad esempio, il valore predefinito del flag character_set_server in MySQL 5.7 è utf8. Quando esegui l'upgrade a MySQL 8.0, il valore predefinito del flag diventa utf8mb4. Per ripristinare il valore utf8, reimposta il valore del flag sul valore precedente.

Per scoprire di più, consulta la sezione Configurare i flag di database. Se un determinato valore o flag non è più supportato nella versione di destinazione, Cloud SQL lo rimuove automaticamente durante l'upgrade.

Cosa posso fare se la replica si interrompe dopo l'upgrade della replica?

Se la replica si interrompe dopo l'upgrade della replica, viene eseguito il rollback alla versione MySQL dell'istanza principale. Puoi eseguire di nuovo l'upgrade della replica, ma se il problema persiste, la replica potrebbe interrompersi di nuovo.

Se il rollback della replica non viene eseguito, hai due opzioni:

1. Elimina la replica danneggiata, crea una nuova replica ed esegui l'upgrade della nuova replica.

   Se l'upgrade non va a buon fine di nuovo, è probabile che sia causato da modifiche incompatibili aggiunte all'istanza principale durante l'upgrade. Risolvi i problemi di upgrade per individuare il problema, correggi l'istanza principale e prova a eseguire l'upgrade della replica. Per ulteriori informazioni, consulta la sezione Risoluzione dei problemi.

2. Esegui l'upgrade dell'istanza principale

   L'operazione di upgrade nell'istanza principale ricrea le repliche se il thread di replica non funziona.

Perché la replica di cui è stato eseguito l'upgrade è rollback alla versione precedente?

Se un upgrade non va a buon fine, viene eseguito il rollback della replica alla versione dell'istanza principale. Puoi eseguire di nuovo l'upgrade della replica, ma se il problema persiste, puoi controllare il log mysql.err sulla replica per trovare l'origine. Cerca parole chiave come [REPL]... failed executing transaction.... end_log_pos...; Failure Reason.

Se il messaggio di errore contiene Access denied for AuthId.... con modifiche ai privilegi utente, è probabile che una query venga eseguita utilizzando i privilegi utente di MySQL 5.7 negli schemi mysql e sys e potrebbe non riuscire a causa delle modifiche ai sistemi di sicurezza e gestione degli account in MySQL 8.0. Per risolvere il problema, devi interrompere le query sull'istanza principale prima di eseguire l'upgrade dell'istanza principale alla nuova versione e poi riprovare l'upgrade della replica. Cloud SQL consiglia di interrompere temporaneamente anche tutte queste query nell'istanza principale prima di eseguire l'upgrade alla nuova versione, in quanto potrebbe verificarsi un problema simile.

Se non vedi il motivo dell'errore, ad esempio Access denied for AuthID.... nei log di MySQL, è probabile che il problema sia causato da nuovi dati incompatibili che potrebbero essere stati aggiunti all'istanza principale dopo l'upgrade della replica. Consulta la sezione Prepararsi a un upgrade a una versione principale per scoprire come risolvere i problemi di incompatibilità prima di eseguire di nuovo l'upgrade.

Passaggi successivi

• Scopri le opzioni per connetterti a un'istanza.
• Scopri di più sull'importazione e sull'esportazione dei dati.
• Scopri di più sull'impostazione dei flag di database.