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 sul posto anziché eseguendo la migrazione dei dati.

Introduzione

I fornitori di software di database rilasciano periodicamente nuove versioni principali che contengono nuove funzionalità, miglioramenti delle prestazioni e della sicurezza. Cloud SQL accetta 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 sul posto o tramite la migrazione dei dati. Gli upgrade in loco sono un modo più semplice per eseguire l'upgrade della versione principale dell'istanza. Non devi migrare i dati o modificare le stringhe di connessione dell'applicazione. Con gli upgrade in loco, puoi conservare il nome, l'indirizzo IP e altre impostazioni dell'istanza corrente dopo l'upgrade. Gli upgrade sul posto 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 per la migrazione dei dati.

Per MySQL 8.0.15 e versioni precedenti, l'operazione di upgrade in loco di MySQL utilizza l'utilità mysql_upgrade. Per MySQL 8.0.16 e versioni successive, l'operazione di upgrade in loco di MySQL viene gestita dal processo MySQL server. Per ulteriori informazioni sull'operazione di upgrade in loco, consulta Elementi aggiornati dalla procedura di upgrade di MySQL.

Pianificare un upgrade della versione principale

  1. Verifica di disporre del ruolo necessario per eseguire un upgrade della versione principale: Proprietario Cloud SQL o Amministratore Cloud SQL.

  2. Scegli una versione principale di destinazione.

    gcloud

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

    Per controllare le versioni del database a cui puoi fare riferimento per un upgrade in loco sulla tua istanza:

    1. Esegui questo comando.
      2. 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, esamina i seguenti campi.
      • majorVersion: la versione principale a cui puoi fare riferimento per l'upgrade sul posto.
      • 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 per la versione del database.

    REST v1

    Per controllare 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:

    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 sul posto 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:

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

    Le nuove versioni principali introducono modifiche incompatibili che potrebbero richiedere di modificare il codice dell'applicazione, lo schema o le impostazioni del database. Prima di poter eseguire l'upgrade dell'istanza di database, esamina 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 riportandolo al valore precedente. Per saperne di più, consulta Configura i flag di database. La maggior parte delle modifiche ai valori predefiniti viene apportata 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 una prova generale 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 test per assicurarti che l'applicazione si comporti come previsto nel database aggiornato.

  6. Decidi un orario per l'upgrade.

    L'upgrade richiede che l'istanza non sia disponibile per un periodo di tempo. Pianifica l'upgrade durante 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, aggiorna il plug-in di autenticazione dei tuoi account utente esistenti in modo che utilizzi il plug-in di autenticazione caching_sha2_password anziché il plug-in mysql_native_password ritirato. 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 integrata che stai aggiornando.

  2. Controlla 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 aggiornate e il nuovo dizionario dei dati. Lo spazio su disco insufficiente causa l'esito negativo dell'upgrade e il rollback alla versione originale. Cloud SQL consiglia di avere un minimo di 100 KB di memoria per ogni tabella.

Configurazione richiesta per l'utilizzo di MySQL 8.4 o versioni successive con il proxy di autenticazione Cloud SQL

Quando utilizzi MySQL 8.4 o versioni successive con Cloud SQL Auth Proxy, devi configurare la configurazione del database dell'applicazione con l'impostazione di configurazione di 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 la preparazione all'upgrade della tua istanza

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

Il controllo preliminare esegue l'utilità di controllo dell'upgrade di MySQL Shell per verificare se la tua istanza è pronta per un upgrade alla versione principale successiva. Se l'istanza non è pronta, l'utilità elenca i problemi che devi risolvere prima di iniziare l'upgrade. Questi problemi sono dovuti a incompatibilità note tra le due versioni principali.

Cloud SQL può eseguire il processo di controllo preliminare in parallelo con il tuo workload. L'esecuzione del controllo preliminare prima di eseguire un upgrade alla versione principale può contribuire a evitare errori di upgrade.

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

  • Nessun problema rilevato: il controllo preliminare è terminato correttamente e non sono stati rilevati problemi.
  • Problemi trovati: il controllo preliminare è stato completato correttamente, ma sono stati rilevati 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. Controlla 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 dell'upgrade.

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 e poi l'upgrade tra MySQL 8.4 e MySQL 9.7.

    Il controllo preliminare non supporta la verifica 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 precheck è limitato a tre ore. Se l'operazione di pre-controllo 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 la procedura di precontrollo. È comunque possibile che l'upgrade non vada a buon fine. È anche possibile che alcuni avvisi non risolti blocchino un upgrade della versione principale.

