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 dell'istanza Cloud SQL in loco anziché eseguendo 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 adotta le nuove versioni dopo il loro rilascio. Dopo che 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 loco o eseguendo la migrazione dei dati. Gli upgrade in loco 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 loco, puoi mantenere il nome, l'indirizzo IP e altre impostazioni dell'istanza corrente dopo l'upgrade. Gli upgrade in loco non richiedono lo spostamento dei file di dati e possono essere completati più rapidamente. In alcuni casi, il tempo di inattività è inferiore a quello richiesto dalla migrazione dei dati.

Pianifica un upgrade della versione principale

1. Verifica di disporre del ruolo richiesto per eseguire un upgrade della versione principale: Cloud SQL Owner o Cloud SQL Admin.

2. Scegli una versione principale di destinazione.

   gcloud

   Per informazioni sull'installazione e su come iniziare a utilizzare gcloud CLI, consulta Installa gcloud CLI. Per informazioni sull'avvio di Cloud Shell, consulta Utilizza Cloud Shell.

   Per controllare le versioni del database che puoi scegliere come target per un upgrade in loco sulla tua istanza, segui questi passaggi:

   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 con l'etichetta upgradableDatabaseVersions.
   3. Ogni sottosezione restituisce una versione del database disponibile per l'upgrade. In ogni sottosezione, esamina i seguenti campi.
   • majorVersion: la versione principale che puoi scegliere come target per l'upgrade in loco.
   • name: la stringa della versione del database che include la versione principale. Per Cloud SQL per MySQL, questo campo include anche la versione secondaria del database.
   • displayName: il nome visualizzato della versione del database.

   REST v1

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

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

   • 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 verificare quali versioni del database di destinazione sono disponibili per l'upgrade 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 sostituzioni seguenti:

   • 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 policy per le versioni.

3. Considera le funzionalità offerte in ogni versione principale del database e risolvi le incompatibilità.

   • MySQL 9.7
   • 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 poter eseguire l'upgrade dell'istanza del database, consulta le note di rilascio della versione principale di destinazione per determinare le incompatibilità che devi 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 di character_set_server cambia in utf8mb4. Per ripristinare utf8, devi modificare manualmente il valore del flag di database impostandolo sul valore precedente. Per saperne di più, consulta Configura i flag di database. La maggior parte delle modifiche ai valori predefiniti viene eseguita dalla community MySQL (scopri di più in Upgrade Server Defaults).

4. Esegui il controllo preliminare per gli upgrade.

5. Testa l'upgrade con un dry run.

   Esegui un dry run 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 il processo di upgrade.

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

6. Decidi quando eseguire l'upgrade.

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

Preparati a un upgrade della versione principale

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

1. Se esegui l'upgrade da MySQL 8.0 a MySQL 8.4, tutti i nuovi utenti che crei dopo l'upgrade utilizzano il plug-in di autenticazione caching_sha2_password anziché il plug-in mysql_native_password deprecato. Puoi anche aggiornare gli account utente esistenti per utilizzare il plug-in di autenticazione caching_sha2_password. 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 del database di autenticazione integrato che stai aggiornando.

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

   Gli upgrade della versione principale richiedono spazio su disco e memoria aggiuntivi per archiviare le tabelle aggiornate e il nuovo dizionario dei dati. Se lo spazio su disco è insufficiente, l'upgrade non va a buon fine e viene eseguito il rollback alla versione originale. Cloud SQL consiglia di avere almeno 100 KB di memoria per ogni tabella.

Configurazione richiesta per l'utilizzo di MySQL 8.4 o versioni successive con Cloud SQL Auth Proxy

Quando utilizzi MySQL 8.4 o versioni successive con il proxy di autenticazione Cloud SQL, devi configurare la configurazione del database dell'applicazione con l'impostazione di configurazione MySQL allowPublicKeyRetrieval=true. Devi eseguire l'upgrade delle applicazioni client con questa configurazione prima di eseguire l'upgrade della versione del database.

Ad esempio, se utilizzi il client mysql, utilizza il flag --get-server-public-key:

mysql -u username -p --get-server-public-key

Se utilizzi il linguaggio di programmazione Java, utilizza quanto segue:

