Esegui l'upgrade della versione principale del database in uso

MySQL | PostgreSQL | SQL Server

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 provider di software per i database rilasciano periodicamente nuove versioni principali che contengono nuove funzionalità e miglioramenti delle prestazioni e della sicurezza. Cloud SQL accetta le nuove versioni dopo che sono state rilasciate. Quando Cloud SQL offrirà 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 consentono di eseguire più facilmente 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 conservare 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 e possono essere completati più velocemente. 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 l'utilità mysql_upgrade.

Pianifica un upgrade della versione principale

Scegli una versione principale di destinazione.

Consulta l'elenco delle versioni supportate da Cloud SQL.
Considera le funzionalità offerte in ogni versione principale del database e risolvi le incompatibilità.
- MySQL 8.0
- MySQL 5.7
Le nuove versioni principali introducono modifiche incompatibili che potrebbero richiedere la modifica del codice dell'applicazione, dello schema o delle impostazioni del database. Prima di eseguire l'upgrade dell'istanza di database, esamina le note di rilascio della versione principale di destinazione per determinare le incompatibilità da risolvere.

Dopo l'upgrade a una versione successiva, il valore predefinito di alcune variabili di sistema potrebbe cambiare. Ad esempio, il valore predefinito di character_set_server in MySQL 5.6 e MySQL 5.7 è utf8. Quando esegui l'upgrade a MySQL 8.0, il valore predefinito di character_set_server diventa utf8mb4. Per ripristinare utf8, devi ripristinare manualmente il valore del flag di database. Per ulteriori informazioni, consulta Configurare i flag di database. La maggior parte delle modifiche ai valori predefiniti viene apportata dalla community MySQL (per saperne di più, consulta la pagina Upgrade delle impostazioni predefinite del server).

Nota: puoi eseguire l'upgrade solo da una versione principale alla successiva. MySQL non supporta l'esclusione delle versioni principali. Non puoi eseguire l'upgrade direttamente da MySQL 5.6 a MySQL 8.0.
Verifica preliminare la presenza di aggiornamenti da MySQL 5.7 a 8.0.

Esegui un controllo preliminare prima di eseguire gli aggiornamenti da MySQL 5.7 a 8.0. Puoi utilizzare l'utilità di controllo upgrade nella shell MySQL. Se vengono rilevati problemi durante il controllo preliminare, correggili prima di procedere con l'upgrade. Cloud SQL non supporta il precontrollo durante un upgrade della versione principale. Anche un tentativo di eseguire l'upgrade di un'istanza che non ha superato il pre-controllo potrebbe non riuscire.
Controlla lo spazio su disco e i tipi di macchine di istanza.

Un upgrade della versione principale richiede risorse aggiuntive, ad esempio spazio su disco, per archiviare le tabelle di cui è stato eseguito l'upgrade. Se lo spazio su disco non è sufficiente, l'upgrade non va a buon fine e il rollback viene eseguito. Per un upgrade da MySQL 5.7 a 8.0, è necessaria memoria aggiuntiva per convertire i metadati precedenti nel nuovo dizionario dati. Prima di eseguire un upgrade di una versione principale, assicurati di avere più di 100.000 di memoria per ogni tabella. Puoi aumentare temporaneamente la memoria cambiando il tipo di macchina.
Verificare la presenza di modifiche alle autorizzazioni degli utenti in MySQL 8.0

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

Per ulteriori informazioni sul funzionamento di questo flag in MySQL 8.0, consulta partial_revokes in MySQL 8.0.
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 venga completato correttamente, esegui test per assicurarti che l'applicazione funzioni come previsto nel database aggiornato.

Nota: assicurati di avere spazio su disco sufficiente prima di eseguire un upgrade della versione principale. Se non hai abilitato gli aumenti automatici dello spazio di archiviazione, prendi nota dello spazio di archiviazione su disco utilizzato dall'istanza di prova aggiornata. Ciò ti aiuta a determinare se è necessario aumentare la capacità di archiviazione per l'istanza di produzione prima di eseguire l'upgrade.
Decidi quando eseguire l'upgrade.

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

Preparati per un upgrade di una versione principale

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

