Risoluzione dei problemi relativi all'upgrade in loco della versione principale a MySQL 8.0

Questa pagina descrive i problemi e le incompatibilità noti che potresti riscontrare durante le operazioni di precontrollo quando esegui un upgrade della versione principale da Cloud SQL per MySQL 5.7 a Cloud SQL per MySQL 8.0.

Per saperne di più sull'upgrade della versione principale, consulta Eseguire l'upgrade della versione principale del database sul posto e Visualizzare i log degli errori.

Modifiche SQL incompatibili

Questa sezione elenca le incompatibilità SQL in Cloud SQL 5.7 e Cloud SQL 8.0 che potresti riscontrare durante l'esecuzione dell'utilità di controllo preliminare o durante l'upgrade e fornisce suggerimenti su come risolverli.

Parole chiave riservate

Il seguente errore si verifica quando tenti di utilizzare una parola chiave riservata:

Warning: The following objects have names that conflict with new reserved
keywords. Ensure queries sent by your applications use `quotes` when referring
to them or they will result in errors.

Questo errore si verifica se tenti di utilizzare parole chiave ora classificate come riservate in MySQL versione 8.0, ad esempio:

  • GROUPS
  • LEAD
  • RANK

Ciò significa che alcune parole precedentemente utilizzate come identificatori ora potrebbero essere considerate illegali. Per risolvere il problema, correggi le istruzioni interessate utilizzando le virgolette per l'identificatore o rinomina l'identificatore.

Per un elenco completo delle parole chiave, consulta Parole chiave e parole riservate.

Rimozione di ASC/DESC con la clausola GROUP BY

Il seguente errore si verifica quando tenti di utilizzare ASC/DESC con la clausola GROUP BY:

[ERROR] [MY-013235] [Server] Error in parsing Routine db_name.routine_name during
upgrade. You may have an error in your SQL syntax; check the manual that
corresponding to your MySQL server version for the right syntax to use near
'some_text'

Di seguito è riportato un altro messaggio di errore che potresti ricevere in questo caso:

[ERROR] [MY-013235] [Server] Unknown trigger has an error in its body: 'You have
an error in you SQL syntax;
[ERROR] [MY-010198] [Server] Error in parsing Triggers from trigger_name.TRG file.

Questo errore si verifica se provi a ordinare la query utilizzando GROUP BY.

Le query che in precedenza si basavano sull'ordinamento GROUP BY possono produrre risultati diversi rispetto alle versioni precedenti di MySQL. Per mantenere un determinato ordinamento, fornisci una clausola ORDER BY.

Per risolvere il problema, utilizza la clausola ORDER BY. Ad esempio, se una procedura memorizzata, un trigger o una definizione di evento contiene una query che utilizza ASC o DESC con la clausola GROUP BY, la query dell'oggetto richiede una clausola ORDER BY.

Per saperne di più, vedi Rimuovere la sintassi per GROUP BY ASC e DESC.

Combinazione di dati spaziali con altri tipi come chiave

Quando utilizzi il tasto prefisso errato, si verifica il seguente errore:

[ERROR] [MY-013140] [Server] Incorrect prefix key; the used key part isn't a
string, the used length is longer than the key part, or the storage engine doesn't
support unique prefix keys
[ERROR] [MY-013140] [Server] Too many key parts specified; max 1 parts allowed

Questo errore si verifica se provi a utilizzare un mix di dati spaziali con altri tipi come chiave.

In MySQL 8.0 e versioni successive, un indice non può contenere un mix di tipi di dati spaziali e di altro tipo. Devi rimuovere la chiave e crearne una nuova supportata in MySQL versione 8.0 o successive. Per saperne di più, consulta Indici spaziali.

Per risolvere il problema, identifica gli indici dei dati spaziali utilizzando una query simile alla seguente:

  SELECT
      s.TABLE_SCHEMA,
      s.TABLE_NAME,
      s.INDEX_NAME,
      s.COLUMN_NAME,
      s.INDEX_TYPE,
      c.DATA_TYPE
  FROM
      information_schema.STATISTICS s
  JOIN
      information_schema.COLUMNS c ON s.TABLE_SCHEMA = c.TABLE_SCHEMA
      AND s.TABLE_NAME = c.TABLE_NAME
      AND s.COLUMN_NAME = c.COLUMN_NAME
  WHERE
      c.DATA_TYPE IN (
          'geometry',
          'point',
          'linestring',
          'polygon',
          'multipoint',
          'multilinestring',
          'multipolygon',
          'geometrycollection'
      )
      AND s.INDEX_TYPE = 'BTREE';