config.setJdbcUrl("jdbc:mysql://" + dbHost + ":" + dbPort + "/" + dbName);
config.addDataSourceProperty("allowPublicKeyRetrieval", "true");

Valuta l'idoneità all'upgrade della tua istanza

Cloud SQL ti consente di eseguire un controllo preliminare sulla tua istanza prima di un upgrade alla versione principale. Questo controllo preliminare è un'operazione a lunga esecuzione (LRO) che verifica se l'istanza è pronta per l'upgrade. Aiuta a trovare potenziali problemi come incompatibilità, problemi di configurazione o problemi relativi ai dati prima dell'operazione di upgrade.

Cloud SQL può eseguire il processo di controllo preliminare in parallelo con il tuo workload. L'esecuzione del controllo preliminare prima di eseguire l'upgrade della versione principale può aiutare a evitare un errore di upgrade.

Quando esegui il controllo preliminare, si verifica una delle seguenti situazioni:

• Nessun problema rilevato: il controllo preliminare è stato completato correttamente e non sono stati rilevati problemi.
• Problemi rilevati: il controllo preliminare è stato completato correttamente, ma ha rilevato errori che bloccheranno l'upgrade. I problemi devono essere risolti prima dell'upgrade.
• Avvisi trovati: il controllo preliminare è stato completato correttamente e sono stati trovati avvisi. Esamina gli avvisi. Ti consigliamo di risolvere eventuali problemi prima di procedere con l'upgrade.

A seconda dei risultati del controllo preliminare, puoi procedere con l'upgrade o risolvere i problemi identificati prima di eseguirlo.

Limitazioni

Quando utilizzi il controllo preliminare dell'upgrade della versione principale, tieni presente le seguenti limitazioni:

• Lo stato dell'istanza deve essere impostato su RUNNING.

• L'istanza non deve avere operazioni di blocco in attesa. Se è in attesa un'operazione di blocco, il controllo preliminare genera un errore con il seguente messaggio:

  Operation failed because another operation was already in progress. Try
  your request after the current operation is complete.
  

• Il controllo preliminare deve connettersi a tutti i database dell'istanza. Se un database è inaccessibile, bloccato o non risponde, il controllo preliminare potrebbe non riuscire o mostrare errori. Ti consigliamo di eseguire il controllo preliminare quando il carico del database è basso.

• Il controllo preliminare verifica la compatibilità dell'upgrade tra versioni principali consecutive di Cloud SQL per MySQL. Ad esempio, puoi eseguire il controllo preliminare per l'upgrade tra MySQL 5.7 e MySQL 8.0, l'upgrade tra MySQL 8.0 e MySQL 8.4, quindi l'upgrade tra MySQL 8.4 e MySQL 9.7.

  Il controllo preliminare non supporta il controllo di un upgrade della versione secondaria all'interno della stessa versione principale. Ad esempio, non puoi eseguire un controllo preliminare per un upgrade da MySQL 8.0.31 a 8.0.45.

• Il pre-controllo è limitato a tre ore. Se l'operazione di controllo preliminare supera il limite di tre ore, il processo scade e viene annullato automaticamente.

• L'utilità di controllo dell'upgrade di MySQL Shell potrebbe non rilevare tutte le incompatibilità durante il processo di controllo preliminare. È comunque possibile che l'upgrade non vada a buon fine. È anche possibile che alcuni avvisi non risolti blocchino l'upgrade a una versione principale.

Prima di iniziare

• Assicurati che l'API Cloud SQL Admin sia abilitata per la tua istanza.
• Verifica di avere l'autorizzazione IAM cloudsql.instances.preCheckMajorVersionUpgrade.

Esegui il controllo preliminare

Per eseguire il controllo preliminare dell'upgrade della versione principale, segui questi passaggi:

Esamina i risultati del controllo preliminare

Al termine del controllo preliminare, l'istanza è pronta per l'upgrade o presenta problemi che richiedono la tua attenzione.

Pronto per l'upgrade

Se il controllo preliminare viene completato correttamente e l'array preCheckResponse è vuoto, significa che non sono stati rilevati problemi o avvisi. L'istanza è pronta per l'upgrade della versione principale. Per continuare, consulta Esegui l'upgrade della versione principale.

Non pronto per l'upgrade

