Esta página descreve problemas conhecidos e incompatibilidades com que se pode deparar quando faz uma atualização de versão principal do Cloud SQL para MySQL 5.7 para o Cloud SQL para MySQL 8.0.
Para mais informações sobre a atualização da versão principal, consulte os artigos Atualize a versão principal da base de dados no local e Veja os registos de erros.
Alterações de SQL incompatíveis
Esta secção apresenta uma lista de incompatibilidades de SQL no Cloud SQL 5.7 e no Cloud SQL 8.0 que podem surgir quando executa o utilitário de pré-verificação e durante a atualização.
Palavras-chave reservadas
Segue-se um exemplo de uma mensagem de erro:
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.
Algumas palavras-chave, como GROUPS, LEAD ou RANK, são agora classificadas como reservadas na versão 8.0 do MySQL. Isto significa que algumas palavras usadas anteriormente como identificadores podem agora ser consideradas ilegais. Para corrigir as declarações afetadas, use as aspas nos identificadores ou mude o nome do identificador.
Para ver uma lista completa de palavras-chave, consulte o artigo Palavras-chave e palavras reservadas.
Remoção de ASC/DESC com cláusula GROUP BY
Segue-se um exemplo de uma mensagem de erro:
[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'
Segue-se outro exemplo de uma mensagem de erro:
[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.
As consultas que anteriormente dependiam da ordenação GROUP BY podem produzir resultados diferentes das versões anteriores do MySQL. Para preservar uma determinada ordem de ordenação,
forneça uma cláusula ORDER BY.
Se um procedimento armazenado, um acionador ou uma definição de evento contiver uma consulta que use ASC ou DESC com a cláusula GROUP BY, a consulta desse objeto precisa de uma cláusula ORDER BY.
Para mais informações, consulte o artigo Remova a sintaxe para GROUP BY ASC e DESC.
Mistura de dados espaciais com outros tipos como chave
Segue-se um exemplo de uma mensagem de erro:
[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
Na versão 8.0 e posteriores do MySQL, um índice não pode conter uma combinação de tipos de dados espaciais e outros. Tem de remover a chave e criar uma nova suportada na versão 8.0 ou posterior do MySQL. Para mais informações, consulte o artigo Índices espaciais. Para identificar os índices de dados espaciais, use uma consulta semelhante à seguinte:
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';
Carateres UTF8 inválidos
Segue-se um exemplo de uma mensagem de erro:
[ERROR] [MY-010765] [Server] Error in Creating DD entry for %s.%s [ERROR] [MY-013140] [Server] Invalid utf8 character string: invalid_string
Se uma definição de tabela contiver carateres UTF8 inválidos, a conversão das definições de tabela no dicionário de dados pode falhar. Para resolver este problema, substitua os carateres inválidos pelos carateres UTF8 correspondentes ou remova-os por completo.
Para identificar e resolver carateres inválidos, pode usar uma consulta semelhante à seguinte:
SHOW CREATE TABLE table_name; ALTER TABLE table_name MODIFY COLUMN column_name data_type comment=''; // removing invalid utf8 character from comment
Transações XA não comprometidas
Segue-se um exemplo de uma mensagem de erro:
[ERROR] [MY-013527] [Server] Upgrade cannot proceed due to an existing prepared XA transactions
Se existirem transações XA não comprometidas,
a atualização da versão principal no local falha. Para resolver este problema, execute uma declaração
XA RECOVER
antes de concluir a atualização. Esta declaração verifica a existência de transações XA não comprometidas. Se for devolvida uma resposta, confirme as transações XA emitindo um comando XA COMMIT ou reverta as transações XA emitindo uma declaração XA ROLLBACK. Para verificar as transações XA existentes, pode executar um comando semelhante ao seguinte:
mysql> XA RECOVER CONVERT xid; +----------+--------------+--------------+-------------------------- | formatID | gtrid_length | bqual_length | data | +----------+--------------+--------------+-------------------------- | 787611 | 9 | 9 | 0x787887111212345678812676152F12345678 | +----------+--------------+--------------+-------------------------- 1 row in set (0.00 sec)
Neste exemplo, podemos ver que os valores de gtrid e bqual são fornecidos no formato hexadecimal, mas, por engano, concatenados. Para resolver este problema, tem de criar manualmente estes valores através dos seguintes campos:
gtrid = 0x787887111212345678bqual = 0x812676152F12345678
Para confirmar ou reverter estas transações XA, pode criar um xid
a partir destas informações através de um comando semelhante ao seguinte:
xid: gtrid [, bqual [, formatID ]] mysql> XA ROLLBACK|COMMIT 0x787887111212345678,0x812676152F12345678,787611;
Excede o comprimento máximo da chave
Segue-se um exemplo de uma mensagem de erro:
[ERROR] [MY-013140] [Server] Specified key was too long; max key length is [INTEGER] bytes
Este problema pode ser causado pela configuração do sql_mode. Na versão 5.7 do MySQL, a ausência de modos rigorosos significava que os índices podiam ser criados com restrições no prefixo ou no comprimento do índice.
No entanto, na versão 8.0 do MySQL, foram introduzidos modos rigorosos, como STRICT_ALL_TABLES ou STRICT_TRANS_TABLES, que aplicavam regras mais rigorosas no comprimento do índice, o que causa este erro.
Para resolver o problema, atualize o comprimento do prefixo do índice para o número máximo de bytes indicado na mensagem de erro. Com o protocolo predefinido UTFMB4, cada caráter pode ocupar até 4 bytes, o que significa que o número máximo de carateres pode ser determinado dividindo o número máximo de bytes por 4.
Informações de metadados não correspondentes
Segue-se um exemplo de uma mensagem de erro:
[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
Segue-se outro exemplo de uma mensagem de erro:
[ERROR] [MY-010767] [Server] Error in fixing SE data for db_name.table_name
Se tentar atualizar tabelas com metadados em conflito entre o ficheiro FRM e o dicionário InnoDB, a atualização falha. Neste caso, o ficheiro FRM pode estar danificado. Para resolver o problema, tem de despejar e restaurar as tabelas afetadas antes de tentar fazer a atualização.
Para mais informações, consulte o artigo Tentativa de atualizar tabelas com metadados em conflito.
Para exportar e restaurar as tabelas afetadas, pode executar um comando semelhante ao seguinte:
mysqldump --databases database_name --host=$host --user=$user --password=$password > database_dump.sql mysql> source database_dump.sql;
O nome da chave externa tem mais de 64 carateres
Segue-se um exemplo de uma mensagem de erro:
[ERROR] [MY-012054] [InnoDB] Foreign key name:key_name is too long
Este erro indica que os nomes das restrições de chaves externas das tabelas não podem ter mais de 64 carateres. Para identificar tabelas com nomes de restrições demasiado longos, pode usar um comando semelhante ao seguinte:
SELECT CONSTRAINT_NAME, TABLE_NAME FROM information_schema.REFERENTIAL_CONSTRAINTS WHERE CHAR_LENGTH(CONSTRAINT_NAME) > 64;
Se uma tabela contiver um nome de restrição com mais de 64 carateres, use o comando ALTER TABLE para mudar o nome da restrição dentro deste limite de carateres:
ALTER TABLE your_table RENAME CONSTRAINT your_long_constraint_name TO your_new_constraint_name;
Diferença entre letras maiúsculas e minúsculas nos nomes das tabelas
Segue-se um exemplo de uma mensagem de erro:
[ERROR] [MY-013521] [Server] Table name 'SCHEMA_NAME.TABLE_NAME' containing upper case characters is not allowed with lower_case_table_names = 1.
Se as instâncias na versão 5.7 do MySQL exigirem nomes de tabelas em minúsculas (lower_case_table_names=1),
todos os nomes de tabelas têm de ser convertidos em minúsculas antes da atualização para a versão 8.0 do MySQL.
Em alternativa, pode desativar o requisito (lower_case_table_names=0)
e, em seguida, atualizar a instância. Lembre-se de que, se alterar o valor do campo lower_case_table_names de 1 para 0, não pode voltar a alterar o valor na versão 8.0 do MySQL.
Tabelas reconhecidas pelo InnoDB que pertencem a um motor diferente
Segue-se um exemplo de uma mensagem de erro:
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 existirem tabelas na base de dados que o motor InnoDB reconhece, mas a camada SQL não, a atualização falha.
Encontre todas as tabelas na base de dados que não estão a usar o motor de armazenamento InnoDB:
SELECT * FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'db_name' AND ENGINE != 'InnoDB'
Para cada tabela identificada, execute um comando ALTER TABLE para alterar o respetivo motor de armazenamento para InnoDB.
ALTER TABLE db_name.table_name ENGINE='INNODB';
Partição do motor de armazenamento desconhecida
Segue-se um exemplo de uma mensagem de erro:
[System] [MY-011012] [Server] Starting upgrade of data directory. [ERROR] [MY-013140] [Server] Unknown storage engine 'partition'
A versão 8.0 do MySQL não permite partições no motor que não sejam InnoDB
e ndbcluster. Tem de verificar se existem tabelas com partições e cujo motor não seja o InnoDB. Para identificar estas tabelas, execute esta consulta:
SELECT TABLE_SCHEMA, TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE ENGINE NOT IN ('innodb', 'ndbcluster') AND CREATE_OPTIONS LIKE '%partitioned%';
Todas as tabelas comunicadas pela consulta têm de ser atualizadas para usar o InnoDB ou configuradas para não serem particionadas. Para alterar um motor de armazenamento de tabelas para InnoDB, execute esta declaração:
ALTER TABLE db_name.table_name ENGINE = INNODB;
Operação de MVU em execução durante um período mais longo
Existem duas tarefas subjacentes associadas a uma atualização da versão principal:
- Operação de pré-verificação: devolve um erro de limite de tempo se não for concluída em três horas.
- Operação de atualização: devolve um erro de limite de tempo se não for concluída no prazo de seis horas.
Se a instância tiver uma operação MAJOR_VERSION_UPGRADE em curso durante um período mais longo do que o esperado, pode investigar os registos de erros do MySQL para verificar se está bloqueada numa atualização de metadados ou bloqueada num passo de pré-verificação. As causas mais comuns deste problema incluem o seguinte:
- Um número muito elevado de tabelas, vistas ou índices
- Recursos insuficientes, como CPU ou memória
- Transações importantes que bloqueiam o encerramento das bases de dados para que o processo de atualização seja iniciado. Pode usar a Google Cloud consola para verificar os processos atuais.
Demasiados ficheiros abertos no sistema
Segue-se um exemplo de uma mensagem de erro:
[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 a instância contiver mais de 2 milhões de tabelas, pode receber um erro a indicar que existem "demasiados ficheiros abertos no sistema". Pode ter de reduzir o número de tabelas para menos de 2 milhões antes de fazer a atualização.
Erro de falta de memória
Quando atualiza do MySQL 5.7 para o 8.0, é necessária memória adicional para converter os metadados antigos no novo dicionário de dados. Para evitar receber um erro "sem memória" durante a atualização da versão principal, o Cloud SQL recomenda ter, pelo menos, 100 KB de memória para cada tabela.
Para encontrar o número de tabelas, use a seguinte consulta:
SELECT table_schema AS 'Database Name', COUNT(*) AS 'Number of Tables' FROM information_schema.tables
Para resolver o problema, antes de iniciar a atualização, pode aumentar temporariamente a memória alterando o tipo de máquina.
Para instâncias principais partilhadas (por exemplo, núcleos micro ou pequenos, incluindo db-f1-micro, db-g1-small, HA db-f1-micro e HA db-g1-small), atualize para uma instância principal dedicada durante a operação de atualização para evitar potenciais problemas relacionados com recursos. Pode
reverter a versão após a conclusão da operação de atualização.
Erro de encerramento do MySQL
Segue-se um exemplo de uma mensagem de erro:
[ERROR] [MY-012526] [InnoDB] Upgrade after a crash is not supported.
O Cloud SQL executa um encerramento limpo antes da atualização da versão principal. As instâncias com cargas de trabalho pesadas ou transações de longa duração podem sofrer um processo de encerramento prolongado, o que pode causar um limite de tempo e a falha da atualização. Para garantir que a atualização é bem-sucedida, planeie-a durante um período de baixo tráfego sem transações de longa duração.