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 del tuo l'istanza Cloud SQL in loco anziché eseguendo la migrazione dei dati.

Introduzione

I fornitori di software per i database rilasciano periodicamente nuove versioni principali che contengono nuove funzionalità, miglioramenti delle prestazioni e della sicurezza. Cloud SQL acquisisce nuove versioni dopo vengono rilasciate. 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 oppure eseguendo la migrazione i tuoi dati. Upgrade in loco sono un modo più semplice per eseguire l'upgrade della versione principale dell'istanza. Non è necessario migrare i dati o modificare le stringhe di connessione dell'applicazione. Grazie agli upgrade in loco, puoi mantenere il nome, l'indirizzo IP e altre impostazioni dell'istanza attuale dopo l'upgrade. Gli upgrade in loco non richiedono lo spostamento di file di dati, possono essere completate più rapidamente. In alcuni casi, il tempo di inattività è più breve di quanto comporta la migrazione dei dati.

L'operazione di upgrade in loco di Cloud SQL per MySQL utilizza mysql_upgrade.

Pianifica un upgrade della versione principale

  1. Scegli una versione principale di destinazione.

    gcloud

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

    per verificare le versioni del database che puoi scegliere come target per un upgrade in loco. sull'istanza, segui questi passaggi:

    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 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 di versione del database che include il parametro 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 esegui l'upgrade della versione in loco, utilizza Metodo instances.get dell'API Cloud SQL Admin.

    Prima di utilizzare i dati della richiesta, effettua 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 delle seguenti 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 i principali eseguire l'upgrade in loco di un'istanza, utilizza Metodo instances.get dell'API Cloud SQL Admin.

    Prima di utilizzare i dati della richiesta, effettua 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 delle seguenti 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 criteri di versione.

  2. Considera le funzionalità offerte in ogni versione e indirizzo principale del database incompatibilità.

    Le nuove versioni principali introducono modifiche incompatibili che potrebbero richiedere modificare il codice dell'applicazione, lo schema o le impostazioni del database. Prima del giorno esegui l'upgrade dell'istanza di database, rivedi le note di rilascio scegliere come target la versione principale per determinare le incompatibilità da .

    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 diventa utf8mb4. Per ripristinare utf8, devi ripristinare manualmente il valore precedente del flag di database. Per ulteriori informazioni, consulta Configurare i flag di database. La maggior parte delle modifiche ai valori predefiniti viene effettuata dalla community MySQL (scopri di più nella pagina Eseguire l'upgrade dei valori predefiniti del server).

  3. Controlla prima la presenza di upgrade da MySQL 5.7 a 8.0.

    Esegui un controllo preliminare prima di eseguire gli upgrade da MySQL 5.7 a 8.0. Puoi utilizzare l'utilità di controllo dell'upgrade nella shell MySQL. Se vengono rilevati problemi durante il precontrollo, correggili prima di procedere con l'upgrade. Cloud SQL supporta il precontrollo durante l'upgrade della versione principale. Un tentativo di upgrade di un potrebbe non andare a buon fine anche l'istanza in cui il precontrollo non è riuscito.

  4. Verifica lo spazio su disco e i tipi di macchine delle istanze.

    Un upgrade della versione principale richiede risorse aggiuntive, ad esempio spazio su disco, per archiviare le tabelle con upgrade eseguito. Se lo spazio su disco non è sufficiente, l'upgrade non va a buon fine e esegue il rollback. Per un upgrade da MySQL 5.7 a 8.0, è necessaria una memoria aggiuntiva per convertire i metadati precedenti al nuovo dizionario dei dati. Prima di eseguire una versione principale aggiorna, assicurati di avere più di 100.000 di memoria per ogni tabella. Tu possono aumentare temporaneamente la memoria modificando il tipo di macchina.

  5. Verificare 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 rimuove la possibilità di utilizzare caratteri jolly nei comandi GRANT del database. Per assicurarti che gli utenti del database abbiano accesso agli schemi corretti del database, modifica i privilegi utente del database prima di eseguire l'upgrade a MySQL 8.0. Aggiorna i privilegi dell'utente per utilizzare tutte le degli schemi del database richiesti, anziché utilizzare caratteri jolly.

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

  6. Testa l'upgrade con una prova.

    Esegui una prova del processo 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 sia stato completato correttamente, per garantire che l'applicazione comporti il comportamento previsto nell'upgrade per configurare un database.

  7. Decidi quando eseguire l'upgrade.

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

Prepararsi a 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 risolvi i problemi incompatibili rilevati durante il processo di precontrollo. I problemi più comuni possono includere:

    1. Aggiunta di nuove parole chiave riservate, come RANKS, GROUPS, FUNCTION, in stored procedure, trigger e così via. Per ulteriori informazioni, consulta Parole chiave e parole riservate.
    2. Caratteri UTF non validi nelle definizioni della tabella.
    3. Transizioni XA di cui non è stato eseguito il commit di cui è necessario eseguire il commit (utilizzando l'istruzione XA COMMIT) o il rollback (utilizzando l'istruzione XA ROLLBACK).
    4. Vincolo di chiave esterna nei nomi più lunghi di 64 caratteri.
    5. Tipo di dati spaziali nell'indice misto delle colonne. Per ulteriori informazioni, consulta la sezione Tipo di dati spaziali.

    Per ulteriori informazioni, vedi Preparare l'installazione per l'upgrade e Eseguire l'upgrade a MySQL 8.0?.

  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 di cui è stato eseguito l'upgrade e il nuovo dizionario dei dati. In assenza di spazio su disco richiesto, l'upgrade non riesce e viene eseguito il rollback alla versione originale. Cloud SQL consiglia di avere almeno 100.000 di memoria per ogni tabella.

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

  3. Esegui l'upgrade delle repliche di lettura.

    Se utilizzi 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 interrompersi 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 dell'istanza principale subito dopo l'upgrade delle repliche.
    2. Evita di eseguire query incompatibili con la nuova versione sull'istanza principale fino al completamento dell'upgrade.
    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 dell'istanza principale e ricreale una volta completato l'upgrade.

    Se la replica si interrompe, viene eseguito il rollback della replica alla versione dell'istanza principale. Puoi eseguire nuovamente l'upgrade della replica, ma se il problema persiste, vedi Domande frequenti.

Esegui l'upgrade della versione principale del database in loco

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

Quando esegui l'upgrade a MySQL 8.0, Cloud SQL esegue automaticamente il provisioning nella versione secondaria predefinita.

Console

  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. Fai clic su Modifica.
  4. Nella sezione Informazioni istanza, fai clic sul pulsante Esegui l'upgrade e conferma di voler passare alla pagina di upgrade.
  5. Nella pagina Scegli una versione del database, fai clic su Versione database per 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 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 la 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 corrente. Specifica una versione del database per una versione principale disponibile come destinazione dell'upgrade per l'istanza. Puoi ottenere questa enum come primo passaggio della procedura Pianifica per l'upgrade. Se hai bisogno di un elenco completo delle enum delle versioni del database, vedi SqlDatabaseEnums.
    gcloud sql instances patch INSTANCE_NAME \
--database-version=DATABASE_VERSION

    Il completamento degli upgrade delle versioni principali richiede diversi minuti. Potresti vedere un messaggio che indica che l'operazione richiede più tempo del previsto. Puoi ignora questo messaggio o esegui gcloud sql operations wait per ignorare il messaggio.

  2. Ottieni il nome dell'operazione di upgrade.

    Utilizza la 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 la gcloud sql operations describe .

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

    gcloud sql operations describe OPERATION

REST v1

  1. Avvia l'upgrade in loco.

    Utilizza una richiesta PATCH con 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 dell'upgrade per l'istanza. Puoi ottenere questa enum come primo passaggio della procedura Pianifica per l'upgrade. Se hai bisogno di un elenco completo delle enum delle versioni del database, vedi SqlDatabaseVersion.

  2. Ottieni il nome dell'operazione di upgrade.

    Utilizza una richiesta GET con 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 operations.get dopo aver sostituito le seguenti variabili:

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

    Metodo HTTP e URL: 

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

Terraform

Per aggiornare la versione del database, utilizza una risorsa Terraform e il provider Terraform per Google Cloud, versione 4.34.0 o successive.

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
}