Se il controllo preliminare è stato eseguito correttamente e l'array preCheckResponse contiene problemi, l'istanza non è pronta per l'upgrade e richiede attenzione. I problemi identificati potrebbero bloccare o meno l'upgrade. Questi problemi sono indicati nel preCheckResponse con i seguenti tipi di messaggi:

Ogni tipo di problema include un campo message e un campo actions_required. Esamina ogni problema per comprenderne il tipo e come risolverlo. Per saperne di più sui problemi comuni e sulle relative soluzioni, consulta Errori comuni dei controlli preliminari per l'upgrade della versione principale.

Dopo aver risolto i problemi, esegui nuovamente il controllo preliminare per verificare che l'istanza sia pronta per l'upgrade. Poi, procedi con l'upgrade dell'istanza una volta completato il controllo preliminare.

Annulla un controllo preliminare dell'upgrade della versione principale

Puoi annullare un'operazione di controllo preliminare dell'upgrade della versione principale per Cloud SQL per MySQL.

Prima di iniziare

Per annullare il controllo preliminare dell'upgrade alla versione principale, devi avere l'ID dell'operazione di controllo preliminare. Devi specificare questo ID nel comando gcloud o dell'API REST in modo che Cloud SQL sappia quale operazione annullare.

L'ID operazione viene restituito nel campo name della risposta.

Puoi anche trovare l'ID operazione effettuando una chiamata operations.list sull'istanza Cloud SQL.

Esegui l'annullamento

Puoi utilizzare i comandi gcloud o dell'API REST per annullare un'operazione di pre-controllo.

Controlla lo stato di annullamento

Puoi utilizzare i comandi gcloud o dell'API REST per controllare lo stato di un'operazione di pre-controllo annullata.

Risolvi i problemi di annullamento

Esegui l'upgrade della versione principale

Puoi eseguire l'upgrade della versione principale di una singola istanza Cloud SQL o di un'istanza principale e includere nell'upgrade tutte le sue repliche, incluse le repliche in cascata e tra regioni.

Esegui l'upgrade della versione principale di una singola istanza

Quando avvii un'operazione di upgrade per una singola istanza, Cloud SQL esegue le seguenti operazioni:

1. Controlla la configurazione dell'istanza per assicurarsi che sia compatibile con un upgrade.
2. Dopo che Cloud SQL ha verificato la configurazione, Cloud SQL rende l'istanza non disponibile.
3. Esegue un backup pre-upgrade.
4. Esegue l'upgrade dell'istanza.
5. Rende disponibile l'istanza.
6. Esegue un backup post-upgrade.

resource "google_sql_database_instance" "default" {
  name             = "mysql-instance"
  region           = "us-central1"
  database_version = "MYSQL_8_0"
  settings {
    tier = "db-n1-standard-2"
  }
}

Quando effettui una richiesta di upgrade sul posto, Cloud SQL esegue prima 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. Consulta anche Risolvi i problemi relativi a un upgrade della versione principale.

Includi le repliche nell'upgrade della versione principale

Se l'istanza principale ha delle repliche, puoi includerle tutte nell'upgrade. Cloud SQL può eseguire l'upgrade di tutte le repliche dell'istanza principale, incluse le repliche tra regioni e le repliche a cascata.

Quando includi le repliche in un upgrade della versione principale, Cloud SQL esegue le seguenti operazioni:

1. Controlla la configurazione dell'istanza principale e delle repliche per assicurarsi che siano compatibili per un upgrade.
2. Rende non disponibile l'istanza principale.
3. Esegue un backup pre-upgrade dell'istanza principale.
4. Interrompe la replica per tutte le repliche.
5. Esegue l'upgrade sull'istanza principale.
6. Se l'upgrade dell'istanza principale va a buon fine, l'istanza principale diventa nuovamente disponibile e riavvia la replica.
7. Cloud SQL esegue un backup post-upgrade dell'istanza principale.
8. Cloud SQL procede con l'upgrade di tutte le repliche.

Anche se l'upgrade della versione principale di una replica non va a buon fine, l'istanza principale continua a essere disponibile.

Per includere le repliche in un upgrade della versione principale, non puoi utilizzare la consoleCloud de Confiance o Terraform. Puoi utilizzare solo gcloud CLI o l'API Cloud SQL Admin.

Backup degli upgrade automatici

