En esta página, se describen los problemas conocidos y las incompatibilidades que puedes encontrar cuando realizas una actualización de versión principal de Cloud SQL para MySQL 5.7 a Cloud SQL para MySQL 8.0.
Para obtener más información sobre la actualización de la versión principal, consulta Actualiza la versión principal de la base de datos in situ y Visualiza los registros de errores.
Cambios de SQL incompatibles
En esta sección, se enumeran las incompatibilidades de SQL en Cloud SQL 5.7 y Cloud SQL 8.0 que pueden surgir cuando ejecutas la utilidad de verificación previa y durante la actualización.
Palabras clave reservadas
El siguiente es un ejemplo de un mensaje de error:
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.
Algunas palabras clave, como GROUPS, LEAD o RANK, ahora se clasifican como reservadas en la versión 8.0 de MySQL. Esto significa que algunas palabras que antes se usaban como identificadores ahora se pueden considerar ilegales. Para corregir las sentencias afectadas, usa comillas para el identificador o cambia su nombre.
Para obtener una lista completa de palabras clave, consulta Palabras clave y palabras reservadas.
Se quitaron ASC/DESC con la cláusula GROUP BY
El siguiente es un ejemplo de un mensaje de error:
[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'
El siguiente es otro ejemplo de mensaje de error:
[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.
Las consultas que antes dependían de la ordenación GROUP BY pueden producir resultados que difieran de las versiones anteriores de MySQL. Para conservar un orden determinado, proporciona una cláusula ORDER BY.
Si un procedimiento almacenado, un activador o una definición de evento contienen una consulta que usa ASC o DESC con la cláusula GROUP BY, la consulta de ese objeto necesita una cláusula ORDER BY.
Para obtener más información, consulta Cómo quitar la sintaxis de GROUP BY ASC y DESC.
Combinación de datos espaciales con otros tipos como clave
El siguiente es un ejemplo de un mensaje de error:
[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
En MySQL 8.0 y versiones posteriores, un índice no puede contener una combinación de tipos de datos espaciales y otros. Debes quitar la clave y crear una nueva que sea compatible con la versión 8.0 o posterior de MySQL. Para obtener más información, consulta Índices espaciales. Para identificar los índices de datos espaciales, usa una consulta similar a la siguiente:
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';
Caracteres UTF8 no válidos
El siguiente es un ejemplo de un mensaje de error:
[ERROR] [MY-010765] [Server] Error in Creating DD entry for %s.%s [ERROR] [MY-013140] [Server] Invalid utf8 character string: invalid_string
Si una definición de tabla contiene caracteres UTF-8 no válidos, es posible que falle la conversión de las definiciones de tabla en el diccionario de datos. Para solucionar este problema, reemplaza los caracteres no válidos por sus caracteres UTF8 correspondientes o quítalos por completo.
Para identificar y corregir los caracteres no válidos, puedes usar una consulta similar a la siguiente:
SHOW CREATE TABLE table_name; ALTER TABLE table_name MODIFY COLUMN column_name data_type comment=''; // removing invalid utf8 character from comment
Transacciones XA no confirmadas
El siguiente es un ejemplo de un mensaje de error:
[ERROR] [MY-013527] [Server] Upgrade cannot proceed due to an existing prepared XA transactions
Si hay transacciones XA sin confirmar, la actualización de versión principal in situ falla. Para solucionar este problema, ejecuta una instrucción XA RECOVER antes de completar la actualización. Esta instrucción verifica si hay transacciones XA sin confirmar. Si se devuelve una respuesta, confirma las transacciones de XA con una instrucción XA COMMIT o revierte las transacciones de XA con una instrucción XA ROLLBACK. Para verificar las transacciones XA existentes, puedes ejecutar un comando similar al siguiente:
mysql> XA RECOVER CONVERT xid; +----------+--------------+--------------+-------------------------- | formatID | gtrid_length | bqual_length | data | +----------+--------------+--------------+-------------------------- | 787611 | 9 | 9 | 0x787887111212345678812676152F12345678 | +----------+--------------+--------------+-------------------------- 1 row in set (0.00 sec)
En este ejemplo, podemos ver que los valores de gtrid y bqual se proporcionan en formato hexadecimal, pero, de forma errónea, se concatenan. Para solucionar este problema, debes construir manualmente estos valores con los siguientes campos:
gtrid = 0x787887111212345678bqual = 0x812676152F12345678
Para confirmar o revertir estas transacciones XA, puedes crear un xid a partir de esta información con un comando similar al siguiente:
xid: gtrid [, bqual [, formatID ]] mysql> XA ROLLBACK|COMMIT 0x787887111212345678,0x812676152F12345678,787611;
Se excedió la longitud máxima de la clave
El siguiente es un ejemplo de un mensaje de error:
[ERROR] [MY-013140] [Server] Specified key was too long; max key length is [INTEGER] bytes
Este problema puede deberse a la configuración de sql_mode. En la versión 5.7 de MySQL, la ausencia de modos estrictos significaba que los índices se podían crear con restricciones en la longitud del prefijo o del índice.
Sin embargo, en la versión 8.0 de MySQL, se introdujeron modos estrictos, como STRICT_ALL_TABLES o STRICT_TRANS_TABLES, que aplicaban reglas más estrictas sobre la longitud del índice, lo que provoca este error.
Para solucionar el problema, actualiza la longitud del prefijo del índice para que esté dentro de la cantidad máxima de bytes que se indica en el mensaje de error. Con el protocolo predeterminado de UTFMB4, cada carácter puede ocupar hasta 4 bytes, lo que significa que la cantidad máxima de caracteres se puede determinar dividiendo la cantidad máxima de bytes por 4.
Información de metadatos que no coincide
El siguiente es un ejemplo de un mensaje de error:
[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
El siguiente es otro ejemplo de mensaje de error:
[ERROR] [MY-010767] [Server] Error in fixing SE data for db_name.table_name
Si intentas actualizar tablas con metadatos que no coinciden entre el archivo .frm y el diccionario de InnoDB, la actualización fallará. En este caso, es posible que el archivo .frm esté dañado. Para solucionar el problema, debes volcar y restablecer las tablas afectadas antes de intentar realizar la actualización.
Para obtener más información, consulta Intento de actualizar tablas con metadatos no coincidentes.
Para volcar y restablecer las tablas afectadas, puedes ejecutar un comando similar al siguiente:
mysqldump --databases database_name --host=$host --user=$user --password=$password > database_dump.sql mysql> source database_dump.sql;
El nombre de la clave externa tiene más de 64 caracteres
El siguiente es un ejemplo de un mensaje de error:
[ERROR] [MY-012054] [InnoDB] Foreign key name:key_name is too long
Este error indica que los nombres de las restricciones de clave externa de las tablas no pueden tener más de 64 caracteres. Para identificar tablas con nombres de restricciones demasiado largos, puedes usar un comando similar al siguiente:
SELECT CONSTRAINT_NAME, TABLE_NAME FROM information_schema.REFERENTIAL_CONSTRAINTS WHERE CHAR_LENGTH(CONSTRAINT_NAME) > 64;
Si una tabla contiene un nombre de restricción que supera los 64 caracteres, usa el comando ALTER TABLE para cambiar el nombre de la restricción dentro de este límite de caracteres:
ALTER TABLE your_table RENAME CONSTRAINT your_long_constraint_name TO your_new_constraint_name;
Las letras no coinciden en el uso de mayúsculas y minúsculas en los nombres de las tablas
El siguiente es un ejemplo de un mensaje de error:
[ERROR] [MY-013521] [Server] Table name 'SCHEMA_NAME.TABLE_NAME' containing upper case characters is not allowed with lower_case_table_names = 1.
Si las instancias de la versión 5.7 de MySQL requieren nombres de tablas en minúsculas (lower_case_table_names=1), todos los nombres de tablas se deben convertir a minúsculas antes de actualizar a la versión 8.0 de MySQL.
Como alternativa, puedes inhabilitar el requisito (lower_case_table_names=0) y, luego, actualizar la instancia. Recuerda que, si cambias el valor del campo lower_case_table_names de 1 a 0, no podrás volver a cambiar el valor en la versión 8.0 de MySQL.
Tablas reconocidas por InnoDB que pertenecen a un motor diferente
El siguiente es un ejemplo de un mensaje de error:
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.
Si hay tablas en la base de datos que el motor InnoDB reconoce y la capa de SQL no, la actualización falla.
Para encontrar todas las tablas de la base de datos que no usan el motor de almacenamiento InnoDB, haz lo siguiente:
SELECT * FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'db_name' AND ENGINE != 'InnoDB'
Para cada tabla identificada, ejecuta un comando ALTER TABLE para cambiar su motor de almacenamiento a InnoDB.
ALTER TABLE db_name.table_name ENGINE='INNODB';
Partición del motor de almacenamiento desconocida
El siguiente es un ejemplo de un mensaje de error:
[System] [MY-011012] [Server] Starting upgrade of data directory. [ERROR] [MY-013140] [Server] Unknown storage engine 'partition'
La versión 8.0 de MySQL no permite particiones en el motor que no sean InnoDB y ndbcluster. Debes verificar si hay tablas con particiones y cuyo motor no sea InnoDB. Para identificar estas tablas, ejecuta la siguiente consulta:
SELECT TABLE_SCHEMA, TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE ENGINE NOT IN ('innodb', 'ndbcluster') AND CREATE_OPTIONS LIKE '%partitioned%';
Todas las tablas que informe la consulta deben actualizarse para usar InnoDB o configurarse como no particionadas. Para cambiar el motor de almacenamiento de una tabla a InnoDB, ejecuta esta instrucción:
ALTER TABLE db_name.table_name ENGINE = INNODB;
La operación de MVU se ejecuta durante más tiempo.
Existen dos tareas subyacentes asociadas con una actualización de versión principal:
- Operación de verificación previa: Muestra un error de tiempo de espera si no finaliza en tres horas.
- Operación de actualización: Muestra un error de tiempo de espera si no finaliza en seis horas.
Si la instancia tiene una operación MAJOR_VERSION_UPGRADE en curso durante un período más largo de lo esperado, puedes investigar los registros de errores de MySQL para verificar si está bloqueada en una actualización de metadatos o si se detuvo en algún paso de verificación previa. Las causas más comunes de este problema incluyen las siguientes:
- Una gran cantidad de tablas, vistas o índices
- Recursos insuficientes, como CPU o memoria
- Transacciones principales que bloquean el cierre de las bases de datos para que comience el proceso de actualización. Puedes usar la consola Trusted Cloud by S3NS para verificar los procesos actuales.
Hay demasiados archivos abiertos en el sistema.
El siguiente es un ejemplo de un mensaje de error:
[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'
Si la instancia contiene más de 2 millones de tablas, es posible que recibas un error que indique que hay "demasiados archivos abiertos en el sistema". Es posible que debas reducir la cantidad de tablas a menos de 2 millones antes de actualizar.
Error de memoria insuficiente
Cuando actualizas de MySQL 5.7 a 8.0, se requiere memoria adicional para convertir los metadatos antiguos en el nuevo diccionario de datos. Para evitar recibir un error de "memoria insuficiente" durante la actualización de versión principal, Cloud SQL recomienda tener al menos 100 KB de memoria para cada tabla.
Para encontrar la cantidad de tablas, usa la siguiente consulta:
SELECT table_schema AS 'Database Name', COUNT(*) AS 'Number of Tables' FROM information_schema.tables
Para solucionar el problema, antes de comenzar la actualización, puedes aumentar la memoria de forma temporal cambiando el tipo de máquina.
En el caso de las instancias con núcleos compartidos (por ejemplo, núcleos micro o pequeños, incluidos db-f1-micro, db-g1-small, HA db-f1-micro y HA db-g1-small), actualiza a una instancia con un núcleo dedicado durante la operación de actualización para evitar posibles problemas relacionados con los recursos. Puedes cambiar a una versión anterior después de que finalice la operación de actualización.
Error de cierre de MySQL
El siguiente es un ejemplo de un mensaje de error:
[ERROR] [MY-012526] [InnoDB] Upgrade after a crash is not supported.
Cloud SQL realiza un cierre limpio antes de la actualización de versión principal. Las instancias con cargas de trabajo pesadas o transacciones de larga duración pueden experimentar un proceso de apagado prolongado, lo que podría provocar un tiempo de espera agotado y un error en la actualización. Para asegurarte de que la actualización se realice correctamente, planifícala durante un período de poco tráfico y sin transacciones de larga duración.