Prima di iniziare

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

Esegui il precontrollo

Per eseguire il controllo preliminare dell'upgrade della versione principale:

gcloud

  1. Utilizza gcloud beta sql instances pre-check-major-version-upgrade per eseguire il controllo preliminare:

    gcloud beta sql instances pre-check-major-version-upgrade INSTANCE_NAME \
  --target-database-version=TARGET_DATABASE_VERSION \
  --project=PROJECT_ID \
  [--async]

    Sostituisci quanto segue:

    • INSTANCE_NAME: il nome dell'istanza
    • TARGET_DATABASE_VERSION: la versione principale a cui vuoi eseguire l'upgrade dell'istanza. Per trovare la versione del database, vedi Pianificare un upgrade.
    • PROJECT_ID: l'ID del tuo Google Cloud progetto.

    (Facoltativo) Utilizza il flag --async per eseguire il comando in modo asincrono.

  2. Se utilizzi il flag --async per eseguire il comando pre-check-major-version-upgrade in modo asincrono, procedi nel seguente modo:

    1. Ottieni il nome dell'operazione di precontrollo:

      Utilizza il comando gcloud sql operations list con il flag --instance:

      gcloud sql operations list --instance=INSTANCE_NAME

      Sostituisci quanto segue:

      • INSTANCE_NAME: il nome dell'istanza

    2. Monitora lo stato del controllo preliminare.

      Utilizza il comando gcloud sql operations describe:

      gcloud sql operations describe OPERATION_NAME

      Sostituisci quanto segue:

      • OPERATION_NAME: il nome dell'operazione di precontrollo recuperato nel passaggio precedente.
  3. Se non esegui il comando pre-check-major-version-upgrade in modo asincrono, attendi il completamento del controllo preliminare per visualizzare i risultati.

REST v1beta4

  1. Esegui il controllo preliminare.

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

    • PROJECT_ID: l'ID progetto
    • INSTANCE_ID: l'ID istanza
    • TARGET_DATABASE_VERSION: la versione principale a cui eseguire l'upgrade. Per trovare un elenco delle versioni del database disponibili, vedi Pianificare un upgrade.

    Metodo HTTP e URL: 

    POST https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID/preCheckMajorVersionUpgrade

    Corpo JSON della richiesta: 

    {
  "preCheckMajorVersionUpgradeContext": {
    "targetDatabaseVersion": "TARGET_DATABASE_VERSION"
  }
}

    Per inviare la richiesta, espandi una di queste opzioni:

    Dovresti ricevere una risposta JSON simile alla seguente:

    {
  "message": "Precheck description of finding",
  "message_type": "ERROR",
  "actions_required": [
    "Precheck action required to fix the finding"
  ]
}

  2. Ottieni il nome dell'operazione di precontrollo.

    Utilizza la richiesta GET con il metodo operations.list dopo aver sostituito PROJECT_ID con l'ID del progetto.

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

    Sostituisci quanto segue:

    • PROJECT_ID: l'ID del tuo Google Cloud progetto.

  3. Monitora lo stato del controllo preliminare.

    Utilizza la richiesta GET con il metodo operations.list:

    GET https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/operation/OPERATION_NAME

    Sostituisci quanto segue:

    • PROJECT_ID: l'ID del tuo Google Cloud progetto.
    • operation_name: il nome dell'operazione di precontrollo recuperato nel passaggio precedente.

Esaminare i risultati del controllo preliminare

Al termine del controllo preliminare, la tua istanza è pronta per l'upgrade oppure 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. La tua istanza è pronta per l'upgrade della versione principale. Per continuare, consulta Eseguire l'upgrade della versione principale.

Non pronto per l'upgrade

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

