Diagnosticar problemas do MySQL

MySQL   |  PostgreSQL   |  PostgreSQL para AlloyDB

Resolver um erro

O processo de job de migração pode apresentar erros durante o tempo de execução.

• Alguns erros, como uma senha incorreta no banco de dados de origem, são recuperáveis, o que significa que eles podem ser corrigidos e o job de migração é retomado automaticamente.
• Algumas são irrecuperáveis, como uma posição de binlog perdida. Isso significa que o job de migração precisa ser reiniciado do início.

Quando um erro ocorre, o status do job de migração muda para Failed, e o substatus reflete o último status antes da falha.

Para resolver um problema, acesse o job de migração com falha para ver o erro e siga as etapas descritas na mensagem de erro.

Para ver mais detalhes sobre o erro, navegue até o Cloud Monitoring usando o link no job de migração. Os registros são filtrados para o job de migração específico.

Na tabela a seguir, confira alguns exemplos de problemas e como eles podem ser resolvidos:

Para este problema...	O problema pode ser...	Tente o seguinte...
As configurações do banco de dados de destino são diferentes da configuração do Terraform usada para provisionar o banco de dados. Esse problema também é conhecido como desvio de configuração.	Ao migrar para um banco de dados de destino, o Database Migration Service modifica algumas configurações do banco de dados de destino para executar o job de migração.	Você precisa reaplicar as configurações usadas na configuração do Terraform depois de promover o job de migração. Consulte Desvio de configuração do Terraform.
Mensagem de erro: ERROR: Error executing DDL script for view {view_name} MySQL Error {1049 or 1146 or 1824}	O despejo inicial falhou porque os bancos de dados selecionados contêm objetos que referenciam dados em bancos de dados não selecionados para migração.	Inspecione a mensagem de erro subsequente para determinar o objeto referenciado ausente. Se você quiser tentar de novo, primeiro adicione o banco de dados que contém o objeto ao job de migração ou remova o banco de dados que contém a referência.
A replicação falhou com o código de erro 1049, 1146 ou 1824 durante a fase de CDC.	Isso pode acontecer se uma instrução DDL for executada em: Uma visualização ou uma restrição de chave externa em um banco de dados selecionado que faz referência a bancos de dados não selecionados para migração. Uma rotina ou um evento em um banco de dados não selecionado.	Inspecione a mensagem de erro subsequente para determinar o objeto referenciado ausente. Se você quiser tentar de novo, primeiro adicione o banco de dados que contém o objeto ao job de migração ou remova o banco de dados que contém a referência.
Mensagem de erro: Error processing table {table_name}: MySQL Error 1118 (42000): Row size too large (>8126).	As tabelas que usam colunas VARCHAR podem ter linhas que excedem o tamanho máximo permitido pelo InnoDB (o mecanismo de armazenamento padrão usado no MySQL).	Para desbloquear seu job de migração, converta as colunas para BLOB ou TEXT ou defina temporariamente a flag innodb_strict_mode como off. Consulte Erro 1118: tamanho da linha muito grande.
O job de migração falhou durante a fase de despejo completo com a seguinte mensagem de erro: ERROR 1064 (42000) at {line_number}: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near {reserved_word} at {line_number}.	Esse problema ocorre ao migrar entre versões do MySQL. As entidades na versão de origem do MySQL podem estar usando palavras que não são permitidas na versão para a qual você quer migrar. Por exemplo, no MySQL 5.7, é possível usar a palavra function em nomes de colunas. No entanto, no MySQL 8.0, function é uma palavra reservada, então o banco de dados de destino não pode analisar suas origens.	Renomeie os objetos do banco de dados de origem referenciados na mensagem de erro ou coloque-os entre crases (``) para evitar a sintaxe. Quando tudo estiver pronto, tente de novo o job de migração.
Mensagem de erro: ERROR 1109 (42S02): Unknown table in <schema name here>	O Database Migration Service não migra os esquemas de sistema mysql, performance_schema, information_schema, ndbinfo ou sys. O job de migração pode falhar se o banco de dados de origem contiver objetos que referenciam tabelas de qualquer um desses esquemas.	Verifique no banco de dados de origem objetos que referenciam tabelas contidas em qualquer um dos esquemas do sistema que não foram migrados. Consulte ERRO 1109 (42S02): tabela desconhecida em <nome do esquema aqui>.
Mensagem de erro: Unknown table 'COLUMN_STATISTICS' in information_schema (1109)	Relevante apenas para cenários de despejo manual de banco de dados com mysqldump. Os bancos de dados MySQL em versões anteriores à 8 não têm a tabela COLUMN_STATISTICS. O utilitário mysqldump nas versões 8 e mais recentes tenta exportar essa tabela por padrão. A exportação falha porque a coluna não existe.	Use a flag --column-statistics=0 ao usar mysqldump.
Mensagem de erro: Specified key was too long; max key length is 767 bytes	A instância do banco de dados de origem pode ter a variável innodb_large_prefix definida.	Defina a flag innodb_large_prefix como ON ao criar a instância de destino ou atualize a instância de destino atual com a flag.
Mensagem de erro: Table definition has changed	Houve alterações na linguagem de definição de dados (DDL, na sigla em inglês) durante o processo de despejo.	Evite mudanças em DDL durante o processo de despejo.
Mensagem de erro: Access denied; you need (at least one of) the SUPER privilege(s) for this operation	Pode haver um evento, uma visualização, uma função ou um procedimento no banco de dados de origem usando superusuario@localhost (como root@localhost). Isso não é compatível com o Cloud SQL.	Veja mais informações sobre o uso de DEFINER no Cloud SQL.
Mensagem de erro: Definer user 'x' does not exist. Please create the user on the replica.	O usuário não existe na réplica.	Veja mais informações sobre o uso de DEFINER no Cloud SQL.
Mensagem de erro: ERROR 1045 (28000) at line {line_number}: Access denied for user 'cloudsqlimport'@'localhost	Há um DEFINER no banco de dados de origem que não existe na réplica.	Veja mais informações sobre o uso de DEFINER no Cloud SQL.
Mensagem de erro: Lost connection to MySQL server during query when dumping table	O banco de dados de origem pode ter ficado inacessível ou o despejo continha pacotes muito grandes.	Tente estas sugestões.
Mensagem de erro: Got packet bigger than 'max_allowed_packet' bytes when dumping table	O pacote era maior do que o permitido pelas configurações.	Use o despejo manual com a opção max_allowed_packet.
A migração inicial dos dados foi bem-sucedida, mas nenhum dado está sendo replicado.	Pode haver sinalizações de replicação conflitantes.	Verifique estas configurações de sinalização.
A migração inicial de dados foi bem-sucedida, mas a replicação de dados deixou de funcionar após um tempo.	Há muitas causas possíveis.	Tente estas sugestões:
Mensagem de erro: mysqld check failed: data disk is full	O disco de dados da instância de destino está cheio.	Aumente o tamanho do disco da instância de destino. Aumente o tamanho do disco manualmente ou ative o aumento automático de armazenamento.
Falha ao se conectar à instância do banco de dados de origem.	Houve um problema de conectividade entre a instância de banco de dados de origem e a de destino.	Siga as etapas no artigo Depurar conectividade.
A migração de um banco de dados gerenciado (Amazon RDS/Aurora) não é iniciada.	A migração de um banco de dados de origem gerenciado sem privilégios de SUPERUSER requer um breve período de inatividade no início da migração.	Siga as etapas neste artigo.
O Binlog foi configurado incorretamente no banco de dados de origem.	As definições de Binlog estão incorretas.	Para jobs de migração contínua do MySQL, siga as definições de binlog obrigatórias.
Falha ao encontrar o arquivo dump.	O DMS não consegue encontrar o arquivo dump fornecido.	Isso pode acontecer se o job de migração não encontrar o arquivo dump no local especificado. Verifique o caminho do despejo para garantir que um arquivo adequado esteja lá ou mude o caminho. Se você mudar o caminho, use uma solicitação PATCH para garantir que o job o use. Reinicie o job de migração.
Não é possível retomar a replicação porque a posição do binlog foi perdida.	A posição do binlog foi perdida e não foi possível retomar o job de migração.	Esse erro pode ocorrer quando o processo de replicação está pausado por muito tempo, o que faz com que a posição do binlog seja perdida. Os jobs de migração não podem ser pausados por períodos que se aproximam do período de armazenamento de binlog. Reinicie o job de migração.
Ao migrar para uma instância de destino atual, você recebe a seguinte mensagem de erro: The destination instance contains existing data or user defined entities (for example databases, tables, or functions). You can only migrate to empty instances. Clear your destination instance and retry the migration job.	A instância de destino do Cloud SQL contém dados extras. Só é possível migrar para instâncias vazias. Consulte as limitações conhecidas.	Promova a instância de destino para torná-la uma instância de leitura/gravação, remova os dados extras e tente novamente o job de migração. Consulte Limpar dados extras da instância de destino atual.
Falha ao executar o job de migração devido a versões incompatíveis do banco de dados de origem e de destino.	A versão do banco de dados de origem fornecida não é compatível com a versão do banco de dados de destino.	Verifique se a versão do banco de dados de destino é igual ou uma versão principal acima da versão de origem e crie um novo job de migração.
Mensagem de erro: Unable to connect to source database server.	O Database Migration Service não consegue estabelecer uma conexão com o servidor de banco de dados de origem.	Verifique se as instâncias de banco de dados de origem e de destino podem se comunicar entre si e se você concluiu todos os pré-requisitos necessários que apareceram ao definir as configurações do job de migração.
Mensagem de erro: Timeout waiting for no write traffic on source.	A migração de um banco de dados de origem gerenciado sem privilégios SUPERUSER resulta em um breve período de inatividade no início da migração.	Siga as etapas em Migrar do MySQL RDS sem privilégios de SUPERUSUÁRIO.
Mensagem de erro: ERROR 1146 (42S02) at line {line_number}: Table '{table_name}' doesn't exist.	Pode haver uma inconsistência entre o valor da flag lower_case_table_names para o banco de dados de origem e o valor da flag para a instância de destino do Cloud SQL.	Defina o valor da flag da instância do Cloud SQL para corresponder ao valor da flag do banco de dados de origem.
Mensagem de erro: ERROR 1109 (42S02) at line {line_number}: Unknown table '{table}' in {database}.	Alguns objetos no banco de dados de origem, como visualizações, funções, procedimentos armazenados ou gatilhos, fazem referência a uma tabela que não existe mais no banco de dados.	Verifique se esses objetos existem. Se isso acontecer, remova os objetos do banco de dados de origem ou adicione a tabela a que os objetos estão fazendo referência ao banco de dados de origem.
Mensagem de erro: ERROR 1045: Access denied for user '{user_name}'@'{replica_IP}' (using password: YES)". Check if MySQL replication user and password are correct. Not attempting further retries.	Você forneceu uma senha incorreta para a instância de origem. Ou a instância de origem força uma conexão SSL, mas o job de migração não está configurado para usar certificações SSL.	Confirme se o nome de usuário, a senha e as configurações de SSL estão corretos para a instância de origem usando o cliente mysql. Se a instância de origem for do Cloud SQL, consulte Exigir SSL/TLS para verificar se o SSL/TLS é necessário para conexões TCP.
O atraso da replicação é consistentemente alto.	A carga de gravação é alta demais para a réplica processar. O atraso de replicação ocorre quando a linha de execução do Cloud SQL para MySQL em uma réplica não consegue acompanhar a linha de execução de E/S. Alguns tipos de consultas ou cargas de trabalho podem causar um atraso de replicação temporário ou permanente para um determinado esquema. Algumas causas típicas de atraso de replicação são: Consultas lentas são executadas na réplica. Encontre e corrija esses problemas. Todas as tabelas precisam ter uma chave primária exclusiva. Cada atualização em uma tabela sem essa chave causa verificações completas na réplica. Consultas como DELETE ... WHERE field < 50000000 causam atraso de replicação com base em linha, já que um grande número de atualizações é acumulado na réplica.	Algumas soluções possíveis incluem: Configure a replicação paralela se a réplica for do MySQL versão 5.7 ou mais recente. Defina a flag innodb_flush_log_at_trx_commit na réplica como 2. Para mais informações sobre essa sinalização, consulte Dicas para trabalhar com sinalizações. Edite a instância do Cloud SQL para MySQL para aumentar o tamanho da réplica. Reduza a carga no banco de dados de origem. Indexe tabelas na réplica para tabelas que não têm chaves primárias e exclusivas. Indexe as tabelas no banco de dados de origem. Isso exige a reinicialização do job de migração. Identifique e corrija consultas lentas no banco de dados de origem.
Mensagem de erro: 'Character set '#255' is not a compiled character set and is not specified in the '/usr/share/mysql/charsets/Index.xml' file' on query.	O banco de dados de origem pode usar conjuntos de caracteres ou ordenações que não são compatíveis com a réplica do Cloud SQL selecionada. Um exemplo é o AWS Aurora versão 2.x, que é compatível com o MySQL 5.7. No entanto, essa versão é compatível com a ordenação utf8mb4_0900_as_ci, que não é compatível com o Cloud SQL para MySQL 5.7.	Se a migração falhar durante a fase de despejo completo, verifique a definição da tabela de origem para saber se há conjuntos de caracteres ou agrupamentos sem suporte. Se possível, atualize para conjuntos de caracteres ou ordenações compatíveis. Se a migração falhar durante a fase de CDC, verifique o status da réplica, encontre o binlog que causa a falha na migração e examine o banco de dados e o aplicativo de origem para localizar as instruções SQL que usam os conjuntos de caracteres ou as ordenações. Se possível, atualize para conjuntos de caracteres ou ordenações compatíveis.