Quando esegui un upgrade della 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 di iniziare l'upgrade. Puoi utilizzare questo backup per ripristinare l'istanza del database allo stato della versione precedente.
• Il secondo backup di upgrade è il backup post-upgrade, che viene eseguito immediatamente dopo che sono consentite nuove scritture nell'istanza del database di cui è stato eseguito l'upgrade.

Quando visualizzi l'elenco dei backup, i backup di 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. Se esegui l'upgrade da MySQL 8.4 a MySQL 9.7, il backup pre-upgrade è etichettato come Pre-upgrade backup, MYSQL_8_4 to MYSQL_9_7. e il backup post-upgrade come Post-upgrade backup, MYSQL_9_7 from MYSQL_8_4.

Come per gli altri backup on demand, i backup di upgrade vengono conservati fino a quando non li elimini o non elimini l'istanza. Se hai attivato il PITR, non puoi eliminare i backup di upgrade mentre si trovano nella finestra di conservazione. Se devi eliminare i backup dell'upgrade, devi disattivare il PITR o attendere che i backup dell'upgrade non rientrino più nella finestra di conservazione.

Completa l'upgrade della versione principale

1. Esegui test di accettazione.

   Esegui dei test per verificare che il sistema aggiornato funzioni come previsto.

2. (Facoltativo) Aggiorna i privilegi utente.

   MySQL 8.0 presenta nuove modifiche ai sistemi di sicurezza e di gestione degli account. Per saperne di più, consulta Novità di MySQL 8.0.

   Cloud SQL per MySQL ha adottato queste modifiche e ha migliorato i privilegi utente associati al ruolo cloudsqlsuperuser. Gli utenti creati nella versione MySQL 5.7 dell'istanza potrebbero non avere gli stessi privilegi degli utenti creati direttamente in MySQL 8.0. Ad esempio, gli utenti che eseguono l'upgrade da MySQL 5.7 a MySQL 8.0 non dispongono del privilegio CONNECTION_ADMIN. Di conseguenza, non possono eseguire il comando KILL sulle sessioni di altri utenti. Per scoprire come aggiornare i privilegi utente, consulta la procedura in questa sezione.

   Se esegui l'upgrade da MySQL 8.0 a MySQL 8.4, vengono apportate ulteriori modifiche ai privilegi utente, tra cui l'aggiunta di privilegi introdotti in MySQL 8.4 e la rimozione di privilegi esistenti in MySQL 8.0. Per saperne di più, consulta Privilegi utente di MySQL 8.4 (cloudsqlsuperuser).

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

   1. Crea un utente con il ruolo cloudsqlsuperuser concesso per impostazione predefinita.

   2. Utilizza questo utente per connetterti all'istanza in modo da poter aggiornare i privilegi di altri utenti.

      Ad esempio, per controllare i privilegi di cui dispongono gli utenti, esegui questo comando:

      SHOW GRANTS for 'admin'@'%',

      Per concedere privilegi a un utente, ad esempio il privilegio di utilizzare il comando KILL per terminare le connessioni, esegui questo comando:

      GRANT CONNECTION_ADMIN ON *.* to 'admin'@'%';

      Per applicare il ruolo cloudsqlsuperuser all'utente admin'@'%, esegui questo comando:

      GRANT 'cloudsqlsuperuser' to 'admin'@'%';

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 in modo da poter recuperare il database, se necessario.

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

Risolvi i problemi relativi all'upgrade della versione principale

Cloud SQL restituisce un messaggio di errore se tenti di 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 log degli errori

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, utilizza la console Cloud de Confiance by S3NS:

1. Nella console Cloud de Confiance , 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 nel seguente modo:

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

   Per saperne di più sui filtri delle query, consulta 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 di query:

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

   Puoi esaminare tutti i log segnalati in un determinato periodo di tempo o filtrarli in base alla gravità. Un'opzione comune per la risoluzione dei problemi potrebbe includere la selezione dei seguenti filtri:

   • Emergenza
   • Avviso
   • Critico
   • Errore

   Durante il controllo preliminare e l'upgrade dalla versione MySQL 5.7 a MySQL 8.0, potresti riscontrare alcuni problemi noti. Per assistenza nella risoluzione di questi problemi, consulta Risoluzione dei problemi relativi all'upgrade della versione principale in loco a MySQL 8.0.