Tipo Descrizione Bloccare l'upgrade?
INFO Un messaggio informativo. No
WARNING È stato rilevato un potenziale problema. Cloud SQL consiglia di esaminare e risolvere l'avviso prima di eseguire l'upgrade per garantire la piena compatibilità. Sì
ERROR È stato rilevato un problema critico che blocca l'upgrade. Questi problemi potrebbero causare l'esito negativo dell'upgrade. Devi risolverli prima di eseguire l'upgrade dell'istanza. Sì
Se la tua istanza ha solo messaggi INFO, puoi eseguirne l'upgrade, ma potresti riscontrare problemi dopo l'upgrade. Ti consigliamo di esaminare i dettagli del messaggio e risolvere il problema prima di eseguire l'upgrade. Se la tua istanza contiene messaggi ERROR o WARNING, devi risolvere questi problemi prima di eseguire l'upgrade.

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 di controllo preliminare dell'upgrade della versione principale.

Dopo aver risolto i problemi, esegui nuovamente il controllo preliminare per verificare che la tua istanza sia pronta per l'upgrade. Dopodiché, procedi con l'upgrade dell'istanza una volta che il controllo preliminare è stato superato.

Annullare 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 della versione principale, devi disporre dell'ID dell'operazione di controllo preliminare. Devi specificare questo ID nel comando gcloud o API REST in modo che Cloud SQL sappia quale operazione annullare.

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

Puoi trovare l'ID operazione anche 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 precontrollo.

gcloud

  1. Recupera l'ID operazione di precontrollo.

    Utilizza il comando gcloud sql operations list con il flag --instance:

    gcloud sql operations list --instance=INSTANCE_NAME

    Sostituisci quanto segue:

    • INSTANCE_NAME: il nome dell'istanza

  2. Annulla il precheck.

    Utilizza il comando gcloud sql operations cancel:

    gcloud sql operations cancel OPERATION_ID

    Sostituisci quanto segue:

    • OPERATION_ID: l'ID operazione recuperato nel passaggio precedente.

REST v1beta4

  1. Recupera l'ID operazione di precontrollo.

    Utilizza la richiesta GET con il metodo operations.list dopo aver sostituito PROJECT_ID con l'ID del progetto.

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

    Sostituisci quanto segue:

    • PROJECT_ID: l'ID del tuo Google Cloud progetto.

  2. Annulla il precheck.

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

    • PROJECT_ID: l'ID del tuo Google Cloud progetto.
    • OPERATION_ID: l'ID operazione recuperato nel passaggio precedente.

    Metodo HTTP e URL: 

    POST https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID/cancel

    Per inviare la richiesta, espandi una di queste opzioni:

    Dovresti ricevere una risposta JSON simile alla seguente:

    Questa chiamata API REST non restituisce alcuna risposta.

Controllare lo stato di annullamento

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

gcloud

  1. Controlla lo stato Annullato.

    Utilizza il comando gcloud sql operations describe:

    gcloud sql operations describe OPERATION_ID

    Sostituisci quanto segue:

    • OPERATION_ID: l'ID operazione del controllo preliminare annullato.

REST v1beta4

  1. Controlla lo stato Annullato.

    Utilizza la richiesta GET con il metodo operations.list:

    GET https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID

    Sostituisci quanto segue:

    • PROJECT_ID: l'ID del tuo Google Cloud progetto.
    • OPERATION_ID: l'ID operazione del controllo preliminare annullato.

Risolvere i problemi di annullamento

Problema Risoluzione dei problemi

Messaggio di errore: You can't cancel operation OPERATION_ID because this operation isn't in progress.

 Stai tentando di annullare un'operazione di precontrollo completata, non riuscita o già annullata. Se l'operazione è in esecuzione, puoi annullarla.

Messaggio di errore: You can't cancel operation OPERATION_ID because Cloud SQL doesn't support the cancellation of an OPERATION_TYPE operation.

 Questo errore si verifica in genere quando passi il OPERATION_ID errato al comando di annullamento, in particolare l'ID di un tipo di operazione che non supporta l'annullamento. Verifica di utilizzare OPERATION_ID associato al controllo preliminare dell'upgrade della versione principale che vuoi annullare.

Messaggio di errore: The OPERATION_TYPE operation isn't cancelled. Wait and retry in a few seconds.

 Al momento Cloud SQL non può annullare l'operazione di precontrollo. Riprova tra qualche secondo. Se il problema persiste, contatta l'assistenza clienti Google Cloud.