Erro 1108: tamanho da linha muito grande

Tabelas com colunas que armazenam strings de comprimento variável podem ter linhas que excedem o tamanho máximo padrão de linha do InnoDB.

O que você pode tentar

Ajustar o esquema da tabela de origem

Esse problema pode ocorrer novamente sempre que você executar instruções INSERT em tabelas que excedam o limite máximo de tamanho de linha. Para evitar problemas futuros, ajuste as tabelas antes de tentar migrar novamente:

• Mude sua tabela ROW_FORMAT para DYNAMIC ou COMPRESSED executando a seguinte consulta:

  ALTER TABLE TABLE_NAME ROW_FORMAT=FORMAT_NAME;
    

  Em que:
  • TABLE_NAME é o nome da tabela cujas linhas excedem o limite máximo de tamanho.
  • FORMAT_NAME é DYNAMIC ou COMPRESSED
  Por exemplo:

  ALTER TABLE mytable ROW_FORMAT=DYNAMIC;
    

• Converter dados de linha em BLOB ou TEXT. Uma maneira de fazer isso é com a função CONVERT().

Desativar o modo estrito do InnoDB

Se não for possível ajustar o esquema da tabela de origem, desative temporariamente a validação do InnoDB para concluir o job de migração. O problema pode ocorrer novamente durante futuras tentativas de gravação no banco de dados. Por isso, é melhor ajustar o esquema da tabela quando possível.