Applica le modifiche

Per applicare la configurazione Terraform a un progetto Google Cloud, completa i passaggi nella le sezioni seguenti.

Prepara Cloud Shell

  1. Avvia Cloud Shell.

  2. Imposta il progetto Google Cloud predefinito dove 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 in Terraform di configurazione del deployment.

Prepara la directory

Ogni file di configurazione Terraform deve avere una directory (inoltre chiamato modulo principale).

  1. In Cloud Shell, crea una directory e un nuovo all'interno di quella directory. Il nome del file deve contenere .tf, ad esempio main.tf. In questo tutorial, il file è denominato 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 nuovo oggetto main.tf.

    Facoltativamente, copia il codice da GitHub. Opzione consigliata quando lo snippet Terraform fa parte di una soluzione end-to-end.

  3. Esamina 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

    Facoltativamente, per utilizzare la versione più recente del provider Google, includi -upgrade : 

    terraform init -upgrade

Applica le modifiche

  1. Rivedi la configurazione e verifica che le risorse che Terraform creerà o che l'aggiornamento soddisfi le tue aspettative: 
    terraform plan

    Apporta le correzioni necessarie alla configurazione.

  2. Applica la configurazione Terraform eseguendo questo comando e inserendo yes alla richiesta: 
    terraform apply

    Attendi finché Terraform non visualizzi il messaggio "Applicazione completata!". .

  3. Apri il progetto Google Cloud per visualizzare i risultati. Nella console Google Cloud, vai alle risorse nella UI per assicurarti create o aggiornate da Terraform.