Esegui l'upgrade della versione principale

Puoi eseguire l'upgrade della versione principale di una singola istanza Cloud SQL oppure puoi eseguire l'upgrade della versione principale di un'istanza principale e includere tutte le relative repliche nell'upgrade, incluse le repliche in cascata e le repliche cross-region.

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 verifica la configurazione, l'istanza non è più disponibile.
  3. Esegue un backup pre-upgrade.
  4. Esegue l'upgrade dell'istanza.
  5. Rende disponibile l'istanza.
  6. Esegue un backup post-upgrade.
Quando esegui l'upgrade a MySQL 8.0, Cloud SQL esegue automaticamente il provisioning dell'istanza sulla versione secondaria predefinita.

Console

  1. Nella Google Cloud console, 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. Fai clic su Modifica.
  4. Nella sezione Informazioni istanza, fai clic sul pulsante Esegui l'upgrade e conferma che vuoi passare alla pagina di upgrade.
  5. Nella pagina Scegli una versione del database, fai clic sull'elenco Versione del database per l'upgrade e seleziona una delle versioni principali del database disponibili.
  6. Fai clic su Continua.
  7. Nella casella ID istanza, inserisci il nome dell'istanza e poi fai clic sul pulsante Avvia upgrade.
Il completamento dell'operazione richiede diversi minuti.

Verifica che la versione principale del database di cui è stato eseguito l'upgrade venga visualizzata sotto il nome dell'istanza nella pagina Panoramica dell'istanza.

gcloud

  1. Avvia l'upgrade.

    Utilizza il comando gcloud sql instances patch con il flag --database-version.

    Prima di eseguire il comando, sostituisci quanto segue:

    • INSTANCE_NAME: il nome dell'istanza.
    • DATABASE_VERSION: l'enumerazione per la versione principale del database, che deve essere successiva alla versione attuale. Specifica una versione del database per una versione principale disponibile come destinazione di upgrade per l'istanza. Puoi ottenere questo enum come primo passaggio del piano di upgrade. Se hai bisogno di un elenco completo degli enum delle versioni del database, consulta SqlDatabaseEnums.
    gcloud sql instances patch INSTANCE_NAME \
--database-version=DATABASE_VERSION

    Il completamento degli upgrade della versione principale richiede diversi minuti. Potresti visualizzare un messaggio che indica che l'operazione sta richiedendo più tempo del previsto. Puoi ignorare questo messaggio o eseguire il comando gcloud sql operations wait per chiuderlo.

  2. Recupera il nome dell'operazione di upgrade.

    Utilizza il comando gcloud sql operations list con il flag --instance.

    Prima di eseguire il comando, sostituisci quanto segue: * INSTANCE_NAME: il nome dell'istanza. 

    gcloud sql operations list --instance=INSTANCE_NAME

  3. Monitora lo stato dell'upgrade.

    Utilizza il comando gcloud sql operations describe.

    Prima di eseguire il comando, sostituisci la variabile OPERATION con il nome dell'operazione di upgrade recuperato nel passaggio precedente. 

    gcloud sql operations describe OPERATION

REST v1

  1. Avvia l'upgrade in loco.

    Utilizza una richiesta PATCH con il metodo instances:patch.

    Prima di utilizzare i dati della richiesta, sostituisci queste variabili:

    • PROJECT_ID: l'ID del progetto.
    • INSTANCE_NAME: il nome dell'istanza.

    Metodo HTTP e URL: 

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

    Corpo JSON della richiesta: 

    {
  "databaseVersion": DATABASE_VERSION
}

    Sostituisci DATABASE_VERSION con l'enumerazione per la versione principale del database, che deve essere successiva alla versione corrente. Specifica una versione del database per una versione principale disponibile come destinazione di upgrade per l'istanza. Puoi ottenere questo enum come primo passaggio del piano di upgrade. Se hai bisogno di un elenco completo degli enum delle versioni del database, consulta SqlDatabaseVersion.

  2. Recupera il nome dell'operazione di upgrade.

    Utilizza una richiesta GET con il metodo operations.list dopo aver sostituito PROJECT_ID con l'ID del progetto.

    Metodo HTTP e URL: 

    GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations

  3. Monitora lo stato dell'upgrade.

    Utilizza una richiesta GET con il metodo operations.get dopo aver sostituito le seguenti variabili:

    • PROJECT_ID: l'ID del progetto.
    • OPERATION_NAME: il nome dell'operazione di upgrade recuperato nel passaggio precedente.

    Metodo HTTP e URL: 

    GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operation/OPERATION_NAME