Para desativar temporariamente a validação do InnoDB com o objetivo de concluir seu job de migração, siga estas etapas:

Se...	Então...
Se você migrar para uma nova instância de destino	Recrie o job de migração. Ao final da etapa Definir um destino, clique em Mostrar configurações opcionais. Na seção Flags, selecione a flag innodb_strict_mode e defina como Off. Depois que a migração for concluída, defina a flag innodb_strict_mode como On. Consulte Configurar flags de banco de dados na documentação do Cloud SQL para MySQL.
Se você migrar para uma instância de destino existente	No Cloud SQL, navegue até a instância de destino e defina a sinalização innodb_strict_mode como Off. Consulte Configurar flags de banco de dados na documentação do Cloud SQL para MySQL. Recrie o job de migração. Depois que a migração for concluída, defina a flag innodb_strict_mode como On. Consulte Configurar flags de banco de dados na documentação do Cloud SQL para MySQL.

---

Limpar dados extras da instância de destino atual

Ao migrar para uma instância de destino atual, você recebe a seguinte mensagem de erro: The destination instance contains existing data or user defined entities (for example databases, tables, or functions). You can only migrate to empty instances. Clear your destination instance and retry the migration job.

Esse problema pode ocorrer se a instância de destino tiver dados extras. Só é possível migrar para instâncias vazias. Consulte as limitações conhecidas.

