Cette page décrit les problèmes et les incompatibilités connus que vous pouvez rencontrer lors des opérations de vérification préalable lorsque vous effectuez une mise à niveau de version majeure de Cloud SQL pour MySQL 5.7 vers Cloud SQL pour MySQL 8.0.
Pour en savoir plus sur la mise à niveau d'une version majeure, consultez les pages Mettre à niveau la version majeure de la base de données sur place et Afficher les journaux d'erreurs.
Modifications SQL incompatibles
Cette section liste les incompatibilités SQL dans Cloud SQL 5.7 et Cloud SQL 8.0 que vous pouvez rencontrer lors de l'exécution de l'utilitaire de vérification préalable ou pendant la mise à niveau. Elle fournit également des suggestions pour résoudre chacun de ces problèmes.
Mots clés réservés
L'erreur suivante se produit lorsque vous essayez d'utiliser un mot clé réservé :
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.
Cette erreur se produit si vous essayez d'utiliser des mots clés désormais classés comme réservés dans MySQL version 8.0, tels que les suivants :
GROUPSLEADRANK
Cela signifie que certains mots précédemment utilisés comme identifiants peuvent désormais être considérés comme illégaux. Pour résoudre ce problème, corrigez les instructions concernées en utilisant des guillemets pour les identifiants ou en renommant l'identifiant.
Pour obtenir la liste complète des mots clés, consultez Mots clés et mots réservés.
Suppression de ASC/DESC avec la clause GROUP BY
L'erreur suivante se produit lorsque vous essayez d'utiliser ASC/DESC avec la clause 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'
Voici un autre message d'erreur que vous pourriez recevoir dans ce cas :
[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.
Cette erreur se produit si vous essayez de trier votre requête à l'aide de GROUP BY.
Les requêtes qui s'appuyaient auparavant sur le tri GROUP BY peuvent produire des résultats différents de ceux des versions précédentes de MySQL. Pour conserver un ordre de tri donné, fournissez une clause ORDER BY.
Pour résoudre le problème, utilisez la clause ORDER BY. Par exemple, si une procédure stockée, un déclencheur ou une définition d'événement contient une requête qui utilise ASC ou DESC avec la clause GROUP BY, la requête de cet objet doit comporter une clause ORDER BY.
Pour en savoir plus, consultez Supprimer la syntaxe pour GROUP BY ASC et DESC.
Mélange de données spatiales avec d'autres types de données comme clé
L'erreur suivante se produit lorsque vous utilisez la mauvaise touche de préfixe :
[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
Cette erreur se produit si vous essayez d'utiliser une combinaison de données spatiales avec d'autres types comme clé.
Dans MySQL 8.0 et versions ultérieures, un index ne peut pas contenir un mélange de types de données spatiales et autres. Vous devez supprimer la clé et en créer une compatible avec MySQL version 8.0 ou ultérieure. Pour en savoir plus, consultez Index spatiaux.
Pour résoudre ce problème, identifiez les index de données spatiales à l'aide d'une requête semblable à la suivante :
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';
Caractères UTF8 non valides
L'erreur suivante se produit lorsque vous utilisez des chaînes de caractères UTF8 non valides :
[ERROR] [MY-010765] [Server] Error in Creating DD entry for %s.%s [ERROR] [MY-013140] [Server] Invalid utf8 character string: invalid_string
Cette erreur se produit si les commandes contiennent des caractères UTF8 non valides. Par exemple, si une définition de table contient des caractères UTF8 non valides, la conversion des définitions de table en dictionnaire de données peut échouer.
Pour résoudre ce problème, remplacez les caractères non valides par leurs caractères UTF8 correspondants ou supprimez-les complètement.
Pour identifier et corriger les caractères non valides, vous pouvez utiliser une requête semblable à celle-ci :
SHOW CREATE TABLE table_name; ALTER TABLE table_name MODIFY COLUMN column_name data_type comment=''; // removing invalid utf8 character from comment
Transactions XA non validées
L'erreur suivante se produit lorsqu'il existe des transactions XA préparées :
[ERROR] [MY-013527] [Server] Upgrade cannot proceed due to an existing prepared XA transactions
Cette erreur se produit s'il existe des transactions XA non validées, ce qui entraîne l'échec de la mise à niveau sur place de la version majeure.
Pour résoudre ce problème, exécutez une instruction XA RECOVER avant de terminer la mise à niveau. Cette instruction recherche les transactions XA non validées.
Si une réponse est renvoyée, validez les transactions XA en émettant une instruction XA COMMIT ou annulez-les en émettant une instruction XA ROLLBACK.
Pour vérifier les transactions XA existantes, vous pouvez exécuter une commande semblable à la suivante :
mysql> XA RECOVER CONVERT xid; +----------+--------------+--------------+-------------------------- | formatID | gtrid_length | bqual_length | data | +----------+--------------+--------------+-------------------------- | 787611 | 9 | 9 | 0x787887111212345678812676152F12345678 | +----------+--------------+--------------+-------------------------- 1 row in set (0.00 sec)
Dans cet exemple, nous pouvons voir que les valeurs de gtrid et bqual sont fournies au format hexadécimal, mais qu'elles sont concaténées par erreur. Pour résoudre ce problème, vous devez créer manuellement ces valeurs à l'aide des champs suivants :
gtrid = 0x787887111212345678bqual = 0x812676152F12345678
Pour valider ou annuler ces transactions XA, vous pouvez créer un xid à partir de ces informations à l'aide d'une commande semblable à la suivante :
xid: gtrid [, bqual [, formatID ]] mysql> XA ROLLBACK|COMMIT 0x787887111212345678,0x812676152F12345678,787611;
Dépasse la longueur maximale de la clé
L'erreur suivante se produit lorsqu'une clé spécifiée est trop longue :
[ERROR] [MY-013140] [Server] Specified key was too long; max key length is [INTEGER] bytes
Cette erreur se produit si la longueur de la clé fournie dépasse la limite autorisée.
Ce problème peut être dû à la configuration de sql_mode. Dans MySQL 5.7, l'absence de modes stricts signifiait que les index pouvaient être créés avec une restriction sur la longueur du préfixe ou de l'index.
Toutefois, dans la version 8.0 de MySQL, des modes stricts tels que STRICT_ALL_TABLES ou STRICT_TRANS_TABLES ont été introduits. Ils appliquent des règles plus strictes sur la longueur des index, ce qui provoque cette erreur.
Pour résoudre le problème, mettez à jour la longueur du préfixe d'index afin qu'elle ne dépasse pas le nombre maximal d'octets indiqué dans le message d'erreur. Avec le protocole par défaut UTFMB4, chaque caractère peut occuper jusqu'à quatre octets. Cela signifie que le nombre maximal de caractères peut être déterminé en divisant le nombre maximal d'octets par quatre.
Informations de métadonnées incohérentes
L'erreur suivante se produit lorsque les métadonnées ne correspondent pas :
[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
Voici un autre message d'erreur que vous pourriez recevoir dans ce cas :
[ERROR] [MY-010767] [Server] Error in fixing SE data for db_name.table_name
Cette erreur se produit si vous essayez de mettre à niveau des tables dont les métadonnées ne correspondent pas.
Par exemple, si vous essayez de mettre à niveau des tables dont les métadonnées ne correspondent pas entre le fichier FRM et le dictionnaire de données InnoDB, la mise à niveau échoue. Dans ce cas, il est possible que le fichier FRM soit corrompu. Pour résoudre ce problème, vous devez vider et restaurer les tables concernées avant de tenter la mise à niveau.
Pour en savoir plus, consultez Tentative de mise à niveau de tables avec des métadonnées incompatibles.
Pour vider et restaurer les tables concernées, vous pouvez exécuter une commande semblable à la suivante :
mysqldump --databases database_name --host=$host --user=$user --password=$password > database_dump.sql mysql> source database_dump.sql;
Nom de clé étrangère de plus de 64 caractères
L'erreur suivante se produit lorsque vous essayez d'utiliser un nom de contrainte de clé étrangère trop long :
[ERROR] [MY-012054] [InnoDB] Foreign key name:key_name is too long
Cette erreur se produit si le nom de la clé étrangère comporte plus de 64 caractères.
Pour résoudre le problème, identifiez les tables dont les noms de contraintes sont trop longs à l'aide d'une commande semblable à celle-ci :
SELECT CONSTRAINT_NAME, TABLE_NAME FROM information_schema.REFERENTIAL_CONSTRAINTS WHERE CHAR_LENGTH(CONSTRAINT_NAME) > 64;
Si le nom d'une contrainte dans une table dépasse 64 caractères, utilisez la commande ALTER TABLE pour renommer la contrainte en respectant cette limite de caractères :
ALTER TABLE your_table RENAME CONSTRAINT your_long_constraint_name TO your_new_constraint_name;
La casse des noms de tables ne correspond pas
L'erreur suivante se produit lorsque vous n'utilisez pas de noms de tables précis :
[ERROR] [MY-013521] [Server] Table name 'SCHEMA_NAME.TABLE_NAME' containing upper case characters is not allowed with lower_case_table_names = 1.
Cette erreur se produit si les noms de tables ne respectent pas la même casse.
Pour résoudre ce problème, si les instances de la version 5.7 de MySQL nécessitent des noms de tables en minuscules (lower_case_table_names=1), tous les noms de tables doivent être convertis en minuscules avant la mise à niveau vers la version 8.0 de MySQL.
Vous pouvez également désactiver l'exigence (lower_case_table_names=0), puis mettre à niveau l'instance. N'oubliez pas que si vous remplacez la valeur du champ lower_case_table_names de 1 par 0, vous ne pourrez plus la modifier dans la version 8.0 de MySQL.
Tables reconnues par InnoDB qui appartiennent à un autre moteur
L'erreur suivante se produit lorsqu'une table est reconnue par InnoDB, mais qu'elle appartient en réalité à un autre moteur :
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.
Cette erreur se produit si vous supprimez une table, puis que vous en créez une autre portant le même nom, mais en utilisant un moteur différent.
Si la base de données contient des tables que le moteur InnoDB reconnaît, mais pas la couche SQL, la mise à niveau échoue.
Pour résoudre ce problème, recherchez toutes les tables de la base de données qui n'utilisent pas le moteur de stockage InnoDB :
SELECT * FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'db_name' AND ENGINE != 'InnoDB'
Pour chaque table identifiée, exécutez une commande ALTER TABLE afin de modifier son moteur de stockage en InnoDB.
ALTER TABLE db_name.table_name ENGINE='INNODB';
Moteur de stockage inconnu partition
L'erreur suivante se produit lorsque vous essayez d'utiliser un moteur de stockage inconnu :
[System] [MY-011012] [Server] Starting upgrade of data directory. [ERROR] [MY-013140] [Server] Unknown storage engine 'partition'
Cette erreur se produit si le moteur contient des partitions non compatibles.
La version 8.0 de MySQL n'autorise que les partitions suivantes dans le moteur de stockage :
InnoDBndbcluster
Pour résoudre ce problème, vous devez rechercher les tables avec des partitions dont le moteur n'est pas InnoDB.
Pour identifier ces tables, utilisez la requête suivante :
SELECT TABLE_SCHEMA, TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE ENGINE NOT IN ('innodb', 'ndbcluster') AND CREATE_OPTIONS LIKE '%partitioned%';
Toutes les tables signalées par la requête doivent être mises à jour pour utiliser InnoDB ou être configurées comme non partitionnées. Pour remplacer le moteur de stockage d'une table par InnoDB, exécutez l'instruction suivante :
ALTER TABLE db_name.table_name ENGINE = INNODB;
Opération MVU en cours depuis plus longtemps
La mise à niveau d'une version majeure implique deux tâches sous-jacentes :
- Opération de prévérification : renvoie une erreur de délai avant expiration si elle n'est pas terminée au bout de trois heures.
- Opération de mise à niveau : renvoie une erreur de délai avant expiration si elle n'est pas terminée dans les six heures.
Si l'instance a une opération MAJOR_VERSION_UPGRADE en cours depuis plus longtemps que prévu, vous pouvez examiner les journaux d'erreurs MySQL pour vérifier si elle est bloquée lors d'une mise à niveau des métadonnées ou bloquée à une étape de vérification préalable. Voici les causes les plus courantes de ce problème :
- Un très grand nombre de tables, de vues ou d'index
- Ressources insuffisantes (processeur ou mémoire, par exemple)
- Transactions majeures bloquant l'arrêt des bases de données pour que le processus de mise à niveau puisse commencer. Vous pouvez utiliser la console Google Cloud pour vérifier les processus en cours.
Trop de fichiers ouverts dans le système
L'erreur suivante se produit lorsque le système comporte trop de fichiers ouverts :
[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'
Cette erreur se produit, par exemple, si l'instance contient plus de deux millions de tables. Dans ce cas, vous pouvez recevoir un message d'erreur indiquant qu'il y a "trop de fichiers ouverts dans le système".
Pour résoudre ce problème, réduisez le nombre de tables avant la mise à niveau.
Erreur de mémoire insuffisante
L'erreur suivante se produit lorsque vous manquez de mémoire :
Out of memory
Cette erreur se produit si les tables ne disposent pas de suffisamment de mémoire.
Lorsque vous passez de MySQL 5.7 à MySQL 8.0, de la mémoire supplémentaire est nécessaire pour convertir les anciennes métadonnées vers le nouveau dictionnaire de données.
Pour résoudre ce problème, nous vous recommandons de disposer d'au moins 100 Ko de mémoire pour chaque table.
Pour trouver le nombre de tables, utilisez la requête suivante :
SELECT table_schema AS 'Database Name', COUNT(*) AS 'Number of Tables' FROM information_schema.tables
Avant de commencer la mise à niveau, vous pouvez augmenter temporairement la mémoire en modifiant le type de machine.
Pour les instances à cœur partagé (par exemple, les cœurs micro ou petits, y compris db-f1-micro, db-g1-small, HA db-f1-micro et HA db-g1-small), passez à une instance à cœur dédié lors de l'opération de mise à niveau pour éviter tout problème potentiel lié aux ressources. Vous pourrez le rétrograder une fois l'opération de mise à niveau terminée.
Erreur d'arrêt de MySQL
L'erreur suivante se produit lorsque vous essayez de mettre à niveau après un plantage :
[ERROR] [MY-012526] [InnoDB] Upgrade after a crash is not supported.
Cette erreur se produit si un arrêt précédent a pris plus de temps que prévu.
Cloud SQL effectue un arrêt propre avant la mise à niveau de la version majeure. Les instances avec des charges de travail importantes ou des transactions de longue durée peuvent connaître un processus d'arrêt prolongé, ce qui peut entraîner un délai avant expiration et l'échec de la mise à niveau.
Pour résoudre ce problème et vous assurer que la mise à niveau réussit, planifiez-la pendant une période de faible trafic, sans transactions de longue durée.