Caratteri UTF8 non validi

Si verifica il seguente errore quando utilizzi stringhe di caratteri UTF8 non valide:

[ERROR] [MY-010765] [Server] Error in Creating DD entry for %s.%s
[ERROR] [MY-013140] [Server] Invalid utf8 character string: invalid_string

Questo errore si verifica se nei comandi sono presenti caratteri UTF8 non validi. Ad esempio, se una definizione di tabella contiene caratteri UTF8 non validi, la conversione delle definizioni di tabella nel dizionario dei dati potrebbe non riuscire.

Per risolvere il problema, sostituisci i caratteri non validi con i caratteri UTF8 corrispondenti o rimuovili del tutto.

Per identificare e risolvere il problema dei caratteri non validi, puoi utilizzare una query simile alla seguente:

SHOW CREATE TABLE table_name;

ALTER TABLE table_name MODIFY COLUMN column_name data_type comment='';
// removing invalid utf8 character from comment

Transazioni XA non eseguite

Si verifica il seguente errore quando esistono transazioni XA preparate:

[ERROR] [MY-013527] [Server] Upgrade cannot proceed due to an existing prepared XA transactions

Questo errore si verifica se sono presenti transazioni XA non commit, il che causa l'esito negativo dell'upgrade in loco della versione principale.

Per risolvere il problema, esegui un'istruzione XA RECOVER prima di completare l'upgrade. Questa istruzione controlla le transazioni XA non eseguite.

Se viene restituita una risposta, esegui il commit delle transazioni XA emettendo un'istruzione XA COMMIT o esegui il rollback delle transazioni XA emettendo un'istruzione XA ROLLBACK.

Per controllare le transazioni XA esistenti, puoi eseguire un comando simile al seguente:

  mysql> XA RECOVER CONVERT xid;
  +----------+--------------+--------------+--------------------------
  | formatID | gtrid_length | bqual_length | data |
  +----------+--------------+--------------+--------------------------
  | 787611   | 9            | 9            | 0x787887111212345678812676152F12345678 |
  +----------+--------------+--------------+--------------------------
  1 row in set (0.00 sec)
  

In questo esempio, possiamo vedere che i valori di gtrid e bqual sono forniti in formato esadecimale, ma erroneamente concatenati. Per risolvere questo problema, devi creare manualmente questi valori utilizzando i seguenti campi:

  • gtrid = 0x787887111212345678
  • bqual = 0x812676152F12345678

Per eseguire il commit o il rollback di queste transazioni XA, puoi creare un xid da queste informazioni utilizzando un comando simile al seguente:

xid: gtrid [, bqual [, formatID ]]

mysql> XA ROLLBACK|COMMIT 0x787887111212345678,0x812676152F12345678,787611;

Supera la lunghezza massima della chiave

Si verifica il seguente errore quando una chiave specificata è troppo lunga:

[ERROR] [MY-013140] [Server] Specified key was too long; max key length is [INTEGER] bytes

Questo errore si verifica se la lunghezza della chiave fornita supera il limite consentito.

Questo problema può essere causato dalla configurazione di sql_mode. Nella versione 5.7 di MySQL, l'assenza di modalità rigide significava che gli indici potevano essere creati con restrizioni sulla lunghezza del prefisso o dell'indice.

Tuttavia, nella versione 8.0 di MySQL sono state introdotte modalità rigide come STRICT_ALL_TABLES o STRICT_TRANS_TABLES che applicano regole più rigide alla lunghezza dell'indice, causando questo errore.

Per risolvere il problema, aggiorna la lunghezza del prefisso dell'indice in modo che rientri nel numero massimo di byte indicato nel messaggio di errore. Con il protocollo predefinito UTFMB4, ogni carattere può occupare fino a 4 byte, il che significa che il numero massimo di caratteri può essere determinato dividendo il numero massimo di byte per 4.