Elimina le modifiche

Per eliminare le modifiche:

  1. Per disabilitare la protezione dall'eliminazione, nel file di configurazione Terraform imposta la classe Argomento deletion_protection per false. 
    deletion_protection =  "false"
  2. Applica la configurazione Terraform aggiornata eseguendo il comando seguente inserendo yes alla richiesta: 
    terraform apply

  1. Rimuovi le risorse applicate in precedenza con la tua configurazione Terraform eseguendo questo comando e inserendo yes al prompt:

    terraform destroy

Quando effettui una richiesta di upgrade in loco, Cloud SQL esegue prima controllo prima dell'upgrade. Se Cloud SQL determina che l'istanza non è è tutto pronto per un upgrade, la richiesta di upgrade non va a buon fine e viene visualizzato un messaggio che suggerisce puoi risolvere il problema. Vedi anche Risolvere i problemi di una versione principale upgrade.

Backup automatici degli upgrade

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

  • Il primo backup dell'upgrade è il backup prima dell'upgrade, che viene eseguito immediatamente prima di iniziare l'upgrade. Puoi usare questo backup per ripristinare dell'istanza di database allo stato della versione precedente.
  • Il secondo backup dell'upgrade è il backup successivo all'upgrade, che viene eseguito. immediatamente dopo le nuove scritture nell'istanza del database di cui è stato eseguito l'upgrade.

Quando visualizzi il tuo elenco di i backup, i backup dell'upgrade sono elencati con il tipo On-demand. I backup dell'upgrade sono etichettati in modo in modo da poterle identificare facilmente. Ad esempio, se esegui l'upgrade da MySQL 5.7 a MySQL 8.0, la configurazione il backup è etichettato come Pre-upgrade backup, MYSQL_5_7 to MYSQL_8_0. e il tuo backup dopo l'upgrade Post-upgrade backup, MYSQL_8_0 from MYSQL_5_7.

Come per altri backup on demand, i backup di upgrade vengono mantenuti finché non li elimini o eliminare l'istanza. Se hai abilitato PITR, non puoi eliminare l'upgrade backup mentre si trovano nel periodo di conservazione. Per eliminare backup dell'upgrade, devi disabilitare PITR o attendere che venga eseguito il backup non rientrano più nel periodo di conservazione.

Completa l'upgrade della versione principale

Dopo aver completato l'upgrade dell'istanza principale, esegui quanto segue passaggi per completare l'upgrade:

  1. Eseguire test di accettazione.

    Esegui dei test per verificare che il sistema di cui hai 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 cambiato i sistemi di sicurezza e di gestione degli account. Per ulteriori informazioni, vedi Novità di MySQL 8.0.

    Di conseguenza, 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, un utente di cui è stato eseguito l'upgrade da MySQL 5.7 potrebbe non avere i privilegi CREATE ROLE e DROP ROLE perché questi privilegi non esistevano in MySQL 5.7. Cloud SQL consiglia di reimpostare i privilegi utente dopo aver eseguito l'upgrade delle versioni per risolvere eventuali problemi relativi ai privilegi utente.

    Per reimpostare i privilegi utente:

    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 i privilegi previsti all'utente di cui è stato eseguito l'upgrade.

  3. (Facoltativo) Crea un backup.

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

Risolvere i problemi relativi a un upgrade della versione principale

