Data Transmission Service:Solução de problemas de latência em tarefas de migração ou sincronização incremental

Problema

Uma tarefa de migração ou sincronização incremental do DTS apresenta latência superior a 1.000 milissegundos.

Possíveis causas

• Causa 1: As especificações da instância são insuficientes para a carga de trabalho. Cada instância do DTS para migração ou sincronização incremental de dados tem um limite específico de RPS (registros por segundo). Quando a carga de escrita no banco de dados de origem é muito alta — por exemplo, devido a transações grandes —, a tarefa pode sofrer throttling, gerando latência.

  Verifique o fluxo de dados da tarefa ou use o recurso Quick Diagnostics para determinar se a instância atingiu os limites de especificação. Para mais informações, consulte Monitor task performance, Specifications of data synchronization instances e Specifications of data migration instances.

• Causa 2: As especificações da instância de destino são insuficientes. O desempenho de escrita da instância do banco de dados de destino atingiu um gargalo.

  Por exemplo, se o destino for uma instância ApsaraDB RDS for MySQL, verifique as métricas de utilização de recursos — como CPU, memória e I/O — na página Monitoring and Alerts do console do ApsaraDB RDS. Compare essas métricas com as especificações da instância para avaliar se ela atingiu seus limites de desempenho. Para mais informações, consulte View monitoring information e ApsaraDB RDS for MySQL instance types.

• Causa 3: Atualizações de hotspot estão afetando o desempenho. Atualizações em uma tabela sem chave primária ou atualizações frequentes em uma única tabela ou linha no banco de dados de origem podem gerar hotspot updates.

  Por exemplo, se a origem for uma instância ApsaraDB RDS for MySQL, use o recurso SQL Explorer and Audit para examinar as transações e identificar a ocorrência de hotspot updates, como transações concentradas em tabelas específicas. Para mais informações, consulte SQL Explorer and Audit.

• Causa 4: O desempenho de leitura do banco de dados de origem atingiu um gargalo ou a largura de banda de rede está saturada.

  Por exemplo, se a origem for uma instância ApsaraDB RDS for MySQL, verifique métricas como IOPS na página Monitoring and Alerts do console do ApsaraDB RDS. Compare essas métricas com as especificações da instância para avaliar se ela atingiu seus limites de desempenho. Para mais informações, consulte View monitoring information e ApsaraDB RDS for MySQL instance types.

• Causa 5: Quando o DTS não consegue se conectar ao banco de dados ou falha ao gravar dados no banco de dados de destino por outros erros, ele executa múltiplas tentativas, gerando latência na sincronização. Verifique se o status da tarefa é Retrying no console. Clique em Troubleshoot para ver a causa e resolver o problema.

  Por exemplo, se o banco de dados de destino for uma instância AnalyticDB for MySQL e você executar uma operação DDL para alterar o tipo de uma coluna no banco de dados de origem, a tarefa de sincronização do DTS apresentará latência e entrará no estado Retrying. Isso ocorre porque a instância AnalyticDB for MySQL de destino não suporta alterações de tipo de coluna. O DTS tenta repetidamente aplicar a operação DDL, mas todas as tentativas falham, resultando na latência.

• Causa 6: O banco de dados de destino possui um trigger, o que pode causar latência significativa.

  Para um banco de dados MySQL, use o seguinte comando para verificar a existência de triggers:

  select * from information_schema.triggers where trigger_schema='<database_name>';

• Causa 7: Se as tabelas sincronizadas para o banco de dados de destino tiverem schemas complexos — como a presença simultânea de chaves primárias e chaves únicas — e outros serviços além do DTS também gravarem no banco de dados de destino, poderão ocorrer bloqueios de tabela e consultas SQL lentas no destino.

• Causa 8: Um grande número de operações DDL está sendo executado no banco de dados de origem.

  Por exemplo, se a origem for uma instância ApsaraDB RDS for MySQL, use o SQL Explorer and Audit para verificar a execução de instruções DDL e determinar se há um volume elevado de operações DDL. Para mais informações, consulte SQL Explorer and Audit.

