DataWorks:Perguntas frequentes sobre sincronização em tempo real

Fontes de dados suportadas

Para obter uma lista das fontes de dados suportadas para sincronização em tempo real, consulte Fontes de dados suportadas para sincronização em tempo real.

Alta latência na sincronização em tempo real

Se você consultar uma tabela de destino e notar a ausência de novos dados, a tarefa de sincronização em tempo real pode estar com alta latência. Acesse a página de tarefas de sincronização em tempo real no Operation Center para verificar se a latency da tarefa está muito elevada. Para mais informações, consulte Soluções para alta latência em tarefas de sincronização em tempo real.

A alta latência pode ter as seguintes causas:

Uso da rede pública

Utilizar a internet pública para tarefas de sincronização em tempo real envolve os seguintes riscos:

• A rede pode ser instável e a perda frequente de pacotes pode afetar o desempenho da sincronização.

• Baixa segurança.

Formato de coluna

Quando o Data Integration sincroniza dados do MySQL, Oracle, LogHub e PolarDB para o DataHub ou Apache Kafka em tempo real, ele adiciona cinco colunas extras ao destino para oferecer suporte ao gerenciamento de metadados, à ordenação de registros e à deduplicação. Para mais informações, consulte Formato de coluna na sincronização em tempo real.

Tratamento de operações TRUNCATE

A sincronização em tempo real suporta operações TRUNCATE, que entram em vigor durante mesclagens incrementais e completas. Se você optar por ignorar o TRUNCATE, dados supérfluos poderão aparecer na tabela de destino.

Melhoria de desempenho

Se a velocidade de gravação estiver lenta, aumente a simultaneidade de gravação e ajuste os parâmetros da JVM. As configurações dos parâmetros da JVM dependem da frequência de alterações dos dados, e não do número de bancos de dados sincronizados. Se o seu grupo de recursos permitir, alocar mais memória pode reduzir a frequência de GC completo e melhorar o desempenho da sincronização em tempo real. Defina Concurrency como 3. No painel Basic configuration da tarefa, defina JVM Parameters como -Xms8192m -Xmx8192m.

Execução de tarefas no console

Não, não é possível executar tarefas de sincronização em tempo real diretamente do console do DataWorks. Após configurar uma tarefa de sincronização em tempo real, envie e implante o nó de sincronização em tempo real e, em seguida, execute-o no ambiente de produção. Para mais informações, consulte Operações e ajustes para sincronização em tempo real de tabela única.

Lentidão com origens MySQL

Um dos motivos é o aumento no número de binlogs a sincronizar. Como os binlogs são gerados no nível da instância, mesmo que uma tarefa esteja configurada para sincronizar apenas a Tabela A, alterações em outras tabelas da instância, como Tabela B e Tabela C, também geram binlogs. Esses binlogs adicionais tornam o processo de sincronização mais lento.

Uso de memória para banco de dados único versus múltiplos

Ao selecionar dois ou mais bancos de dados, a tarefa entra no modo de sincronização em tempo real de instância completa. Esse modo consome mais recursos do que duas tarefas separadas em tempo real, cada uma sincronizando um único banco de dados.

Políticas DDL suportadas

Métodos de tratamento:

Tipos de DDL:

Considerações sobre DDL e DML de origem

• Após adicionar uma nova coluna na origem e processá-la no destino, aplicam-se as seguintes limitações:

  • Quando uma coluna com DEFAULT VALUE é adicionada, a nova coluna na tabela de destino permanece NULL. Posteriormente, quando novos dados forem adicionados a essa coluna na origem, a tarefa os sincronizará para o destino.

  • Quando uma coluna VIRTUAL é adicionada, a nova coluna na tabela de destino permanece NULL. Posteriormente, quando novos dados forem adicionados a essa coluna na origem, a tarefa os sincronizará para o destino.

• Para sincronização em tempo real a partir de origens MySQL e PolarDB for MySQL, anexe novas colunas ao final da tabela em vez de inseri-las no meio. Se for inevitável inserir uma coluna no meio na origem, aplicam-se as seguintes restrições:

  • Em uma solução completa e incremental, não adicione uma coluna no meio durante a fase de sincronização completa. Isso pode causar anomalias nos dados durante a fase de sincronização em tempo real.

  • Durante a fase de sincronização em tempo real, o tempo de redefinição do deslocamento de sincronização deve ser posterior ao evento DDL que adiciona a coluna no meio. Caso contrário, ocorrerão anomalias nos dados durante a sincronização subsequente.

• Se ocorrerem anomalias nos dados, restaure-os reinicializando a tabela afetada. É necessário reinicializar apenas a tabela específica onde a coluna foi adicionada, e não todas as tabelas da tarefa.

Alta latência após failover do PostgreSQL

Esse é um comportamento do próprio banco de dados PostgreSQL. Se a latência for inaceitável, pare a tarefa e reinicie-a para realizar uma sincronização de dados completa e incremental.

Execução de uma sincronização completa

No Data Integration, localize sua tarefa na lista de tarefas de sincronização. Em seguida, na coluna Actions, clique em More > Rerun.

A tarefa para de ler do MySQL

1. Execute o seguinte comando no banco de dados para identificar o arquivo binlog atual.

   show master status 

2. Compare esse valor com o arquivo binlog lido pela tarefa. Pesquise nos logs por journalName=mysql-bin.000001,position=50 para confirmar se os dados estão sendo gravados no banco de dados.

3. Se os dados estiverem sendo gravados, mas o binlog não estiver avançando, entre em contato com seu DBA para obter assistência.

Falhas recorrentes de tarefas para Oracle, PolarDB e MySQL