O que você pode tentar

Limpe os dados extras da instância de destino e inicie o job de migração novamente seguindo estas etapas:

1. Interrompa o job de migração.
2. Neste ponto, a instância de destino do Cloud SQL está no modo read-only. Promova a instância de destino para ter acesso de gravação.
3. Conecte-se à instância de destino do Cloud SQL.
4. Remova os dados extras dos bancos de dados da instância de destino. O destino só pode conter dados de configuração do sistema. Os bancos de dados de destino não podem conter dados do usuário (como tabelas). Há diferentes instruções SQL que podem ser executadas nos bancos de dados para encontrar dados não relacionados ao sistema, por exemplo:

   SELECT schema_name FROM information_schema.SCHEMATA
   WHERE schema_name NOT IN ('information_schema', 'sys', 'performance_schema', 'mysql');
     

5. Inicie o job de migração.

---

Desvio de configuração do Terraform

Ao migrar para um banco de dados de destino, o Database Migration Service modifica algumas configurações do banco de dados de destino para executar o job de migração. Para bancos de dados provisionados com o Terraform, essa interação pode causar uma deriva de configuração em que a configuração real do banco de dados de destino é diferente da configuração definida nos arquivos do Terraform.

O que você pode tentar

Não tente reaplicar a configuração do Terraform enquanto o job de migração estiver em execução. É possível ajustar com segurança a configuração necessária depois que o banco de dados de destino for promovido. O Database Migration Service faz as seguintes modificações na instância de destino do Cloud SQL:

• A configuração de backup é definida como valores padrão.
• A recuperação pontual é redefinida para os valores padrão.

É possível que ocorra deriva de configuração se a configuração do Terraform contiver definições para qualquer um desses recursos. Se você precisar corrigir a configuração do banco de dados de destino, aguarde a conclusão do job de migração e a promoção do banco de dados de destino. Em seguida, siga estas etapas: 1. Execute o comando "terraform plan" para conferir a prévia das suas modificações. 1. Execute o comando "terraform apply" para reajustar as configurações do banco de dados de destino.

---

ERRO 1109 (42S02): tabela desconhecida em <nome do esquema aqui>

Os jobs de migração falham com a seguinte mensagem: ERROR 1109 (42S02): Unknown table in <schema name here> , por exemplo: ERROR 1109 (42S02) at line X: Unknown table 'GLOBAL_STATUS' in information_schema.

O problema pode ser

O Database Migration Service não migra os esquemas de sistema mysql, performance_schema, information_schema, ndbinfo ou sys. Consulte Limitações conhecidas. O job de migração pode falhar se o banco de dados de origem tiver objetos que referenciam tabelas de qualquer um desses esquemas.

O que você pode tentar

Verifique no banco de dados de origem objetos que referenciam tabelas dos esquemas do sistema. No banco de dados de origem, execute estas consultas:

# Query to check routines or functions definitions.
SELECT ROUTINE_SCHEMA, ROUTINE_NAME FROM information_schema.routines
WHERE ROUTINE_SCHEMA NOT IN ('information_schema', 'mysql', 'ndbinfo', 'performance_schema', 'sys')
AND ROUTINE_DEFINITION like '%OBJECT_NAME_REPORTED_IN_THE_ERROR_MESSAGE%'