Terraform

Per eseguire l'upgrade della versione principale del database utilizzando Terraform, devi impostare l'argomento database_version nella definizione della risorsa google_sql_database_instance sulla versione principale di destinazione. Devi utilizzare il provider Terraform per Google Cloud la versione 4.34.0 o successive.

Gli esempi seguenti mostrano una configurazione google_sql_database_instance di base. Per eseguire l'upgrade della versione principale, imposta l'argomento database_version sulla versione principale pertinente.

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

Apporta le seguenti modifiche agli argomenti Terraform:

  • database_version: impostalo sulla versione principale di destinazione per l'upgrade.
  • deletion_protection: definisce la protezione Terraform di primo livello contro l'eliminazione delle istanze.
    • true: impedisce a Terraform di eliminare l'istanza. Qualsiasi operazione Terraform che prevede di eliminare questa risorsa viene bloccata.
    • false: consente a Terraform di eliminare l'istanza.

Esamina il piano Terraform

Prima di applicare qualsiasi modifica, esegui sempre terraform plan ed esamina attentamente l'output. I simboli accanto al nome della risorsa indicano come Terraform applicherà le modifiche:

  • ~ Aggiornamento sul posto: questo simbolo indica che Terraform modificherà l'istanza esistente. Questo è il risultato previsto e sicuro per un upgrade in loco della versione principale quando si modifica database_version.
  • +/- Ricrea (sostituzione forzata): questo simbolo indica che Terraform prevede di eliminare l'istanza attuale e crearne una nuova.
    • Se deletion_protection è impostato su true, Terraform genera un errore e blocca questa sostituzione pericolosa. Devi impostare esplicitamente deletion_protection = false nella configurazione ed eseguire di nuovo terraform apply per aggiornare lo stato, prima che un successivo apply consenta l'eliminazione e la ricreazione.
    • Se deletion_protection è impostato su false, terraform apply procederebbe con la perdita di dati.

    Le istanze possono essere pianificate per la sostituzione (eliminazione e ricreazione) a causa di una modifica della configurazione o di un percorso di upgrade non supportato per la modifica in loco. Se trovi un'istanza pianificata per l'eliminazione e la ricreazione, devi interrompere immediatamente l'operazione e indagare sul motivo della sostituzione pianificata prima che venga eseguita.

Dopo aver esaminato l'output di terraform plan per assicurarti che indichi solo un aggiornamento sul posto (~) per la modifica della versione del database, applica la configurazione

Per applicare la configurazione di Terraform in un progetto Google Cloud , completa i passaggi nelle sezioni seguenti.

Prepara Cloud Shell

  1. Avvia Cloud Shell.

  2. Imposta il progetto Google Cloud predefinito in cui vuoi applicare le configurazioni Terraform.

    Devi eseguire questo comando una sola volta per progetto e puoi eseguirlo in qualsiasi directory.

    export GOOGLE_CLOUD_PROJECT=PROJECT_ID

    Le variabili di ambiente vengono sostituite se imposti valori espliciti nel file di configurazione Terraform.

Preparare la directory

Ogni file di configurazione Terraform deve avere la propria directory (chiamata anche modulo radice).

  1. In Cloud Shell, crea una directory e un nuovo file al suo interno. Il nome file deve avere l'estensione .tf, ad esempio main.tf. In questo tutorial, il file viene chiamato main.tf. 
    mkdir DIRECTORY && cd DIRECTORY && touch main.tf

  2. Se stai seguendo un tutorial, puoi copiare il codice campione in ogni sezione o passaggio.

    Copia il codice campione nel main.tf appena creato.

    (Facoltativo) Copia il codice da GitHub. Questa opzione è consigliata quando lo snippet Terraform fa parte di una soluzione end-to-end.

  3. Rivedi e modifica i parametri di esempio da applicare al tuo ambiente.
  4. Salva le modifiche.
  5. Inizializza Terraform. Devi eseguire questa operazione una sola volta per directory. 
    terraform init

    (Facoltativo) Per utilizzare l'ultima versione del provider Google, includi l'opzione -upgrade: 

    terraform init -upgrade