Informazioni sui metadati non corrispondenti

Il seguente errore si verifica quando i metadati non corrispondono:

[ERROR] [MY-012084] [InnoDB] Num of Indexes in InnoDB doesn't match with Indexes from server
[ERROR] [MY-012069] [InnoDB] table: TABLE_NAME has xx columns but InnoDB dictionary has yy columns

Di seguito è riportato un altro messaggio di errore che potresti ricevere in questo caso:

[ERROR] [MY-010767] [Server] Error in fixing SE data for db_name.table_name

Questo errore si verifica se tenti di eseguire l'upgrade di tabelle con metadati non corrispondenti.

Ad esempio, se provi ad eseguire l'upgrade di tabelle con metadati non corrispondenti tra il file FRM e il dizionario dei dati InnoDB, l'upgrade non va a buon fine. In questo caso, il file FRM potrebbe essere danneggiato. Per risolvere il problema, devi eseguire il dump e il ripristino delle tabelle interessate prima di tentare l'upgrade.

Per ulteriori informazioni, consulta Tentativo di upgrade di tabelle con metadati non corrispondenti.

Per eseguire il dump e il ripristino delle tabelle interessate, puoi eseguire un comando simile al seguente:

mysqldump --databases database_name --host=$host --user=$user --password=$password > database_dump.sql

mysql> source database_dump.sql;

Il nome della chiave esterna supera i 64 caratteri

Il seguente errore si verifica quando tenti di utilizzare un nome di vincolo di chiave esterna troppo lungo:

[ERROR] [MY-012054] [InnoDB] Foreign key name:key_name is too long

Questo errore si verifica se il nome della chiave esterna supera i 64 caratteri.

Per risolvere il problema, identifica le tabelle con nomi di vincoli troppo lunghi utilizzando un comando simile al seguente:

SELECT CONSTRAINT_NAME, TABLE_NAME
FROM information_schema.REFERENTIAL_CONSTRAINTS
WHERE CHAR_LENGTH(CONSTRAINT_NAME) > 64;

Se una tabella contiene un nome di vincolo superiore a 64 caratteri, utilizza il comando ALTER TABLE per rinominare il vincolo entro questo limite di caratteri:

ALTER TABLE your_table RENAME CONSTRAINT your_long_constraint_name TO your_new_constraint_name;

Mancata corrispondenza tra maiuscole e minuscole nei nomi delle tabelle

Il seguente errore si verifica quando non utilizzi nomi di tabelle precisi:

[ERROR] [MY-013521] [Server] Table name 'SCHEMA_NAME.TABLE_NAME' containing upper case characters is not allowed with lower_case_table_names = 1.

Questo errore si verifica se i nomi delle tabelle non corrispondono.

Per risolvere questo problema, se le istanze con MySQL versione 5.7 richiedono nomi di tabelle in lettere minuscole (lower_case_table_names=1), tutti i nomi delle tabelle devono essere convertiti in lettere minuscole prima dell'upgrade a MySQL versione 8.0.

In alternativa, puoi disattivare il requisito (lower_case_table_names=0) e poi eseguire l'upgrade dell'istanza. Ricorda che se modifichi il valore del campo lower_case_table_names da 1 a 0, non puoi più modificarlo nella versione 8.0 di MySQL.

Tabelle riconosciute da InnoDB che appartengono a un motore diverso

Il seguente errore si verifica quando una tabella viene riconosciuta da InnoDB, ma in realtà appartiene a un motore diverso:

Error: Following tables are recognized by InnoDB engine while the SQL layer believes they belong to a different engine. Such situation may happen when one removed InnoDB files manually from the disk and creates a table with same name by using different engine.

Questo errore si verifica se elimini una tabella e poi ne crei una nuova con lo stesso nome, utilizzando un motore diverso.

Se nel database sono presenti tabelle riconosciute dal motore InnoDB ma non dal livello SQL, l'upgrade non va a buon fine.

Per risolvere il problema, trova tutte le tabelle nel database che non utilizzano il motore di archiviazione InnoDB:

SELECT * FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'db_name' AND ENGINE != 'InnoDB'

Per ogni tabella identificata, esegui un comando ALTER TABLE per modificare il motore di archiviazione in InnoDB.

ALTER TABLE db_name.table_name ENGINE='INNODB';

Motore di archiviazione sconosciuto partition

Il seguente errore si verifica quando tenti di utilizzare un motore di archiviazione sconosciuto:

[System] [MY-011012] [Server] Starting upgrade of data directory. [ERROR] [MY-013140] [Server] Unknown storage engine 'partition'

Questo errore si verifica se nel motore sono presenti partizioni non supportate.

MySQL versione 8.0 consente solo le seguenti partizioni nel motore di archiviazione:

  • InnoDB
  • ndbcluster

Per risolvere il problema, devi verificare la presenza di tabelle con partizioni il cui motore non sia InnoDB.

Per identificare queste tabelle, utilizza la seguente query:

SELECT TABLE_SCHEMA, TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE ENGINE NOT IN ('innodb', 'ndbcluster') AND CREATE_OPTIONS LIKE '%partitioned%';

Qualsiasi tabella segnalata dalla query deve essere aggiornata per utilizzare InnoDB o configurata per non essere partizionata. Per modificare un motore di archiviazione della tabella in InnoDB, esegui questa istruzione:

ALTER TABLE db_name.table_name ENGINE = INNODB;

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

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

  • Operazione di pre-controllo: 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, puoi esaminare i log degli errori di MySQL per verificare se è bloccata in un upgrade dei metadati o bloccata in un passaggio di precontrollo. Le cause più comuni di questo problema includono:

  • Un numero molto 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 in corso.

Troppi file aperti nel sistema

Il seguente errore si verifica quando nel sistema sono presenti troppi file aperti:

[ERROR] [MY-012592] [InnoDB] Operating system error number 23 in a file operation
[ERROR] [MY-012596] [InnoDB] Error number 23 means 'Too many open files in system'

Questo errore si verifica, ad esempio, se l'istanza contiene più di 2 milioni di tabelle. In questo caso, potresti ricevere un errore che indica che nel sistema sono presenti "troppi file aperti".

Per risolvere il problema, riduci il numero di tabelle prima dell'upgrade.

Errore di esaurimento della memoria

Quando la memoria è insufficiente, si verifica il seguente errore:

Out of memory

Questo errore si verifica se alle tabelle non viene allocata memoria sufficiente.

Quando esegui l'upgrade da MySQL 5.7 a 8.0, è necessaria memoria aggiuntiva per convertire i vecchi metadati nel nuovo dizionario dei dati.

Per risolvere il problema, ti consigliamo di avere almeno 100 KB di memoria per ogni tabella.

Per trovare il numero di tabelle, utilizza la seguente query:

SELECT table_schema AS 'Database Name', COUNT(*) AS 'Number of Tables' FROM information_schema.tables

Prima di iniziare l'upgrade, puoi aumentare temporaneamente la memoria modificando il tipo di macchina.

Per le istanze con core condiviso (ad esempio, core micro o small, inclusi db-f1-micro, db-g1-small, HA db-f1-micro, HA db-g1-small), esegui l'upgrade a un'istanza con core dedicato durante l'operazione di upgrade per evitare potenziali problemi relativi alle risorse. Puoi eseguire il downgrade al termine dell'operazione di upgrade.

Errore di arresto di MySQL

Quando provi a eseguire l'upgrade dopo un arresto anomalo, si verifica il seguente errore:

[ERROR] [MY-012526] [InnoDB] Upgrade after a crash is not supported.

Questo errore si verifica se un arresto precedente ha richiesto più tempo del previsto.

Cloud SQL esegue un arresto controllato prima dell'upgrade della versione principale. Le istanze con carichi di lavoro elevati o transazioni di lunga durata potrebbero richiedere un processo di arresto prolungato, causando potenzialmente un timeout e l'esito negativo dell'upgrade.

Per risolvere questo problema e assicurarti che l'upgrade vada a buon fine, pianificalo durante un periodo di traffico ridotto senza transazioni a esecuzione prolungata.

Passaggi successivi