Cloud SQL restituisce un messaggio di errore se tenti di eseguire un upgrade non valido Ad esempio, se l'istanza contiene flag di database non validi per nuova versione.

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

Visualizza i log degli 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 per 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 su il Link Visualizza i log degli errori MySQL.

    Si apre la pagina Esplora log.

  4. Visualizza i log come segue:

    • Per visualizzare l'elenco di tutti i log degli errori in un progetto, seleziona il nome log nel campo Log nome.

    Per ulteriori informazioni sui filtri delle query, consulta Impostazioni avanzate query.

    • Per filtrare i log degli errori di upgrade per una singola istanza, inserisci il 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; usa la seguente query filtro:

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

Ripristina alla versione principale precedente

Se il sistema di database aggiornato non funziona come previsto, potrebbe essere necessario ripristinare la versione precedente dell'istanza. Per farlo, puoi ripristinare prima dell'upgrade a un'istanza di ripristino di Cloud SQL, che è una che esegue la versione precedente all'upgrade.

Per ripristinare la versione precedente, segui questi passaggi:

  1. Identifica il backup prima dell'upgrade.

    Consulta Backup automatici degli upgrade.

  2. Crea un'istanza di recupero.

    Crea un nuovo Cloud SQL di Compute Engine utilizzando la versione principale che Cloud SQL era in esecuzione al momento del backup precedente all'upgrade. Imposta gli stessi flag e le stesse istanza impostazioni che l'originale utilizzati dall'istanza.

  3. Ripristina il backup prima dell'upgrade.

    Ripristina il backup prima dell'upgrade all'istanza di ripristino. L'operazione potrebbe richiedere diversi minuti.

  4. Aggiungi le tue repliche di lettura.

    Se utilizzavi repliche di lettura, aggiungile singolarmente.

  5. Connetti la tua applicazione.

    Una volta ripristinato il sistema del database, aggiorna l'applicazione con i dettagli sull'istanza di ripristino e sulle sue repliche di lettura. Puoi riprendere la pubblicazione il traffico sulla versione precedente l'upgrade del database.

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 8.0 che hanno più di 512.000 tabelle potrebbe richiedere molto tempo e timeout.

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ì. La tua 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 in genere richiede 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 se i database sono molto grandi, l'upgrade potrebbe richiedere ore o addirittura il timeout perché il tempo di upgrade corrisponde al numero di oggetti nei database. Se devi eseguire l'upgrade di più istanze, il tempo totale di upgrade verrà incrementato in modo proporzionale.

Posso monitorare ogni passaggio del processo di upgrade?
Mentre Cloud SQL ti consente di monitorare se un'operazione di upgrade è ancora in corso i progressi fatti, 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 loco della versione principale, Cloud SQL conserva il database tra cui nome istanza, indirizzo IP, valori dei flag configurati in modo esplicito e 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 utf8, reimposta il valore del flag precedente.

Per saperne di più, consulta Configurare i flag di database. Se un determinato o il valore non è più supportato nella tua versione di destinazione, Cloud SQL rimuove automaticamente il flag 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 nuovamente l'upgrade della replica, ma se il problema persiste, la replica potrebbe interrompersi di nuovo.

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

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

    Se l'upgrade non riesce nuovamente, la causa è probabilmente la presenza di modifiche incompatibili aggiunte all'istanza principale al momento dell'upgrade. Errore durante l'upgrade per individuare il problema, correggere l'istanza principale e provare a eseguire l'upgrade della replica. Consulta la sezione Risoluzione dei problemi per ulteriori informazioni.

  2. Esegui l'upgrade dell'istanza principale

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

Perché la mia replica di cui è stato eseguito l'upgrade ha eseguito il 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 venga eseguita una query utilizzando i privilegi utente MySQL 5.7 sugli schemi mysql e sys e potrebbe non riuscire a causa delle modifiche ai sistemi di sicurezza e di gestione degli account in MySQL 8.0. Per risolvere il problema, devi arrestare le query sull'istanza principale prima di eseguire l'upgrade dell'istanza principale alla nuova versione, quindi riprovare a eseguire l'upgrade della replica. Cloud SQL consiglia di arrestare temporaneamente tutte queste query anche nell'istanza principale prima di eseguire l'upgrade alla nuova versione, poiché potrebbe causare 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. Prima di eseguire nuovamente l'upgrade, leggi come prepararsi all'upgrade della versione principale per sapere come risolvere i problemi di incompatibilità.

Passaggi successivi