SOLO per gli aggiornamenti da MySQL 5.7 a 8.0: verifica e risolvi i problemi incompatibili rilevati durante il processo di precontrollo. I problemi più comuni possono includere:
1. Aggiunta di nuove parole chiave riservate, ad esempio RANKS, GROUPS, FUNCTION, nelle stored procedure, negli attivatori e così via. Per ulteriori informazioni, consulta Parole chiave e parole riservate.
2. Caratteri UTF non validi nelle definizioni delle tabelle.
3. Transizioni XA non impegnate di cui è necessario eseguire il commit (utilizzando l'istruzione XA COMMIT) o eseguire il rollback (utilizzando l'istruzione XA ROLLBACK).
4. Vincolo di chiave esterna nei nomi più lunghi di 64 caratteri.
5. Tipo di dati spaziali in un indice misto di colonne. Per saperne di più, consulta la sezione Tipo di dati spaziali.
Per ulteriori informazioni, consulta Preparazione dell'installazione per l'upgrade e Eseguire l'upgrade a MySQL 8.0?.
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 dati. La mancanza di spazio su disco richiesto causa un errore dell'upgrade e il rollback alla versione originale. Cloud SQL consiglia di avere almeno 100.000 in memoria per ogni tabella.
Nota: puoi aumentare temporaneamente la memoria modificando il tipo di macchina prima di eseguire l'upgrade della versione principale. Per scoprire di più, consulta la sezione Cambiare il tipo di macchina.
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 l'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 ti consiglia di:
1. Esegui l'upgrade dell'istanza principale immediatamente dopo aver eseguito l'upgrade delle repliche.
2. Evita di eseguire query incompatibili con la nuova versione nell'istanza principale fino al completamento dell'upgrade.
3. (Facoltativo) Metti in pausa tutte le istruzioni WRITE per l'istanza principale fino al completamento dell'upgrade.
4. (Facoltativo) Rimuovi tutte le repliche prima di eseguire l'upgrade di quella principale e ricreale una volta completato l'upgrade.
Se la replica si interrompe, viene eseguito il rollback alla versione dell'istanza principale. Puoi eseguire di nuovo l'upgrade della replica, ma se il problema persiste, consulta le [domande frequenti](#faqs).

Esegui l'upgrade della versione principale del database in uso

Quando avvii un'operazione di upgrade, Cloud SQL controlla innanzitutto la configurazione dell'istanza per verificare che sia compatibile per un upgrade. Dopo aver verificato la configurazione, Cloud SQL rende non disponibile l'istanza, esegue un backup precedente all'upgrade, esegue l'upgrade, rende disponibile l'istanza ed esegue un backup successivo all'upgrade.

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

Console

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

Vai a Istanze Cloud SQL
Per aprire la pagina Panoramica di un'istanza, fai clic sul nome dell'istanza.
Fai clic su Modifica.
Nella sezione Informazioni istanza, fai clic sul pulsante Esegui l'upgrade e conferma di voler andare alla pagina dell'upgrade.
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.
Fai clic su Continua.
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

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'enum per la versione principale del database, che deve essere superiore alla versione corrente. Vedi le enumerazioni delle versioni del database disponibili.
```
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 ignorarlo.
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
```
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

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:
```
POST https://sqladmin.googleapis.com/sql/v1/projects/project-id/instances/instance_name
```
Corpo JSON della richiesta:
```
{
  "databaseVersion": enum DATABASE_VERSION
}
```
Sostituisci DATABASE_VERSION con l'enum per la versione principale del database, che deve essere superiore alla versione attuale. Vedi le enumerazioni delle versioni del database disponibili.

Invia la richiesta utilizzando curl o PowerShell. Vedi Modificare le istanze.
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/sql/v1/projects/project-id/operations
```
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/sql/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 successiva.

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 in un progetto Google Cloud, completa i passaggi nelle sezioni seguenti.

prepara Cloud Shell

Avvia Cloud Shell.
Imposta il progetto Google Cloud predefinito a 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
```
Se imposti valori espliciti nel file di configurazione Terraform, le variabili di ambiente vengono sostituite.

Prepara la directory

Ogni file di configurazione Terraform deve avere una propria directory (detta anche modulo principale).

In Cloud Shell, crea una directory e un nuovo file al suo interno. Il nome del file deve avere l'estensione .tf, ad esempio main.tf. In questo tutorial, il file è indicato come main.tf.
```
mkdir DIRECTORY && cd DIRECTORY && touch main.tf
```
Se stai seguendo un tutorial, puoi copiare il codice campione in ogni sezione o passaggio.

Copia il codice campione nel file main.tf appena creato.

Se vuoi, copia il codice da GitHub. Questa opzione è consigliata se lo snippet Terraform fa parte di una soluzione end-to-end.
Esamina e modifica i parametri di esempio da applicare al tuo ambiente.
Salva le modifiche.
Inizializza Terraform. Devi eseguire questa operazione una sola volta per directory.
```
terraform init
```
Facoltativamente, per utilizzare la versione più recente del provider Google, includi l'opzione -upgrade:
```
terraform init -upgrade
```

Applica le modifiche

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.
Applica la configurazione Terraform eseguendo il comando seguente e inserendo yes al prompt:
```
terraform apply
```
Attendi finché Terraform non visualizza il messaggio "Applicazione completata".
Apri il progetto Google Cloud per visualizzare i risultati. Nella console Google Cloud, vai alle risorse nell'interfaccia utente per assicurarti che Terraform le abbia create o aggiornate.

Elimina le modifiche

Per eliminare le modifiche:

Per disabilitare la protezione dall'eliminazione, nel file di configurazione Terraform imposta l'argomento deletion_protection su false.
```
deletion_protection =  "false"
```
Applica la configurazione Terraform aggiornata eseguendo il comando seguente e inserendo yes al prompt:
```
terraform apply
```

Rimuovi le risorse applicate in precedenza con la tua configurazione Terraform eseguendo il comando seguente e inserendo yes al prompt:
```
terraform destroy
```

Quando effettui una richiesta di upgrade in loco, 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 mostra un messaggio che suggerisce come risolvere il problema. Vedi anche Risolvere i problemi di upgrade di una versione principale.

Backup degli upgrade automatici

Quando esegui un upgrade della versione principale, Cloud SQL effettua automaticamente due backup on demand, denominati backup dell'upgrade:

Il primo backup dell'upgrade è il backup precedente all'upgrade, che viene eseguito immediatamente prima di iniziare l'upgrade. Puoi utilizzare questo backup per ripristinare l'istanza di database allo stato precedente nella versione precedente.
Il secondo backup dell'upgrade è quello successivo all'upgrade, che viene eseguito immediatamente dopo che sono state consentite nuove scritture all'istanza del database di cui è stato eseguito l'upgrade.

Quando visualizza l'elenco dei backup, i backup degli upgrade sono elencati con il tipo On-demand. I backup degli upgrade sono etichettati in modo da identificarli facilmente. Ad esempio, se esegui l'upgrade da MySQL 5.7 a MySQL 8.0, il backup prima dell'upgrade è etichettato Pre-upgrade backup, MYSQL_5_7 to MYSQL_8_0. e il backup successivo all'upgrade Post-upgrade backup, MYSQL_8_0 from MYSQL_5_7.

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

Completa l'upgrade della versione principale

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

Esegui test di accettazione.

Esegui dei test per verificare che il sistema di cui hai eseguito l'upgrade funzioni come previsto.
(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, consulta Novità di MySQL 8.0.

Ciò potrebbe far sì che gli utenti creati nella versione MySQL 5.7 dell'istanza non abbiano gli stessi privilegi degli utenti creati direttamente in MySQL 8.0. Ad esempio, un utente che ha eseguito l'upgrade da MySQL 5.7 potrebbe non 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 segui questi passaggi:
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 che ha eseguito l'upgrade con:
```
REVOKE ALL PRIVILEGES ON *.* FROM user@host
```
3. Concedi i privilegi previsti all'utente che ha eseguito l'upgrade.
(Facoltativo) Crea un backup.

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

Risolvere i problemi relativi all'upgrade di una 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. Se la richiesta ha una struttura valida, prova a esaminare i suggerimenti che seguono.

Visualizza i log di upgrade

Se si verificano problemi con una richiesta di upgrade valida, Cloud SQL pubblica i log degli errori su 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:

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

Vai a Istanze Cloud SQL
Per aprire la pagina Panoramica di un'istanza, fai clic sul nome dell'istanza.
Nel riquadro Operazioni e log della pagina Panoramica dell'istanza, fai clic sul link Visualizza i log degli errori MySQL.

Si apre la pagina Esplora log.
Visualizza i log nel seguente modo:
- Per elencare tutti i log degli errori in un progetto, seleziona il nome del log nel filtro di log Nome log.
Per ulteriori informazioni sui filtri delle query, consulta Query avanzate.
- Per filtrare i log degli errori dell'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 dell'upgrade in base a un'istanza denominata shopping-db in esecuzione nel progetto buylots, utilizza il seguente filtro delle query:
```
 resource.type="cloudsql_database"
 resource.labels.database_id="buylots:shopping-db"
 logName : "projects/buylots/logs/cloudsql.googleapis.com%2Fmysql.err"
 ```
```

Ripristina la versione principale precedente

Se il sistema di database di cui hai eseguito l'upgrade non funziona come previsto, potrebbe essere necessario ripristinare l'istanza alla versione precedente. Per farlo, devi ripristinare il backup precedente all'upgrade in un'istanza di ripristino di Cloud SQL, ovvero una nuova istanza che esegue la versione precedente all'upgrade.

Per ripristinare la versione precedente, svolgi i seguenti passaggi:

Identifica il backup prima dell'upgrade.

Vedi Backup degli upgrade automatici.
Creare un'istanza di recupero.

Crea una nuova istanza Cloud SQL utilizzando la versione principale utilizzata da Cloud SQL al momento dell'esecuzione del backup precedente all'upgrade. Imposta gli stessi flag e impostazioni dell'istanza utilizzati dall'istanza originale.
Ripristina il backup precedente all'upgrade.

Ripristina il backup precedente l'upgrade all'istanza di ripristino. L'operazione potrebbe richiedere diversi minuti.
Aggiungi le repliche di lettura.

Se utilizzavi repliche di lettura, aggiungile singolarmente.
Collega la tua applicazione.

Dopo aver ripristinato il sistema di database, aggiorna l'applicazione con i dettagli sull'istanza di ripristino e sulle sue repliche di lettura. Puoi riprendere la gestione del traffico nella versione precedente all'upgrade del database.

Limitazioni

Trova l'elenco delle limitazioni che interessano gli upgrade di versione principale in loco per Cloud SQL per MySQL. Queste limitazioni sono attualmente in corso di revisione:

L'aggiornamento di istanze da MySQL 5.7 a 8.0 con 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ì. 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 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 tuoi database sono molto grandi, l'upgrade potrebbe richiedere ore o addirittura un timeout perché la tempistica dell'upgrade corrisponde al numero di oggetti nei database. Se hai più istanze di cui è necessario eseguire l'upgrade, il tempo totale per l'upgrade aumenta in modo proporzionale.

Posso monitorare ogni passaggio del processo di upgrade?: Mentre Cloud SQL consente di monitorare se un'operazione di upgrade è ancora in corso, non puoi monitorare i singoli passaggi in ogni upgrade.

Posso annullare il mio upgrade dopo averlo avviato?: No, una volta avviato, non puoi annullare un upgrade. Se l'upgrade non va a buon fine, Cloud SQL recupera automaticamente l'istanza nella versione precedente.

Che cosa succede alle mie impostazioni durante un upgrade?

Quando esegui un upgrade della versione principale in loco, Cloud SQL conserva le impostazioni del database, tra cui 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 diventa utf8mb4. Per ripristinare il valore utf8, ripristina il valore precedente per il valore del flag.

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

Che cosa posso fare se la replica si interrompe dopo aver eseguito l'upgrade della replica?

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

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

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

Se l'upgrade continua a non riuscire, è probabile che il problema sia dovuto a modifiche incompatibili aggiunte all'account 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. Per ulteriori informazioni, visita la pagina relativa alla troubleshoot.
Esegui l'upgrade dell'istanza principale

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

Perché è stato eseguito il rollback della mia replica di cui è stato eseguito l'upgrade 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 dei privilegi utente, è probabile che una query venga eseguita utilizzando i privilegi utente MySQL 5.7 su schemi MySQL e sys e potrebbe non funzionare a causa delle modifiche ai sistemi di sicurezza e di gestione degli account di MySQL 8.0. Per risolvere questo problema, devi arrestare le query sull'istanza principale prima di eseguire l'upgrade dell'istanza principale alla nuova versione e poi 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, in quanto ciò 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. Per informazioni su come risolvere i problemi di incompatibilità prima di eseguire nuovamente l'upgrade, vedi Prepararsi per un upgrade della versione principale.

Passaggi successivi

Scopri le opzioni per la connessione a un'istanza.
Scopri di più su come importare ed esportare i dati.
Scopri di più sull'impostazione dei flag di database.