Operazione MVU in esecuzione per un periodo di tempo più lungo

Esistono due attività di base associate a un upgrade della versione principale:

• Operazione di controllo preliminare: restituisce un errore di timeout se non viene completata entro tre ore.
• Operazione di upgrade: restituisce un errore di timeout se non viene completata entro sei ore.

Se l'istanza ha un'operazione MAJOR_VERSION_UPGRADE in corso per un periodo di tempo più lungo del previsto, esamina i log degli errori di MySQL. Ciò potrebbe essere dovuto a problemi comuni, ad esempio:

• Un numero elevato di tabelle, viste o indici
• Risorse insufficienti, ad esempio CPU o memoria
• Transazioni principali che bloccano l'arresto dei database per l'avvio del processo di upgrade. Puoi utilizzare la console Cloud de Confiance per controllare i processi in corso.

Errori comuni dei controlli preliminari per l'upgrade della versione principale

I problemi comuni riscontrati negli upgrade da MySQL 5.7 a MySQL 8.0 possono includere:

• Aggiunta di nuove parole chiave riservate, come RANKS, GROUPS, FUNCTION, in stored procedure, trigger e altri oggetti del database. Per saperne di più, consulta Parole chiave e parole riservate.
• Caratteri UTF non validi nelle definizioni delle tabelle.
• Transazioni XA non sottoposte a commit che devono essere sottoposte a commit (utilizzando l'istruzione XA COMMIT) o di cui deve essere eseguito il rollback (utilizzando l'istruzione XA ROLLBACK).
• Vincolo di chiave esterna nei nomi più lunghi di 64 caratteri.
• Tipo di dati spaziali in un indice misto di colonne. Per saperne di più, consulta Tipo di dati spaziali.

Per assistenza nella risoluzione degli errori e dei problemi noti durante il controllo preliminare di MySQL 5.7 a MySQL 8.0, consulta Risoluzione dei problemi relativi all'upgrade della versione principale in loco a MySQL 8.0. Per ulteriori informazioni sui problemi comuni di MySQL, consulta Preparazione dell'installazione per l'upgrade ed Esegui l'upgrade a MySQL 8.0?.

I problemi comuni riscontrati negli upgrade da MySQL 8.0 a MySQL 8.4 possono includere:

• Terminologia di replica obsoleta. I termini MASTER e SLAVE sono stati 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.

I problemi comuni riscontrati negli upgrade da MySQL 8.4 a MySQL 9.7 possono includere:

• Se hai attivato cloudsql_vector per la tua istanza, non puoi avere un indice secondario non vettoriale su una colonna che contiene vector embedding di Cloud SQL prima dell'upgrade. Potresti ricevere il seguente messaggio di errore:

  Non-vector secondary indexes are disallowed on vector columns when cloudsql_vector is enabled.

  Per risolvere il problema, elimina l'indice secondario prima di eseguire l'upgrade a MySQL 9.7.

• Hai vector embedding esistenti nel tuo database Cloud SQL 8.4, ma hai impostato cloudsql_vector su off. Nell'ambito dell'upgrade a MySQL 9.7, viene eseguita la migrazione di tutti i dati vettoriali al formato MySQL della community anziché al formato VARBINARY utilizzato dai database Cloud SQL per MySQL 8.4 e versioni precedenti. Per assicurarti che i dati vettoriali vengano migrati correttamente, puoi aggiornare il flag cloudsql_vector impostandolo su on e procedere con l'upgrade a MySQL 9.7. Il processo di upgrade esegue la migrazione dei dati vettoriali al formato basato sulla community. In alternativa, puoi mantenere il flag cloudsql_vector impostato su off ed eliminare manualmente i dati vettoriali nel database MySQL 8.4 prima di eseguire l'upgrade.
• Hai ancora account utente del database integrato che utilizzano il plug-in mysql_native_password. Il plug-in viene rimosso completamente da Cloud SQL per MySQL 9.7. Se un account utente utilizza il plug-in mysql_native_password, non può connettersi al tuo database. Prima di eseguire l'upgrade a Cloud SQL per MySQL 9.7, devi modificare tutti gli account rimanenti in modo che utilizzino il plug-in caching_sha2_password.

Ripristina l'istanza principale alla versione principale precedente