Applica le modifiche

  1. Rivedi la configurazione e verifica che le risorse che Terraform creerà o aggiornerà corrispondano alle tue aspettative: 
    terraform plan

    Apporta le correzioni necessarie alla configurazione.

  2. Applica la configurazione Terraform eseguendo questo comando e inserendo yes al prompt: 
    terraform apply

    Attendi che Terraform visualizzi il messaggio "Apply complete!".

  3. Apri il tuo Google Cloud progetto per visualizzare i risultati. Nella console Google Cloud , vai alle risorse nell'interfaccia utente per assicurarti che Terraform le abbia create o aggiornate.

Quando invii una richiesta di upgrade sul posto, Cloud SQL esegue innanzitutto un controllo pre-upgrade. Se Cloud SQL determina che la tua 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 relativi a un upgrade della versione principale.

Includi le repliche nell'upgrade della versione principale

Se l'istanza principale ha 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 l'istanza e le repliche 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 sull'istanza primaria va a buon fine, l'istanza primaria torna disponibile e la replica viene riavviata.
  7. Cloud SQL esegue un backup post-upgrade dell'istanza principale.
  8. Cloud SQL procede all'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 consoleGoogle Cloud o Terraform. Puoi utilizzare solo gcloud CLI o l'API Cloud SQL Admin.

gcloud

  1. Avvia l'upgrade.

    Utilizza il comando gcloud sql instances patch con i flag --database-version e --include-replicas-for-major-version-upgrade.

    Prima di eseguire il comando, sostituisci quanto segue:

    • INSTANCE_NAME: il nome dell'istanza primaria.
    • DATABASE_VERSION: l'enumerazione per la versione principale del database, che deve essere successiva alla versione attuale. Specifica una versione del database per una versione principale disponibile come destinazione di upgrade per l'istanza. Puoi ottenere questo enum come primo passaggio del piano di upgrade. Se hai bisogno di un elenco completo degli enum delle versioni del database, consulta SqlDatabaseEnums.
    gcloud sql instances patch INSTANCE_NAME \
  --database-version=DATABASE_VERSION \
  --include-replicas-for-major-version-upgrade

    Il completamento degli upgrade della versione principale richiede diversi minuti. Potresti visualizzare un messaggio che indica che l'operazione sta richiedendo più tempo del previsto. Puoi ignorare questo messaggio o eseguire il comando gcloud sql operations wait per chiuderlo. L'upgrade delle repliche può richiedere diversi minuti. Per controllare lo stato dell'upgrade:

  2. Recupera il nome dell'operazione di upgrade.

    Utilizza il comando gcloud sql operations list con il flag --instance.

    Prima di eseguire il comando, sostituisci la variabile INSTANCE_NAME con il nome dell'istanza. 

    gcloud sql operations list --instance=INSTANCE_NAME

  3. Monitora lo stato dell'upgrade.

    Utilizza il comando gcloud sql operations describe.

    Prima di eseguire il comando, sostituisci la variabile OPERATION con il nome dell'operazione di upgrade recuperato nel passaggio precedente. 

    gcloud sql operations describe OPERATION

REST

  1. Avvia l'upgrade in loco.

    Utilizza una richiesta PATCH con il metodo instances:patch.

    Prima di utilizzare i dati della richiesta, sostituisci queste variabili:

    • PROJECT_ID: l'ID del progetto
    • INSTANCE_NAME: il nome dell'istanza

    Metodo HTTP e URL: 

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

    Corpo JSON della richiesta: 

    {
  "databaseVersion": DATABASE_VERSION
  "includeReplicasForMajorVersionUpgrade": true
}
    • Sostituisci DATABASE_VERSION con l'enumerazione per la versione principale del database, che deve essere successiva alla versione corrente. Specifica una versione del database per una versione principale disponibile come destinazione di upgrade per l'istanza. Puoi ottenere questo enum come primo passaggio del piano di upgrade. Se hai bisogno di un elenco completo degli enum delle versioni del database, consulta SqlDatabaseVersion.
    • Nel campo includeReplicasForMajorVersionUpgrade, specifica true.

  2. Recupera il nome dell'operazione di upgrade.

    Utilizza una richiesta GET con il metodo operations.list dopo aver sostituito PROJECT_ID con l'ID del progetto.

    Metodo HTTP e URL: 

    GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations

  3. Monitora lo stato dell'upgrade.

    Utilizza una richiesta GET con il metodo operations.get dopo aver sostituito le seguenti variabili:

    • PROJECT_ID: l'ID del progetto
    • OPERATION_NAME: il nome dell'operazione di upgrade recuperato nel passaggio precedente.

    Metodo HTTP e URL: 

    GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operation/OPERATION_NAME