# Query to check view definitions.
SELECT TABLE_SCHEMA, TABLE_NAME FROM information_schema.views
WHERE TABLE_SCHEMA NOT IN ('information_schema', 'mysql', 'ndbinfo', 'performance_schema', 'sys')
AND view_definition like '%OBJECT_NAME_REPORTED_IN_THE_ERROR_MESSAGE%'

# Query to check trigger definitions.
SELECT TRIGGER_SCHEMA, TRIGGER_NAME FROM information_schema.TRIGGERS
WHERE TRIGGER_SCHEMA NOT IN ('information_schema', 'mysql', 'ndbinfo', 'performance_schema', 'sys')
AND event_object_table = 'OBJECT_NAME_REPORTED_IN_THE_ERROR_MESSAGE'

# Query to check constraint definitions.
SELECT TABLE_SCHEMA, TABLE_NAME
FROM information_schema.KEY_COLUMN_USAGE
WHERE TABLE_SCHEMA NOT IN ('information_schema', 'mysql', 'ndbinfo', 'performance_schema', 'sys')
AND REFERENCED_TABLE_NAME = 'OBJECT_NAME_REPORTED_IN_THE_ERROR_MESSAGE'

Se essas consultas retornarem resultados, exclua os objetos de código relevantes e faça a migração novamente.

---

Tabela desconhecida "COLUMN_STATISTICS" em information_schema

Ao executar a versão 8 ou mais recente do utilitário mysqldump para exportar uma versão do banco de dados MySQL anterior à 8, você encontra este erro: Unknown table 'COLUMN_STATISTICS' in information_schema (1109).

O problema pode ser

Os bancos de dados MySQL em versões anteriores à 8 não têm a tabela COLUMN_STATISTICS. O utilitário mysqldump nas versões 8 e mais recentes tenta exportar essa tabela por padrão. A exportação falha porque a coluna não existe.

O que você pode tentar

Adicione a flag --column-statistics=0 ao comando mysqldump para remover a tabela COLUMN_STATISTICS da exportação. Para mais informações, consulte Como exportar um banco de dados MySQL usando mysqldump.

---

A chave especificada era muito longa. O comprimento máximo da chave é 767 bytes

Você verá o erro Specified key was too long; max key length is 767 bytes.

O problema pode ser

O banco de dados de origem pode ter a variável innodb_large_prefix definida. Isso permite prefixos de chave de índice com mais de 767 bytes. O valor padrão é OFF para MySQL 5.6.

O que você pode tentar

Defina a flag innodb_large_prefix como ON ao criar o banco de dados de destino ou atualize o banco de dados de destino atual com a flag.

---

A definição da tabela foi alterada

Você verá o erro Table definition has changed.

Possível problema

Houve alterações de DDL durante o processo de despejo.

O que você pode tentar

Não modifique tabelas nem faça outras alterações de DDL durante o processo de despejo.Use um script para verificar se as operações de DDL foram interrompidas.

---

Acesso negado. Você precisa de (pelo menos um dos) privilégios de SUPER para esta operação

Você verá o erro Access denied; you need (at least one of) the SUPER privilege(s) for this operation.

O problema pode ser

Pode haver um evento, uma visualização, uma função ou um procedimento no banco de dados de origem usando superusuario@localhost (como root@localhost). Isso não é compatível com o Cloud SQL.

O que você pode tentar

Consulte este documento sobre como migrar um banco de dados com cláusulas DEFINER.

---

Mensagem de erro: Definer user 'x' does not exist. Please create the user on the replica.

Você verá o erro Definer user 'x' does not exist. Please create the user on the replica.

O problema pode ser

A causa raiz é que um usuário no banco de dados de origem com a cláusula DEFINER não existe no banco de dados de réplica.

O que você pode tentar