• Causa 9: A transmissão de dados a longas distâncias está causando latência de rede.

  Verifique as regiões dos bancos de dados de origem e destino na página de lista de tarefas.

• Causa 10: Os schemas das tabelas nos bancos de dados de origem e destino não são compatíveis entre si.

• Causa 11: O valor de latência exibido no console pode estar desatualizado.

Soluções

• Solução 1: Faça upgrade das especificações da instância da tarefa de migração ou sincronização incremental de dados para melhorar o desempenho. Para mais informações, consulte Upgrade a DTS instance.

• Solução 2: Faça upgrade das especificações da instância do banco de dados de destino para melhorar seu desempenho de escrita.

  Para uma instância ApsaraDB RDS for MySQL, consulte Change instance specifications para realizar o upgrade da configuração.

• Solução 3: Se houver hotspot updates em andamento, aguarde a conclusão. Como alternativa, considere redesenhar a lógica da aplicação para evitar esse tipo de atualização.

• Solução 4: Melhore o desempenho da instância do banco de dados de origem ou faça upgrade de sua largura de banda de rede.

  Para uma instância ApsaraDB RDS for MySQL, consulte Change instance specifications para realizar o upgrade da configuração.

• Solução 5: Verifique a mensagem de erro específica no console e resolva o problema conforme indicado.

  Se o DTS falhar ao aplicar operações DDL em um destino AnalyticDB for MySQL, remova primeiro a tabela com a operação DDL com falha dos objetos de sincronização. Após a latência cair para zero, exclua a tabela correspondente no banco de dados de destino. Por fim, adicione a tabela novamente aos objetos de sincronização. Para mais informações, consulte Data synchronization FAQ e Modify synchronization objects.

• Solução 6: Exclua ou desabilite os triggers no banco de dados de destino.

  Para um banco de dados MySQL, use o comando DROP TRIGGER [ IF EXISTS ] [database_name] <trigger_name>; para excluir um trigger.

  Nota

  Se o banco de dados de origem tiver um trigger, consulte Configure a synchronization task when the source database has a trigger para configure a tarefa do DTS.

• Solução 7: Verifique o status de bloqueio, as consultas SQL lentas e o schema das tabelas no banco de dados de destino. Ajuste as operações de escrita ou o schema para resolver bloqueios e consultas lentas.

  O exemplo a seguir, para um banco de dados MySQL, demonstra como consultar o status de bloqueio, as consultas SQL lentas e o schema das tabelas, além de como resolver cada problema.

  • Status de bloqueio e consultas SQL lentas: execute SHOW PROCESSLIST; para identificar processos bloqueados ou consultas lentas. Em seguida, execute KILL [CONNECTION | QUERY] thread_id para encerrar o processo.

  • Schema da tabela: execute show create table <database_name>.<table_name>; para visualize o schema da tabela. Se existir uma chave única, avalie se ela é necessária para o negócio. Caso não seja, execute alter table <database_name>.<table_name> drop index <unique_key_name>; no banco de dados de destino para removê-la.

• Solução 8: Se a tarefa do DTS estiver sendo execute com sucesso, evite executar operações DDL em massa no banco de dados de origem. Quando as operações DDL forem necessárias, execute-as nos horários de menor uso.

  Nota

  Ao configure a tarefa, não selecione operações DDL que não precisam ser sincronizadas.

• Solução 9: Para reduzir a latência de rede inevitável em transmissões de longa distância, use o Express Connect para conectar as instâncias dos bancos de dados de origem e destino.

• Solução 10: Ajuste os schemas das tabelas para garantir a consistência entre os bancos de dados de origem e destino.

• Solução 11: Aguarde alguns minutos e atualize o console.

Referências

Para soluções relacionadas a tarefas de dados completos lentas, consulte Troubleshoot slow or stuck full data migration.