Backup automatici degli upgrade

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 avviare l'upgrade. Puoi utilizzare questo backup per ripristinare lo stato precedente dell'istanza di database.
  • Il secondo backup dell'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 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 Pre-upgrade backup, MYSQL_5_7 to MYSQL_8_0. e il backup post-upgrade 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 Pre-upgrade backup, MYSQL_8_0 to MYSQL_8_4. e il backup post-upgrade 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 Pre-upgrade backup, MYSQL_8_4 to MYSQL_9_7. e il backup post-upgrade è etichettato Post-upgrade backup, MYSQL_9_7 from MYSQL_8_4.

Come per gli altri backup on demand, i backup dell'upgrade vengono conservati finché non li elimini o finché non elimini l'istanza. Se hai attivato il recupero point-in-time, non puoi eliminare i backup dell'upgrade mentre si trovano nel periodo di conservazione. Se devi eliminare i backup dell'upgrade, devi disattivare PITR o attendere che i backup dell'upgrade non rientrino più nella finestra di conservazione.

Completa l'upgrade della versione principale

Dopo aver completato l'upgrade dell'istanza principale, segui questi passaggi per completare l'upgrade:

  1. Esegui i test di accettazione.

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

  2. (Facoltativo) Aggiorna i privilegi utente.

    MySQL 8.0 ha nuove modifiche ai sistemi di sicurezza e gestione degli account. Per ulteriori informazioni, vedi Novità di MySQL 8.0.

    Cloud SQL per MySQL ha adottato queste modifiche e 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 descritta 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 ulteriori informazioni, consulta Privilegi utente di MySQL 8.4 (cloudsqlsuperuser).

    Puoi aggiornare i privilegi utente in MySQL 8.0, MySQL 8.4 o MySQL 9.7 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 degli 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.

    Anche se Cloud SQL crea 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.

Risolvere i problemi relativi a un upgrade della versione principale

Cloud SQL restituisce un messaggio di errore se tenti un comando di upgrade non valido, ad esempio se la tua 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 Google Cloud:

  1. Nella Google Cloud console, 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 log degli errori MySQL.

    Si apre 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 log 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 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 oppure filtrare i log in base alla gravità. Un'opzione comune per la risoluzione dei problemi potrebbe includere la selezione dei seguenti filtri:

    • Emergenza
    • Avviso
    • Critico
    • Errore

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

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

Esistono due attività sottostanti 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, allora 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 Google Cloud per controllare i processi attuali.