Consulte este documento sobre como migrar um banco de dados com cláusulas DEFINER. Talvez seja necessário criar o usuário no banco de dados de réplica.

---

Mensagem de erro: ERROR 1045 (28000) at line {line_number}: Access denied for user 'cloudsqlimport'@'localhost

Você verá o erro ERROR 1045 (28000) at line {line_number}: Access denied for user 'cloudsqlimport'@'localhost.

O problema pode ser

A causa raiz é que um usuário no banco de dados de origem com a cláusula DEFINER não existe no banco de dados de réplica, e esse usuário tem referência cruzada nas definições de objetos no banco de dados de origem.

O que você pode tentar

Consulte este documento sobre como migrar um banco de dados com cláusulas DEFINER. Talvez seja necessário criar um ou mais usuários no banco de dados de réplica.

---

Perda de conexão com o servidor MySQL durante a consulta ao despejar tabela

Você verá o erro Lost connection to MySQL server during query when dumping table.

O problema pode ser

• A instância do banco de dados de origem pode ter ficado inacessível para a instância de destino.
• O banco de dados de origem pode ter tabelas com blobs grandes ou strings longas que exigem a configuração de max_allowed_packet como um número maior no banco de dados de origem.

O que você pode tentar

• Verifique se a instância do banco de dados de origem está ativa e acessível.
• Configure a flag max-allowed-packet no job de migração e reinicie o job. Ou, gere um despejo manual com a opção max_allowed_packet para despejar os dados e migrar com o arquivo dump.
• Aumentar max_allowed_packet provavelmente exigirá o ajuste das configurações net_read_timeout e net_write_timeout no banco de dados de origem. Em geral, elas devem ser aumentadas até que o erro de conexão pare.

---

Pacote maior com bytes "max_allowed_packet" ao despejar tabela

Você verá o erro Got packet bigger than 'max_allowed_packet' bytes when dumping table.

Possível problema

O pacote era maior do que o permitido pelas configurações.

O que você pode tentar

Crie um job de migração usando um despejo manual com a opção max_allowed_packet para despejar os dados e migrar com o arquivo dump.

---

Nenhum dado está sendo replicado

A migração inicial dos dados foi bem-sucedida, mas nenhum dado está sendo replicado.

O problema pode ser

Uma possível causa raiz pode ser que o banco de dados de origem tenha flags de replicação que fazem com que algumas ou todas as mudanças não sejam replicadas.

O que você pode tentar

Verifique se as flags de replicação, como binlog-do-db, binlog-ignore-db, replicate-do-db ou replicate-ignore-db, não estão definidas de maneira conflitante.
Execute o comando show master status no banco de dados de origem para conferir as configurações atuais.

---

A migração inicial de dados foi concluída, mas a replicação de dados deixou de funcionar após um tempo

A migração inicial de dados foi bem-sucedida, mas a replicação de dados deixou de funcionar após um tempo.

O problema pode ser

Pode haver muitas causas raiz para esse problema.

O que você pode tentar

• Verifique as métricas de replicação da instância de destino no Cloud Monitoring.
• Os erros da linha de execução de E/S do MySQL ou do SQL podem ser encontrados no Cloud Logging nos arquivos de registro mysql.err.
• O erro também pode ser encontrado ao se conectar à instância de destino. Execute o comando SHOW REPLICA STATUS e verifique estes campos na saída:
  • Replica_IO_Running
  • Replica_SQL_Running
  • Last_IO_Error
  • Last_SQL_Error

  Observação:SHOW REPLICA STATUS é um alias introduzido no MySQL 8.0.22. Para versões anteriores (MySQL 5.7, MySQL 8.0), use o alias antigo do comando de status. Para mais informações, consulte Instrução de status na documentação do MySQL.

  Se você recebeu o erro fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file' in Last_IO_Error, isso pode ser devido a uma configuração de retenção de binlog insuficiente na instância de origem.

  Se você recebeu o erro error connecting to master 'USER_NAME@SOURCE_HOST:SOURCE_PORT' - retry-time: RETRY_TIME retries: RETRIES, isso pode ser devido à falha da instância de destino ao se reconectar à origem por causa de um problema de conectividade ou autenticação.

