Nesta página, descrevemos problemas e incompatibilidades conhecidos que podem ocorrer durante as operações de pré-verificação 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
Nesta seção, listamos incompatibilidades de SQL no Cloud SQL 5.7 e no Cloud SQL 8.0 que podem ocorrer ao executar o utilitário de pré-verificação ou durante o upgrade. Também oferecemos sugestões de como corrigir cada uma delas.
Palavras-chave reservadas
O seguinte erro ocorre quando você tenta usar uma palavra-chave reservada:
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.
Esse erro ocorre se você tentar usar palavras-chave agora classificadas como reservadas no MySQL versão 8.0, como as seguintes:
GROUPSLEADRANK
Isso significa que algumas palavras usadas anteriormente como identificadores agora podem ser consideradas ilegais. Para resolver esse problema, corrija as instruções afetadas usando aspas no 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
O seguinte erro ocorre quando você tenta usar ASC/DESC com a
cláusula 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'
Esta é outra mensagem de erro que você pode receber nesse caso:
[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.
Esse erro ocorre se você tentar classificar a consulta usando GROUP BY.
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.
Para resolver o problema, use a cláusula ORDER BY. Por exemplo, se um procedimento armazenado, um gatilho 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
O seguinte erro ocorre quando você usa a chave de prefixo errada:
[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
Esse erro ocorre se você tentar usar uma combinação de dados espaciais com outros tipos como chave.
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 resolver esse problema, identifique os índices de dados espaciais usando 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
O seguinte erro ocorre quando você usa strings de caracteres UTF8 inválidas:
[ERROR] [MY-010765] [Server] Error in Creating DD entry for %s.%s [ERROR] [MY-013140] [Server] Invalid utf8 character string: invalid_string
Esse erro ocorre quando há caracteres UTF8 inválidos nos comandos. Por exemplo, se uma definição de tabela contiver caracteres UTF8 inválidos, a conversão das definições em dicionário de dados poderá falhar.
Para resolver esse problema, substitua os caracteres inválidos pelos correspondentes em UTF8 ou remova-os.
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
O seguinte erro ocorre quando há transações XA preparadas:
[ERROR] [MY-013527] [Server] Upgrade cannot proceed due to an existing prepared XA transactions
Esse erro ocorre se houver transações XA não confirmadas, causando falha no upgrade da versão principal no local.
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 a este:
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
O seguinte erro ocorre quando uma chave especificada é muito longa:
[ERROR] [MY-013140] [Server] Specified key was too long; max key length is [INTEGER] bytes
Esse erro ocorre se o comprimento da chave fornecida exceder o limite permitido.
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 o 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
O seguinte erro ocorre quando há metadados incompatíveis:
[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
Esta é outra mensagem de erro que você pode receber nesse caso:
[ERROR] [MY-010767] [Server] Error in fixing SE data for db_name.table_name
Esse erro ocorre se você tentar fazer upgrade de tabelas com metadados incompatíveis.
Por exemplo, se você tentar fazer upgrade de tabelas com metadados incompatíveis entre o arquivo FRM e o dicionário de dados InnoDB, o upgrade vai falhar. Nesse caso, o arquivo FRM pode estar corrompido. Para resolver esse 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 despejo e a restauração das tabelas afetadas, execute um comando semelhante a este:
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
O seguinte erro ocorre quando você tenta usar um nome de restrição de chave externa muito longo:
[ERROR] [MY-012054] [InnoDB] Foreign key name:key_name is too long
Esse erro ocorre se o nome da chave externa tiver mais de 64 caracteres.
Para resolver o problema, identifique as tabelas com nomes de restrição muito longos usando 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
O seguinte erro ocorre quando você não usa nomes de tabela precisos:
[ERROR] [MY-013521] [Server] Table name 'SCHEMA_NAME.TABLE_NAME' containing upper case characters is not allowed with lower_case_table_names = 1.
Esse erro ocorre se houver diferenças entre as letras maiúsculas e minúsculas nos nomes das tabelas.
Para resolver esse problema, se as instâncias na versão 5.7 do MySQL exigirem nomes de tabela em letras minúsculas (lower_case_table_names=1), todos os nomes de tabela 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
O erro a seguir ocorre quando uma tabela é reconhecida pelo InnoDB, mas
pertence a um mecanismo diferente:
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.
Esse erro ocorre se você excluir uma tabela e criar uma nova com o mesmo nome usando um mecanismo diferente.
Se houver tabelas no banco de dados que o mecanismo InnoDB reconhece, mas a camada SQL não, o upgrade vai falhar.
Para resolver esse problema, 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';
Mecanismo de armazenamento desconhecido: partition
O seguinte erro ocorre quando você tenta usar um mecanismo de armazenamento desconhecido:
[System] [MY-011012] [Server] Starting upgrade of data directory. [ERROR] [MY-013140] [Server] Unknown storage engine 'partition'
Esse erro ocorre quando há partições não compatíveis no mecanismo.
A versão 8.0 do MySQL permite apenas as seguintes partições no mecanismo de armazenamento:
InnoDBndbcluster
Para resolver esse problema, verifique se há tabelas com partições e cujo
mecanismo não seja InnoDB.
Para identificar essas tabelas, use a seguinte 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 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 do Google Cloud para verificar os processos atuais.
Há muitos arquivos abertos no sistema
O seguinte erro ocorre quando há muitos arquivos abertos no sistema:
[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'
Esse erro ocorre se, por exemplo, a instância tiver mais de 2 milhões de tabelas. Nesse caso, você pode receber um erro indicando que há "muitos arquivos abertos no sistema".
Para resolver esse problema, reduza o número de tabelas antes de fazer o upgrade.
Erro de falta de memória
O seguinte erro ocorre quando a memória acaba:
Out of memory
Esse erro ocorre quando as tabelas não têm memória suficiente alocada.
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 resolver esse problema, recomendamos que você tenha 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
Antes de iniciar o upgrade, é possível aumentar 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
O seguinte erro ocorre quando você tenta fazer upgrade após uma falha:
[ERROR] [MY-012526] [InnoDB] Upgrade after a crash is not supported.
Esse erro ocorre se um desligamento anterior demorou mais do que o esperado.
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 resolver esse problema e garantir que o upgrade seja bem-sucedido, planeje-o durante um período de baixo tráfego sem transações de longa duração.