Se il sistema di database di cui è stato eseguito l'upgrade non funziona come previsto, potresti dover ripristinare l'istanza principale alla versione precedente. Per farlo, 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 di un'istanza principale, segui questi passaggi:

1. Identifica il backup precedente all'upgrade.

   Consulta Backup automatici degli upgrade.

2. Crea un'istanza di recupero.

   Crea una nuova istanza Cloud SQL utilizzando la versione principale di Cloud SQL in esecuzione al momento della creazione del backup pre-upgrade. Imposta gli stessi flag e le stesse impostazioni dell'istanza utilizzati 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 utilizzi repliche di lettura, aggiungile singolarmente.

5. Connetti la tua 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 gestione del traffico sulla versione del database precedente all'upgrade.

Limitazioni

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

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

• Quando esegui l'upgrade da MySQL 8.0 a MySQL 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 su un'istanza principale non aggiornata 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 o crea nuovi account utente nell'istanza principale solo utilizzando il comando seguente.

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

  Sostituisci USERNAME e PASSWORD con i valori appropriati.

Domande frequenti

Le seguenti domande potrebbero sorgere durante l'upgrade della versione principale del database.

La mia istanza non è disponibile durante un upgrade?

Sì. L'istanza rimane non disponibile per un periodo di tempo durante il quale Cloud SQL esegue l'upgrade.

Quanto tempo richiede un upgrade?

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

Se l'istanza ospita troppi database o tabelle o se i database sono molto grandi, l'upgrade potrebbe richiedere ore o addirittura scadere, perché il tempo totale dell'upgrade corrisponde al numero di oggetti nei database. Se devi eseguire l'upgrade di più istanze, il tempo di upgrade aumenta proporzionalmente. Se includi le repliche nell'upgrade, l'operazione di upgrade può richiedere fino a un'ora, a seconda del numero di repliche dell'istanza principale.

Posso monitorare ogni passaggio del processo 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 ripristina automaticamente l'istanza alla versione precedente.

Cosa succede alle mie impostazioni durante un upgrade?

Quando esegui un upgrade della versione principale in loco, Cloud SQL conserva le impostazioni del database, inclusi il nome dell'istanza, l'indirizzo IP, i valori dei flag configurati esplicitamente 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 cambia in utf8mb4. Per ripristinare utf8, imposta il flag sul valore precedente.

Per scoprire di più, consulta Configura i flag di database. Se un determinato flag o valore 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 di una replica?

Se la replica si interrompe dopo l'upgrade di una replica, Cloud SQL esegue il rollback della replica alla versione principale di MySQL dell'istanza principale. Puoi eseguire nuovamente l'upgrade della replica, ma se il problema persiste, la replica potrebbe interrompersi di nuovo. Per questo motivo, ti consigliamo di includere le repliche quando esegui l'upgrade della versione principale, anziché eseguire l'upgrade di ogni replica separatamente.

Se non viene eseguito il rollback della replica alla stessa versione principale dell'istanza principale, hai due opzioni:

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

   Se l'upgrade non va a buon fine, è probabile che ciò sia dovuto a modifiche incompatibili aggiunte all'istanza principale durante l'upgrade. Risolvi i problemi dell'upgrade per individuare il problema, correggi l'istanza principale e prova a eseguire l'upgrade della replica. Per saperne di più, consulta la sezione Risoluzione dei problemi.

2. Esegui l'upgrade dell'istanza principale

   Se il thread della replica non funziona, l'operazione di upgrade sull'istanza principale ricrea le repliche.

Perché è stato eseguito il rollback della mia replica di cui è stato eseguito l'upgrade alla versione principale precedente?

Se un upgrade non va a buon fine, viene eseguito il rollback della replica alla versione dell'istanza principale. Puoi eseguire nuovamente 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 venga eseguita una query utilizzando i privilegi utente di MySQL 5.7 sugli schemi mysql e sys e che l'operazione non vada a buon fine 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, quindi riprovare l'upgrade della replica. Cloud SQL consiglia di interrompere temporaneamente tutte queste query anche nell'istanza principale prima di eseguire l'upgrade alla nuova versione, poiché 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 Preparati per un upgrade della versione principale per scoprire come risolvere i problemi di incompatibilità prima di eseguire nuovamente 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.