• Sintoma: A tarefa de sincronização em tempo real falha repetidamente.

  Quando a origem de uma sincronização em tempo real é uma fonte de dados Oracle, PolarDB ou MySQL, o processamento de mensagens DDL da origem não é suportado por padrão. Quando ocorrem alterações DDL diferentes da criação de uma nova tabela, a tarefa em tempo real falha e encerra. Com a retomada a partir de ponto de interrupção, a sincronização ainda pode falhar mesmo que nenhuma mensagem DDL seja gerada na origem.

  Nota

  Para evitar perda ou corrupção de dados, não use o comando Rename para trocar os nomes de duas colunas. Por exemplo, não troque os nomes da Coluna A e da Coluna B.

• Causa: A sincronização em tempo real suporta retomada a partir de ponto de interrupção. Para garantir que nenhum dado seja perdido, a tarefa pode retroceder a um deslocamento anterior ao reiniciar. Isso pode fazer com que a tarefa leia mensagens DDL anteriores novamente, desencadeando outra falha.

• Solução:

  1. Quando ocorrer uma alteração DDL na origem, realize manualmente a alteração DDL correspondente no banco de dados de destino.

  2. Inicie a tarefa de sincronização em tempo real e altere a política DDL de Error para Ignore.

     Nota

     Como a retomada a partir de ponto de interrupção ainda pode assinar este evento DDL, altere temporariamente a política para Ignore para evitar que a tarefa falhe novamente.

  3. Pare a tarefa de sincronização em tempo real, altere a política DDL de Ignore de volta para Error e, em seguida, reinicie a tarefa.

Erro do Kafka: Startup mode for the consumer set to timestampOffset, but no begin timestamp was specified.

Redefina o deslocamento inicial. Na caixa de diálogo Start da tarefa, localize a opção Reset offset e marque a caixa de seleção Reset offset para ativar esse recurso.

A função Reset offset no Data Integration permite alterar o ponto inicial da sincronização de dados. Use-a para reiniciar uma tarefa a partir de um horário ou posição de dados específica, por exemplo, para recuperar-se de um erro ou ressincronizar dados específicos. Isso garante a consistência e integridade dos dados.

Erro do MySQL: Cannot replicate because the master purged required binary logs.

Se uma tarefa de sincronização em tempo real do MySQL falhar com a mensagem Cannot replicate because the master purged required binary logs. Replicate the missing transactions from elsewhere, or provision a new slave from backup., pode ser porque o MySQL não possui o registro binlog no deslocamento consumido. Verifique o período de retenção do binlog nas configurações do MySQL e garanta que o deslocamento esteja configurado dentro desse intervalo de tempo quando a tarefa de sincronização iniciar.

Erro do MySQL: MySQLBinlogReaderException

Se uma tarefa de sincronização em tempo real do MySQL falhar com a mensagem MySQLBinlogReaderException: The database you are currently syncing is the standby database, but the current value of log_slave_updates is OFF, you need to enable the binlog log update of the standby database first. , pode ser porque o binlog não está habilitado no banco de dados standby. Se desejar sincronizar um banco de dados standby, habilite o binlog para bancos de dados standby em cascata. Solicite ajuda ao seu DBA.

Para mais informações sobre como habilitar o binlog, consulte Etapa 3: Habilitar binlog para MySQL.

Erro do MySQL: show master status' has an error!

Se uma tarefa de sincronização em tempo real do MySQL falhar com a mensagem show master status' has an error! e os detalhes do erro forem Caused by: java.io.IOException: message=Access denied; you need (at least one of) the SUPER, REPLICATION CLIENT privilege(s) for this operation, with command: show master status, pode ser porque a conta da fonte de dados não possui as permissões necessárias no banco de dados.

A conta configurada para a fonte de dados deve ter as permissões SELECT, REPLICATION SLAVE e REPLICATION CLIENT para o banco de dados. Para mais informações sobre como conceder permissões à conta da fonte de dados, consulte Etapa 2: Criar uma conta e conceder permissões.

Erro do MySQL: parse.exception.PositionNotFoundException: can't find start position forxxx

O processo de sincronização não conseguiu encontrar o deslocamento. Redefina o deslocamento.

Erro do PolarDB: The mysql server does not enable the binlog write function. Please enable the mysql binlog write function first

• Possível causa: o parâmetro loose_polar_log_bin não está habilitado para a fonte de dados PolarDB de origem.

• Solução: habilite o parâmetro loose_polar_log_bin. Para mais informações, consulte Configurar uma fonte de dados PolarDB.

Erro do Hologres: permission denied for database xxx

Ao sincronizar dados para o Hologres em tempo real, conceda permissões de administrador ao usuário atual para a instância do Hologres. O usuário deve ter permissão para criar schemas. Para mais informações, consulte Modelo de permissões do Hologres.

Erro do MaxCompute: ODPS-0410051:invalid credentials-accessKeyid not found

Ao sincronizar dados para uma fonte de dados MaxCompute em tempo real usando um AccessKey temporário, o AccessKey temporário expira automaticamente após 7 dias, o que causa a falha da tarefa. A plataforma reinicia automaticamente a tarefa ao detectar uma falha causada por um AccessKey temporário expirado. Se você configurou alertas de monitoramento para esse tipo de falha, receberá um alerta.

Erro do Oracle: logminer doesn't init, send HeartbeatRecord

Quando uma tarefa de sincronização em tempo real do Oracle é inicializada, ela carrega um log de arquivamento anterior para encontrar um deslocamento de sincronização adequado. Se o log de arquivamento for grande, a fase de inicialização pode levar de 3 a 5 minutos para ser concluída.