Questa pagina descrive i problemi e le incompatibilità noti che potresti riscontrare quando esegui un upgrade della versione principale da Cloud SQL per MySQL 5.7 a Cloud SQL per MySQL 8.0.
Per ulteriori informazioni sull'upgrade della versione principale, vedi 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 possono verificarsi quando esegui l'utilità di pre-controllo e durante l'upgrade.
Parole chiave riservate
Di seguito è riportato un esempio di messaggio di errore:
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.
Alcune parole chiave, come GROUPS, LEAD o RANK,
ora sono classificate come riservate in MySQL versione 8.0. Ciò significa che alcune
parole precedentemente utilizzate come identificatori ora potrebbero essere considerate illegali. Per correggere
le istruzioni interessate, utilizza le virgolette per l'identificatore o rinomina l'identificatore.
Per un elenco completo delle parole chiave, consulta Parole chiave e parole riservate.
Rimossa la clausola ASC/DESC con GROUP BY
Di seguito è riportato un esempio di messaggio di errore:
[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 esempio di messaggio di errore:
[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.
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.
Se una procedura, un trigger o una definizione di evento archiviati 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
Di seguito è riportato un esempio di messaggio di 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
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 ulteriori informazioni, consulta Indici spaziali. Per identificare gli indici dei dati spaziali, utilizza 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
Di seguito è riportato un esempio di messaggio di errore:
[ERROR] [MY-010765] [Server] Error in Creating DD entry for %s.%s [ERROR] [MY-013140] [Server] Invalid utf8 character string: invalid_string
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 questo 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
Di seguito è riportato un esempio di messaggio di errore:
[ERROR] [MY-013527] [Server] Upgrade cannot proceed due to an existing prepared XA transactions
Se sono presenti transazioni XA non commit,
l'upgrade in loco della versione principale non va a buon fine. Per risolvere il problema, esegui un'istruzione
XA RECOVER
prima di completare l'upgrade. Questa istruzione controlla le transazioni XA non sottoposte a commit. 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 concatenati erroneamente. Per risolvere
questo problema, devi creare manualmente questi valori utilizzando i seguenti campi:
gtrid = 0x787887111212345678bqual = 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
Di seguito è riportato un esempio di messaggio di errore:
[ERROR] [MY-013140] [Server] Specified key was too long; max key length is [INTEGER] bytes
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 limitazioni 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
Di seguito è riportato un esempio di messaggio di errore:
[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 esempio di messaggio di errore:
[ERROR] [MY-010767] [Server] Error in fixing SE data for db_name.table_name
Se provi ad eseguire l'upgrade di tabelle con metadati non corrispondenti tra il file frm e il dizionario InnoDB, l'upgrade non riesce. 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
Di seguito è riportato un esempio di messaggio di errore:
[ERROR] [MY-012054] [InnoDB] Foreign key name:key_name is too long
Questo errore indica che i nomi dei vincoli di chiave esterna delle tabelle non possono superare i 64 caratteri. Per identificare le tabelle con nomi di vincoli troppo lunghi, puoi utilizzare 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
Di seguito è riportato un esempio di messaggio di errore:
[ERROR] [MY-013521] [Server] Table name 'SCHEMA_NAME.TABLE_NAME' containing upper case characters is not allowed with lower_case_table_names = 1.
Se le istanze con MySQL versione 5.7 richiedono nomi di tabelle in minuscolo (lower_case_table_names=1),
tutti i nomi delle tabelle devono essere convertiti in minuscolo 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
Di seguito è riportato un esempio di messaggio di errore:
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.
Se nel database sono presenti tabelle riconosciute dal motore InnoDB ma non dal livello SQL, l'upgrade non va a buon fine.
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';
Partizione del motore di archiviazione sconosciuta
Di seguito è riportato un esempio di messaggio di errore:
[System] [MY-011012] [Server] Starting upgrade of data directory. [ERROR] [MY-013140] [Server] Unknown storage engine 'partition'
La versione 8.0 di MySQL non consente partizioni nel motore diverse da InnoDB e ndbcluster. Devi controllare le tabelle con partizioni il cui motore non è InnoDB. Per identificare queste tabelle, esegui questa 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 il motore di archiviazione di una 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 pre-controllo. Le cause più comuni di questo problema sono:
- 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 Trusted Cloud by S3NS per controllare i processi attuali.
Troppi file aperti nel sistema
Di seguito è riportato un esempio di messaggio di errore:
[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'
Se l'istanza contiene più di 2 milioni di tabelle, potresti ricevere un errore che indica che "nel sistema sono aperti troppi file". Prima di eseguire l'upgrade, potrebbe essere necessario ridurre il numero di tabelle a meno di 2 milioni.
Errore di esaurimento della memoria
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 evitare di ricevere un errore "Memoria esaurita" durante l'upgrade della versione principale, Cloud SQL consiglia 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
Per risolvere il problema, 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
Di seguito è riportato un esempio di messaggio di errore:
[ERROR] [MY-012526] [InnoDB] Upgrade after a crash is not supported.
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 assicurarti che l'upgrade vada a buon fine, pianificalo in un periodo di traffico ridotto senza transazioni a esecuzione prolungata.