---

Falha na verificação do mysqld: o disco de dados está cheio

Você verá o erro mysqld check failed: data disk is full.

O problema pode ser

O disco de dados da instância de destino provavelmente está cheio.

O que você pode tentar

Aumente o tamanho do disco da instância de destino.

---

Falha ao se conectar ao banco de dados de origem

Falha ao se conectar ao banco de dados de origem.

O problema pode ser

Houve um problema de conectividade entre a instância de banco de dados de origem e a de destino.

O que você pode tentar

Siga as etapas no artigo sobre depuração da conectividade.

---

A migração de um banco de dados gerenciado (Amazon RDS/Aurora) não é iniciada

O job de migração não é iniciado.

O problema pode ser

A migração de um banco de dados de origem gerenciado sem privilégios de SUPERUSER requer um breve período de inatividade no início da migração.

O que você pode tentar

• Para o Amazon RDS, siga as etapas neste artigo.
• Para o Amazon Aurora, siga as etapas neste artigo.

---

O binlog foi configurado incorretamente no banco de dados de origem.

Você vê um erro indicando um problema com os registros binários.

O problema pode ser

Isso pode acontecer em jobs de migração contínua do MySQL se a configuração do binlog estiver incorreta no banco de dados de origem.

O que você pode tentar

Siga as definições aqui.

---

Falha ao ler o arquivo dump fornecido

Você vai ver um erro indicando um problema com o arquivo dump.

O problema pode ser

O DMS não consegue encontrar o arquivo dump fornecido.

O que você pode tentar

1. Verifique o caminho do despejo para garantir que um arquivo adequado esteja lá ou mude o caminho.
2. Se você mudar o caminho, use uma solicitação PATCH para garantir que o job o use.
3. Reinicie o job de migração.

---

Não é possível retomar a replicação porque a posição do binlog foi perdida

A posição do binlog foi perdida.

O problema pode ser

Esse erro pode ocorrer quando o processo de replicação está pausado por muito tempo, o que faz com que a posição do binlog seja perdida. Os jobs de migração não podem ser pausados por períodos que se aproximam do período de armazenamento de binlog.

O que você pode tentar

Reinicie o job de migração.

---

Falha ao executar o job de migração devido a versões incompatíveis do banco de dados de origem e de destino

As versões do banco de dados de origem e de destino não são uma combinação compatível.

O problema pode ser

A versão do banco de dados de origem fornecida não é compatível com a versão do banco de dados de destino.

O que você pode tentar

Verifique se a versão do banco de dados de destino é igual ou uma versão principal acima da versão de origem e crie um novo job de migração.

---

Não é possível se conectar ao servidor do banco de dados de origem

Você verá o erro Unable to connect to source database server.

O problema pode ser

O Database Migration Service não consegue estabelecer uma conexão com o servidor de banco de dados de origem.

O que você pode tentar

Verifique se as instâncias de banco de dados de origem e de destino podem se comunicar entre si. Em seguida, verifique se você concluiu todos os pré-requisitos necessários que apareceram quando definiu as configurações do job de migração.

---

O uso de disco da instância de destino do Cloud SQL cai para zero

O uso de disco cai repentinamente para zero durante a migração.

O problema pode ser

Pode haver uma falha ao importar os dados completos do despejo. Quando isso acontece, o processo de migração tenta realizar outro carregamento dos dados. Esse processo primeiro apaga os dados existentes na instância de destino (por isso, o uso do disco vai a zero) e tenta recarregar os dados.

O que você pode tentar

Acesse o Análise de registros e selecione a instância de destino na lista de recursos. Procure uma mensagem de registro semelhante: DUMP_STAGE(RETRY): Attempt .../...: import failed: error..."; Clearing database and trying again." Encontre a mensagem depois do texto import failed: e tente resolver o problema.