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 a perda da posição do binlog, o que significa que o job de migração precisa ser reinicializado 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 conferir o erro e siga as etapas descritas na mensagem de erro.

Para conferir mais detalhes sobre o erro, acesse 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 resolvê-los:

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 deslocamento de configuração.	Quando você migra para um banco de dados de destino existente, o Database Migration Service modifica determinadas configurações do banco de dados de destino para executar o job de migração.	É necessário aplicar novamente as configurações usadas na configuração do Terraform após promover o job de migração. Consulte Desvio de configuração do Terraform.
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 o job de migração, converta as colunas em BLOB ou TEXT ou defina temporariamente a flag innodb_strict_mode como off. Consulte Erro 1118: o 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 do MySQL de origem podem estar usando palavras que não são permitidas na versão do MySQL 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, portanto, 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 em colchetes (``) para escapar da sintaxe. Quando terminar, tente novamente 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 tiver objetos que referenciam tabelas de qualquer um desses esquemas.	Verifique se há objetos no banco de dados de origem que fazem referência a tabelas contidas em qualquer um dos esquemas do sistema que não foram migrados. Consulte ERROR 1109 (42S02): Tabela desconhecida em <schema name here>.
Mensagem de erro: Unknown table 'COLUMN_STATISTICS' in information_schema (1109)	Relevante para cenários de despejo manual de banco de dados apenas 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.	Confira 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.	Confira 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.	Confira 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 concluída, 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 origem e a de destino do banco de dados.	Siga as etapas no artigo Como depurar a 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 do Binlog estão incorretas.	Para jobs contínuos de migração do MySQL, siga as definições de binário necessá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 o job de migração não pôde ser retomado.	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 existente, 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 é incompatí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 destino 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 quando definiu 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 Como migrar do MySQL RDS sem privilégios de SUPERUSER.
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 do banco de dados de origem e o valor da flag da 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 houver, exclua os objetos do banco de dados de origem ou adicione a tabela que os objetos estão referenciando 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 o Cloud SQL, consulte Exigência de 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. Estas são algumas das causas comuns do atraso de replicação: Consultas lentas são realizadas 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 faz verificações completas de tabela 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. Consulte Dicas para trabalhar com flags para mais informações sobre essa flag. 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. Índice de tabelas na réplica para as tabelas que não têm chaves primárias exclusivas. Tabelas de índice no banco de dados de origem. Isso requer 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 é a AWS Aurora versão 2.x, que é compatível com o MySQL 5.7. No entanto, essa versão oferece suporte à 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 se a definição da tabela de origem usa conjuntos de caracteres ou ordenações 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 binário que causa a falha 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: o tamanho da linha é muito grande

As tabelas com colunas que armazenam strings de comprimento variável podem ter linhas que excedem o tamanho máximo de linha padrão 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 nas tabelas que excedem o limite máximo de tamanho da linha. Para evitar problemas futuros, é melhor ajustar as tabelas antes de tentar a migração novamente:

• Mude a 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 de linha
  • FORMAT_NAME é DYNAMIC ou COMPRESSED
  Por exemplo:

  ALTER TABLE mytable ROW_FORMAT=DYNAMIC;
    

• Converta os dados da linha em BLOB ou TEXT. Uma maneira de realizar essa operação é 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 em tentativas futuras de gravação no banco de dados. Portanto, é melhor ajustar o esquema da tabela quando possível.

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

Se…	Depois...
Se você migrar para uma nova instância de destino	Recrie o job de migração. No final da etapa Definir um destino, clique em Mostrar configurações opcionais. Na seção Flags, selecione a flag innodb_strict_mode e defina-a 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	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. Crie novamente 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 existente, 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 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. Nesse 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. Conectar-se à instância de destino do Cloud SQL.
4. Remova dados extras dos bancos de dados de 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 que não são do sistema, por exemplo:

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

5. Iniciar o job de migração.

---

Desvio de configuração do Terraform

Quando você migra para um banco de dados de destino existente, o Database Migration Service modifica determinadas 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 do conjunto de configuração nos arquivos do Terraform.

O que você pode tentar

Não tente reaplicar a configuração do Terraform quando 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 executa as seguintes modificações na instância de destino do Cloud SQL:

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

A deriva de configuração pode ocorrer se a configuração do Terraform contiver configurações para qualquer um desses recursos. Se você precisar corrigir a configuração do banco de dados de destino, aguarde até que o job de migração seja concluído e o banco de dados de destino seja promovido. Em seguida, siga estas etapas: 1. Execute o comando "terraform plan" para conferir a visualização das modificações. 1. Execute o comando "terraform apply" para ajustar novamente as configurações do banco de dados de destino.

---

ERRO 1109 (42S02): tabela desconhecida em <schema name here>

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 fazem referência a tabelas de qualquer um desses esquemas.

O que você pode tentar

Verifique se há objetos no banco de dados de origem que fazem referência a tabelas dos esquemas do sistema. No banco de dados de origem, execute as seguintes 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, considere excluir os objetos de código relevantes e realizar a migração novamente.

---

Tabela desconhecida "COLUMN_STATISTICS" em information_schema

Ao executar o utilitário mysqldump versão 8 ou mais recente 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 que 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 na 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 de migração. Ou gere um dump manual com a opção max_allowed_packet para despejar os dados e migrar com o arquivo dump.
• Aumentar max_allowed_packet provavelmente vai exigir ajustes nas configurações net_read_timeout e net_write_timeout no banco de dados de origem. Geralmente, é necessário aumentar até que o erro de conexão seja corrigido.

---

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 dump 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 a sinalização do seu banco de dados de origem, o que faz com que algumas ou todas as alterações do banco de dados 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 parou 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 na interface do 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: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 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 à 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 na reconexão da instância de destino com a origem devido a 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 origem e a de destino do banco de dados.

O que você pode tentar

Siga as etapas no artigo de solução de problemas de 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 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ê encontra 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ê recebe 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 é 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 é incompatí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 destino 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 do disco da instância de destino do Cloud SQL cai para zero

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

O problema pode ser

Pode ocorrer uma falha ao importar os dados completos do dump. Quando isso acontece, o processo de migração tenta realizar outro carregamento dos dados. Esse processo primeiro exclui os dados existentes na instância de destino (é por isso que o uso do disco diminui para zero) e depois tenta recarregar os dados.

O que você pode tentar

Acesse o Explorador 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 após o texto import failed: e tente resolver o problema.