Nesta página, descrevemos problemas conhecidos e incompatibilidades que podem ocorrer ao fazer um upgrade de versão principal do Cloud SQL para MySQL 5.7 para o Cloud SQL para MySQL 8.0.
Para mais informações sobre o upgrade da versão principal, consulte Fazer upgrade da versão principal do banco de dados no local e Ver registros de erros.
Mudanças incompatíveis no SQL
Esta seção lista as incompatibilidades de SQL no Cloud SQL 5.7 e no Cloud SQL 8.0 que podem surgir ao executar o utilitário de pré-verificação e durante o upgrade.
Palavras-chave reservadas
Confira um exemplo de 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, agora são classificadas como reservadas na versão 8.0 do MySQL. Isso significa que algumas
palavras usadas anteriormente como identificadores agora podem ser consideradas ilegais. Para corrigir
instruções afetadas, use aspas de identificador ou renomeie o identificador.
Para uma lista completa de palavras-chave, consulte Palavras-chave e palavras reservadas.
Remoção de ASC/DESC com a cláusula GROUP BY
Confira um exemplo de 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'
Confira outro exemplo de 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 antes dependiam da classificação GROUP BY podem gerar resultados diferentes das versões anteriores do MySQL. Para preservar uma determinada ordem de classificaçã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 precisará de uma cláusula ORDER BY.
Para mais informações, consulte Remover a sintaxe de GROUP BY ASC e DESC.
Mistura de dados espaciais com outros tipos como chave
Confira um exemplo de 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
No MySQL 8.0 e versões mais recentes, um índice não pode conter uma combinação de tipos de dados espaciais e outros. Remova a chave e crie uma nova compatível com o MySQL versão 8.0 ou mais recente. Para mais informações, consulte Índices espaciais. Para identificar índices de dados espaciais, use uma consulta semelhante a esta:
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 inválidos
Confira um exemplo de 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 caracteres UTF8 inválidos, a conversão das definições em um dicionário de dados poderá falhar. Para resolver esse problema, substitua os caracteres inválidos pelos correspondentes em UTF8 ou remova-os completamente.
Para identificar e corrigir caracteres inválidos, use uma consulta semelhante a esta:
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 confirmadas
Confira um exemplo de mensagem de erro:
[ERROR] [MY-013527] [Server] Upgrade cannot proceed due to an existing prepared XA transactions
Se houver transações XA não confirmadas,
o upgrade no local da versão principal vai falhar. Para resolver esse problema, execute uma instrução
XA RECOVER
antes de concluir o upgrade. Essa instrução verifica transações XA não confirmadas. Se uma resposta for retornada, confirme as transações XA emitindo um XA COMMIT ou reverta as transações XA emitindo uma instrução XA ROLLBACK. Para verificar as transações XA atuais, execute 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, os valores de gtrid e bqual são fornecidos em formato hexadecimal, mas concatenados por engano. Para resolver esse problema, construa manualmente esses valores usando os seguintes campos:
gtrid = 0x787887111212345678bqual = 0x812676152F12345678
Para confirmar ou desfazer essas transações XA, crie um xid
com essas informações usando um comando semelhante a este:
xid: gtrid [, bqual [, formatID ]] mysql> XA ROLLBACK|COMMIT 0x787887111212345678,0x812676152F12345678,787611;
Exceder o tamanho máximo da chave
Confira um exemplo de mensagem de erro:
[ERROR] [MY-013140] [Server] Specified key was too long; max key length is [INTEGER] bytes
Esse problema pode ser causado pela configuração sql_mode. Na versão 5.7 do MySQL, a ausência de modos estritos permitia que os índices fossem criados com restrição no prefixo ou no comprimento do índice.
No entanto, na versão 8.0 do MySQL, foram introduzidos modos estritos, como STRICT_ALL_TABLES
ou STRICT_TRANS_TABLES, que aplicam regras mais rigorosas
ao comprimento do índice, causando esse erro.
Para resolver o problema, atualize o comprimento do prefixo do índice para ficar dentro do número máximo de bytes indicado na mensagem de erro. Com o protocolo padrão UTFMB4, cada caractere pode ocupar até 4 bytes. Isso significa que o número máximo de caracteres pode ser determinado dividindo o número máximo de bytes por 4.
Informações de metadados incompatíveis
Confira um exemplo de 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
Confira outro exemplo de mensagem de erro:
[ERROR] [MY-010767] [Server] Error in fixing SE data for db_name.table_name
Se você tentar fazer upgrade de tabelas com metadados incompatíveis entre o arquivo frm e o dicionário InnoDB, o upgrade vai falhar. Nesse caso, o arquivo .frm pode estar corrompido. Para resolver o problema, faça um dump e restaure as tabelas afetadas antes de tentar fazer o upgrade.
Para mais informações, consulte Tentativa de fazer upgrade de tabelas com metadados incompatíveis.
Para fazer o dump e restaurar as tabelas afetadas, execute um comando semelhante ao seguinte:
mysqldump --databases database_name --host=$host --user=$user --password=$password > database_dump.sql mysql> source database_dump.sql;
Nome da chave estrangeira com mais de 64 caracteres
Confira um exemplo de mensagem de erro:
[ERROR] [MY-012054] [InnoDB] Foreign key name:key_name is too long
Esse erro indica que os nomes de restrição de chave externa das tabelas não podem ter mais de 64 caracteres. Para identificar tabelas com nomes de restrição muito longos, use um comando semelhante a este:
SELECT CONSTRAINT_NAME, TABLE_NAME FROM information_schema.REFERENTIAL_CONSTRAINTS WHERE CHAR_LENGTH(CONSTRAINT_NAME) > 64;
Se uma tabela tiver um nome de restrição com mais de 64 caracteres, use o comando
ALTER TABLE para renomear a restrição dentro desse limite
de caracteres:
ALTER TABLE your_table RENAME CONSTRAINT your_long_constraint_name TO your_new_constraint_name;
Capitalização de letras incompatível nos nomes das tabelas
Confira um exemplo de 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 letras minúsculas (lower_case_table_names=1),
todos os nomes de tabelas precisarão ser convertidos para letras minúsculas antes do upgrade para a versão 8.0 do MySQL.
Como alternativa, desative o requisito (lower_case_table_names=0) e faça upgrade da instância. Se você mudar o valor do campo
lower_case_table_names de 1 para 0,
não será possível mudar o valor de volta na versão 8.0 do MySQL.
Tabelas reconhecidas pelo InnoDB que pertencem a um mecanismo diferente
Confira um exemplo de 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 houver tabelas no banco de dados que o mecanismo InnoDB reconhece, mas a camada SQL não, o upgrade vai falhar.
Encontre todas as tabelas no banco de dados que não estão usando o mecanismo 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 mudar o mecanismo de armazenamento para InnoDB.
ALTER TABLE db_name.table_name ENGINE='INNODB';
Partição de mecanismo de armazenamento desconhecida
Confira um exemplo de 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 mecanismo que não sejam InnoDB
e ndbcluster. Verifique se há tabelas com partições e cujo
mecanismo não seja o InnoDB. Para identificar essas 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 informadas pela consulta precisam ser atualizadas para usar o InnoDB ou configuradas para não serem particionadas. Para mudar o mecanismo de armazenamento de uma tabela para InnoDB, execute esta instrução:
ALTER TABLE db_name.table_name ENGINE = INNODB;
Operação de MVU em execução por mais tempo
Há duas tarefas associadas a uma atualização de versão principal:
- Operação de pré-verificação: retorna um erro de tempo limite se não for concluída em três horas.
- Operação de upgrade: retorna um erro de tempo limite se não for concluída em seis horas.
Se a instância tiver uma operação MAJOR_VERSION_UPGRADE em andamento por
um período maior do que o esperado, investigue os registros de erros do MySQL para verificar se
ela está bloqueada em um upgrade de metadados ou travada em alguma etapa de pré-verificação. As causas mais comuns desse problema são:
- Um número muito grande de tabelas, visualizações ou índices
- Recursos insuficientes, como CPU ou memória
- Transações principais bloqueando o encerramento de bancos de dados para que o processo de upgrade comece. Use o console Trusted Cloud by S3NS para verificar os processos atuais.
Há muitos arquivos abertos no sistema
Confira um exemplo de 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 tiver mais de 2 milhões de tabelas, talvez você receba um erro indicando que há "muitos arquivos abertos no sistema". Talvez seja necessário reduzir o número de tabelas para menos de 2 milhões antes de fazer upgrade.
Erro de falta de memória
Ao fazer upgrade do MySQL 5.7 para o 8.0, é necessário ter mais memória para converter metadados antigos no novo dicionário de dados. Para evitar receber um erro de "falta de memória" durante o upgrade 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, aumente temporariamente a memória mudando o tipo de máquina.
Para instâncias de núcleo compartilhado (por exemplo, núcleos micro ou small, incluindo db-f1-micro, db-g1-small, HA db-f1-micro, HA db-g1-small), faça upgrade para uma instância de núcleo dedicado durante a operação de upgrade para evitar possíveis problemas relacionados a recursos. É possível fazer downgrade depois que a operação de upgrade for concluída.
Erro de encerramento do MySQL
Confira um exemplo de mensagem de erro:
[ERROR] [MY-012526] [InnoDB] Upgrade after a crash is not supported.
O Cloud SQL faz um desligamento limpo antes do upgrade da versão principal. As instâncias com cargas de trabalho pesadas ou transações de longa duração podem passar por um processo de desligamento prolongado, o que pode causar um tempo limite e a falha da atualização. Para garantir que o upgrade seja bem-sucedido, planeje-o durante um período de baixo tráfego sem transações de longa duração.