Errori comuni di controllo preliminare dell'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 di database. Per saperne di più, consulta Parole chiave e parole riservate.
  • Caratteri UTF non validi nelle definizioni delle tabelle.
  • Transazioni XA non eseguite che devono essere eseguite (utilizzando l'istruzione XA COMMIT) o annullate (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 dei problemi relativi a errori e problemi noti durante il controllo preliminare da MySQL 5.7 a MySQL 8.0, consulta Risoluzione dei problemi relativi all'upgrade in loco della versione principale a MySQL 8.0. Per ulteriori informazioni sui problemi comuni di MySQL, consulta Preparare l'installazione per l'upgrade ed Eseguire 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 vengono rimossi completamente da MySQL 8.4.

    Se utilizzi ancora comandi o configurazioni con questi termini, devi sostituirli o rimuoverli. Per saperne di più sulla rimozione e la 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 abilitato cloudsql_vector per la tua istanza, non puoi avere un indice secondario non vettoriale su una colonna che contiene incorporamenti vettoriali 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 database Cloud SQL 8.4, ma hai impostato cloudsql_vector su off. Nell'ambito dell'upgrade a MySQL 9.7, tutti i dati vettoriali vengono migrati nel formato MySQL della community anziché nel formato VARBINARY utilizzato da Cloud SQL per MySQL 8.4 e versioni precedenti. Per assicurarti che la migrazione dei dati vettoriali venga eseguita correttamente, puoi aggiornare il flag cloudsql_vector a 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 tuo database MySQL 8.4 prima dell'upgrade.
  • Hai account utente del database integrati rimanenti che utilizzano il plug-in mysql_native_password. Il plug-in viene rimosso completamente da Cloud SQL per MySQL 9.7. Se alcuni account utente utilizzano il plug-in mysql_native_password, questi account non possono connettersi al tuo database. Devi modificare tutti gli account rimanenti in modo che utilizzino il plug-in caching_sha2_password prima di eseguire l'upgrade a Cloud SQL per MySQL 9.7.

Ripristina l'istanza primaria alla versione principale precedente

Se il sistema di database aggiornato non funziona come previsto, potrebbe essere necessario ripristinare la versione precedente dell'istanza principale. A questo scopo, ripristina il backup pre-upgrade in un'istanza di recupero Cloud SQL, ovvero una nuova istanza che esegue la versione pre-upgrade.

Per ripristinare una versione precedente dell'istanza primaria, segui questi passaggi:

  1. Identifica il backup pre-upgrade.

    Consulta Backup automatici degli upgrade.

  2. Crea un'istanza di recupero.

    Crea una nuova istanza Cloud SQL utilizzando la versione principale in esecuzione su Cloud SQL 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 pre-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 sull'istanza di recupero e sulle relative repliche di lettura. Puoi riprendere a pubblicare il traffico nella versione precedente dell'upgrade del database.

Limitazioni

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

  • Non puoi eseguire un upgrade in loco della versione principale 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 andare in timeout.
  • L'upgrade delle istanze da MySQL 8.0 a MySQL 8.4 con più di 512.000 tabelle potrebbe richiedere molto tempo e andare in timeout.

  • 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 primaria, è possibile creare un nuovo account utente su un'istanza primaria non aggiornata con il plug-in di autenticazione mysql_native_password ritirato. Per evitare questa situazione, assicurati di eseguire l'upgrade dell'istanza primaria immediatamente dopo l'upgrade delle repliche oppure crea nuovi account utente solo sull'istanza primaria 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 sorgere le seguenti domande.

La mia istanza non è disponibile durante un upgrade?
Sì. L'istanza rimane non disponibile per un 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 ha un numero ridotto di vCPU o memoria, l'upgrade potrebbe richiedere più tempo.

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

Posso monitorare ogni passaggio della procedura di upgrade?
Cloud SQL ti consente di monitorare se un'operazione di upgrade è ancora in corso, ma 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 la versione precedente dell'istanza.
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 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 cambia in utf8mb4. Per ripristinare il valore utf8, imposta di nuovo il valore del flag sul valore precedente.

Per saperne 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 di nuovo 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 il rollback della replica non viene eseguito 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 riesce di nuovo, è probabile che la causa siano modifiche incompatibili aggiunte all'istanza principale durante l'upgrade. Risolvi i problemi dell'upgrade per individuare il problema, correggi l'istanza primaria 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 di replica non funziona, l'operazione di upgrade sull'istanza principale ricrea le repliche.

Perché la mia replica aggiornata rollback alla versione principale precedente?

Se un upgrade non va a buon fine, la replica viene eseguito il rollback 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 venga eseguita una query utilizzando i privilegi utente di MySQL 5.7 sugli schemi mysql e sys e potrebbe non riuscire a causa delle modifiche ai sistemi di gestione della sicurezza e degli account in MySQL 8.0. Per risolvere il problema, devi interrompere le query sull'istanza primaria prima di eseguire l'upgrade dell'istanza primaria 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 causare un problema simile.

Se non vedi il motivo dell'errore, ad esempio Access denied for AuthID.... nei log 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 all'upgrade di una versione principale per scoprire come risolvere i problemi di incompatibilità prima di eseguire di nuovo l'upgrade.

Passaggi successivi