A sincronização completa de banco de dados em tempo real abrange migração de schema, inicialização completa e sincronização incremental em várias tabelas durante longos períodos. Saiba como iniciar e parar tarefas, modifique configurações, configure alertas e aplique as melhores práticas de solução de problemas e ajustes.
Pré-requisitos
Antes de execute operações ou solucionar problemas, verifique se as seguintes condições foram atendidas:
Requisitos de permissão
Conta de source: A conta deve ter permissões para ler metadados, como bancos de dados, tabelas, colunas, chaves primárias e índices. Também são necessárias permissões para ler o log de alterações do source, como Binlog, WAL (Write-Ahead Logging) ou Oplog.
Conta de destino: A conta deve ter permissões para crie tabelas, alterar tabelas e gravar dados.
Conectividade de rede
O grupo de recursos precisa conseguir acessar tanto o source quanto o destino. Problemas de rede podem causar falhas na migração de schema, interrupção da inicialização completa ou falhas na sincronização incremental.
Retenção de logs do source
A retenção insuficiente de logs é o motivo mais comum pelo qual uma tarefa não consegue retomar a partir do offset original após ser parada.
Compatibilidade entre source de dados e canal
As capacidades de sincronização (como carga completa, incremental e DDL) variam conforme o source de dados. As opções configuráveis na UI representam os recursos suportados. Verifique se as versões do seu source e destino são compatíveis com o canal.
Escopo e aplicabilidade
Antes de solucionar problemas em uma tarefa de sincronização completa de banco de dados em tempo real, revise o tipo de tarefa, as capacidades do canal e as principais áreas de solução de problemas para confirme se este tópico se aplica ao seu cenário.
|
Critério |
Escopo aplicável |
Não aplicável / Foco principal |
|
Tipo de tarefa |
Change Data Capture (CDC) em tempo real para múltiplas tabelas ou banco de dados completo. |
Não se aplica à sincronização em tempo real de tabela única. Para tarefas de tabela única, consulte Operações e ajustes para sincronização em tempo real de tabela única. |
|
Canais típicos |
Source de banco de dados para Hologres, MaxCompute, ADB (AnalyticDB), Doris, StarRocks, SelectDB, Kafka, DLF (Data Lake Formation), Lindorm, Elasticsearch ou OSS (Object Storage Service). |
Não aplicável a outros tipos de canal. |
|
Foco na solução de problemas |
Retenção de logs, offset, chave primária, DDL, carga do source, performance de gravação no destino, partições, commits, arquivos pequenos, limitação de taxa e backlog. |
Além do status da tarefa, utilize métricas e logs para uma solução de problemas detalhada. |
A sincronização completa de banco de dados em tempo real depende que o source forneça continuamente um log de alterações (como Binlog, WAL ou Oplog). O destino deve suportar o modo de gravação atual, a semântica de chave primária ou única e as alterações de schema necessárias. Se essas condições não forem atendidas, a tarefa poderá não ser executada corretamente ou garantir a consistência dos dados.
Estágios da tarefa
Uma tarefa de sincronização completa de banco de dados em tempo real geralmente progride pelos seguintes estágios, cada um com um foco operacional diferente.
|
Estágio |
Descrição |
Foco operacional |
|
Migração de schema |
Lê informações de banco de dados, tabelas e colunas do source e cria ou atualiza estruturas de tabelas no destino. |
Permissões de metadados do source, permissões de criação de tabelas no destino, mapeamento de tipos de dados, regras de mapeamento de nomes de tabelas. |
|
Inicialização completa |
Lê dados históricos do source e os grava no destino para preencher os dados existentes antes do início da tarefa. |
Chave de divisão, concorrência de carga completa, contagem de conexões do source, grupo de recursos, capacidade de gravação do destino, recuperação completa e incremental. |
|
Sincronização incremental |
Consome continuamente as alterações do source e as grava no destino. |
Atraso de offset, throughput de leitura e gravação, failover, checkpoint, eventos DDL, retenção de logs do source. |
Uma tarefa de sincronização completa de banco de dados em tempo real geralmente conclui primeiro a migração de schema e a inicialização completa, e então processa continuamente a sincronização incremental.
Os dados incrementais gerados durante a inicialização completa dependem da retenção de logs do source e da capacidade do pipeline em tempo real de recuperar o atraso. Portanto, ao iniciar, parar, reexecutar ou adicionar tabelas a uma tarefa, monitore tanto o Progresso da Inicialização Completa quanto a Latência em Tempo Real.
Operações
Iniciar e parar tarefas
Após iniciar uma tarefa, verifique se ela está sendo executada corretamente checando os seguintes itens nesta ordem:
Verifique se a migração de schema foi concluída e se as estruturas das tabelas foram criadas no destino.
Observe a inicialização completa para garantir que a leitura e a gravação de dados estejam normais. As taxas de leitura e gravação completas devem estar estáveis, e o número de tabelas concluídas deve aumentar continuamente.
Confirme se a sincronização incremental está funcionando normalmente. A latência em tempo real deve estar dentro de uma faixa razoável, sem failovers frequentes e com commits de checkpoint bem-sucedidos.
Antes de parar uma tarefa, verifique se o período de retenção de logs do source é longo o suficiente para cobrir o tempo de inatividade. Se uma tarefa ficar parada por muito tempo, o Binlog, WAL ou logs de mensagens do source podem ser limpos, impedindo que a tarefa retome a partir do último offset salvo. Ao retomar a tarefa, ela continua a partir do último offset salvo. Se o offset tiver expirado, avalie os riscos de redefinir o offset ou reinicializar a tarefa. Para mais informações, consulte "Não é possível retomar uma tarefa a partir do offset anterior após ser parada" na seção de perguntas frequentes.
Modifique configurações
Para uma tarefa de sincronização completa de banco de dados em tempo real em execução, talvez seja necessário adicionar ou remover tabelas, ajustar mapeamentos de tabelas ou modifique recursos para cargas de trabalho completas ou incrementais. Após modifique a configuração, envie e aplique as atualizações seguindo as instruções na tela.
|
Tipo de alteração |
Riscos |
Recomendações |
|
Adicionar tabela |
Requer releitura de metadados e, dependendo das capacidades do canal, pode acionar migração de schema, inicialização completa e sincronização incremental. |
Confirme se as novas tabelas correspondem às regras de seleção e atualize os mapeamentos de tabelas. Monitore o progresso da inicialização completa, o status de integração incremental e a retenção de logs do source para as novas tabelas. |
|
Excluir tabela |
Remover tabelas de uma tarefa em execução pode afetar mapeamentos existentes, dados no destino e dependências downstream. |
Antes de remover uma tabela, confirme que nenhum processo de negócio depende dela. Se necessário, crie uma nova tarefa para lidar com o escopo atualizado. |
|
Modifique regras de mapeamento |
Pode causar conflitos de nomes de tabelas no destino, colunas ausentes, alterações de partição ou mudanças na forma como os dados existentes são tratados. |
Antes de envie, verifique os nomes das tabelas de destino, tipos de colunas, chaves primárias, partições, colunas adicionais e dados existentes no destino. |
|
Ajustar recursos |
Alocações de recursos, concorrência e contagens de conexão diferem entre a inicialização completa e a sincronização incremental. Ajustes inadequados podem aumentar a carga no source ou no destino. |
Ajuste os recursos incrementalmente. Após cada alteração, monitore a taxa de inicialização completa, latência em tempo real, failover, checkpoint e utilização de recursos. |
Como as alterações de configuração entram em vigor:
Atualizar mapeamentos de tabelas e adicionar novas tabelas geralmente não exigem pausar a tarefa.
Ajustar especificações de recursos, como CU (Compute Unit), pode exigir reiniciar a tarefa ou aguardar o próximo checkpoint para entrar em vigor. Siga as instruções na tela.
Modifique as regras de mapeamento enquanto a tarefa estiver pausada para evitar afetar dados em trânsito.
Se uma alteração de configuração falhar, reverta para a configuração anterior e envie novamente.
Configuração de alertas
Para tarefas de sincronização completa de banco de dados em tempo real, configure alertas para pelo menos os seguintes eventos:
|
Tipo de alerta |
Casos de uso |
Descrição |
|
Status anormal da tarefa |
Todas as tarefas |
Aciona um alerta imediatamente se uma tarefa falhar ou encerrar inesperadamente. |
|
Latência de negócio |
Todas as tarefas |
Aciona um alerta quando a latência em tempo real excede o limiar aceitável pelo negócio. |
|
Failover |
Todas as tarefas |
Failovers frequentes geralmente indicam um problema que requer intervenção manual. |
|
Utilização de recursos |
Cenários com recursos limitados |
Aciona um alerta quando a utilização de CPU, memória ou rede está excessivamente alta. |
|
Notificação de DDL |
Canais que processam eventos DDL |
Eventos DDL podem afetar o schema do destino e devem ser monitorados. |
|
Backlog |
Sources Kafka, DataHub ou LogHub |
Monitore o backlog de partições, shards ou tópicos usando o console do source ou métricas da tarefa. |
Para sources baseados em logs, como MySQL e PostgreSQL, monitore também o período de retenção de logs como Binlog e WAL para evitar falhas na recuperação da tarefa causadas pela expiração dos logs.
Para obter etapas detalhadas sobre como configurar regras de alerta, consulte Regras de alerta comuns.
Métodos de solução de problemas
Falhas na migração de schema
Falhas na migração de schema geralmente resultam de problemas de permissão, erros de leitura de metadados, incompatibilidade de tipos de dados ou problemas na criação de tabelas no destino. Solucione o problema na seguinte ordem:
Verifique se a conta do source tem permissões para ler metadados, incluindo bancos de dados, tabelas, colunas, chaves primárias e índices.
Verifique a conectividade de rede entre o grupo de recursos da tarefa e tanto o source quanto o destino.
Verifique se a conta de destino tem permissões para crie tabelas, alterar tabelas e gravar dados.
Verifique se as regras de mapeamento para nomes de tabelas, bancos de dados ou schemas geram nomes duplicados ou inválidos.
Verifique se os tipos de dados, chaves primárias, colunas de partição e colunas adicionais são compatíveis com o destino.
Ao selecionar tabelas usando expressões regulares ou em massa, teste primeiro com um pequeno número de tabelas antes de expandir o escopo de sincronização.
Inicialização completa lenta ou com falha
Se a inicialização completa estiver lenta ou falhar, determine se a tarefa está travada durante a inicialização de recursos, leitura do source, gravação no destino ou aguardando para recuperar o atraso das alterações incrementais. Verifique métricas como taxa de leitura completa, taxa de gravação, número de tabelas concluídas, shards restantes, contagem de conexões do source e latência de gravação no destino.
|
Sintoma |
Causa possível |
Recomendação |
|
A tarefa de inicialização completa não inicia por um longo período. |
Fila no grupo de recursos, falha na inicialização de recursos ou problemas de conectividade com o source ou destino. |
Verifique o status do grupo de recursos e a conectividade de rede. Verifique se as permissões das contas do source e destino estão corretas. |
|
Baixa taxa de leitura completa. |
Chave de divisão mal distribuída, consultas SQL do source não utilizando índices, alta carga no source ou conexões/cota insuficientes. |
Verifique a chave de divisão e os índices, e ajuste moderadamente a concorrência da carga completa. Se a carga do source for alta, aplique limitação de taxa ou execute a tarefa fora do horário de pico. |
|
Baixa taxa de gravação completa. |
Capacidade de gravação insuficiente no destino, partições mal projetadas ou parâmetros de gravação em lote inadequados. |
Verifique a carga do destino, QPS de gravação, latência de commit em lote e número de partições. |
|
Recuperação incremental lenta após a conclusão da inicialização completa. |
Um grande volume de alterações ocorreu no source durante a inicialização completa, e o pipeline em tempo real precisa processar o backlog de logs. |
Verifique se a latência em tempo real está diminuindo continuamente e garanta que o período de retenção de logs do source seja suficiente. |
Alta latência em tempo real
Quando a latência em tempo real aumenta, primeiro determine se a tarefa ainda está na fase de recuperação da inicialização completa. Em seguida, identifique se o gargalo está no leitor, no pipeline de processamento ou no gravador.
|
Sintoma |
Causa possível |
Recomendação |
|
A latência permanece alta após a conclusão da inicialização completa. |
Grande backlog de alterações incrementais acumuladas durante a inicialização completa; leitura lenta de logs do source; gravação lenta para recuperação no destino. |
Monitore a taxa de leitura incremental, taxa de gravação e tempo de retenção de logs do source para confirme que a latência está diminuindo continuamente. |
|
Alto tempo de espera do leitor. |
Aumento repentino no volume de alterações do source, transações grandes, backlog de logs do source ou desequilíbrio de partições/shards. |
Verifique picos de gravação no source, crescimento de logs e distribuição de partições ou shards. |
|
Alto tempo de espera do gravador. |
Performance de gravação lenta no destino, limitação de taxa, conexões insuficientes ou excesso de partições dinâmicas. |
Verifique os recursos do destino, QPS de gravação, latência de commit em lote e design de partições. |
|
Failover frequente. |
Memória insuficiente, instabilidade de service externo, falhas de checkpoint ou erros de processamento de DDL. |
Examine os logs antes e depois do failover. Analise métricas de memória, utilização de recursos e checkpoint para resolver o problema. |
|
A latência aumenta após um evento DDL. |
Processamento de DDL demorado ou falha ao alterar o schema no destino. |
Revise o evento DDL e as permissões do destino para confirme se a política de tratamento de DDL está conforme o esperado. |
Se o source for Kafka, DataHub ou LogHub, uma única partição ou shard geralmente só pode ser consumida por um processo concorrente. Se os dados estiverem concentrados em poucas partições, aumentar a concorrência geral da tarefa pode não ajudar.
Novas tabelas não estão sincronizando
Se uma nova tabela não estiver sendo sincronizada, verifique os seguintes itens nesta ordem:
A nova tabela corresponde às regras atuais de seleção de banco de dados e tabelas?
O mapeamento da tabela foi atualizado com sucesso?
Verifique se as tabelas foram criadas ou se o schema foi migrado no destino.
A tarefa suporta adicionar tabelas dinamicamente durante a execução?
Verifique os detalhes de execução para a migração de schema, inicialização completa ou eventos em tempo real da tabela correspondente.
Para canais que não suportam adicionar tabelas dinamicamente, modifique a configuração e publique novamente, ou crie uma nova tarefa para lidar com as novas tabelas. Se as novas tabelas exigirem dados históricos, confirme se o canal realiza uma inicialização completa para elas. Caso contrário, use um preenchimento de dados ou uma capacidade separada de sincronização completa.
Recomendações de ajustes
|
Item de ajuste |
Cenário |
Recomendação |
|
Especificações de recursos de carga completa / Compute Unit (CU) |
A inicialização completa está na fila, a velocidade de execução é baixa ou a utilização do grupo de recursos é alta. |
Aumente gradualmente os recursos de carga completa ou execute tarefas fora do horário de pico. Monitore a taxa de leitura, taxa de gravação e carga do source. |
|
Concorrência de carga completa e chave de divisão |
A fase de carga completa é executada, mas a velocidade geral é lenta. |
Escolha uma chave de divisão que seja uniformemente distribuída e tenha índice. Aumente a concorrência moderadamente. Se a carga do source for alta, reduza a concorrência ou aplique limitação de taxa. |
|
Conexões do source / Cota |
A inicialização completa reporta erros relacionados a conexões, Cota ou limitação de taxa. |
Reduza a concorrência de tarefas do mesmo source. Ou aumente o número de conexões e a Cota se a capacidade do source permitir. |
|
Especificações de recursos incrementais / CU |
A utilização de CPU, memória, rede ou grupo de recursos está alta. |
Aumente gradualmente os recursos. Observe se a latência, failover e performance de checkpoint melhoram. |
|
Concorrência incremental |
Múltiplas tabelas, partições ou shards têm paralelismo suficiente. |
Primeiro, confirme que não há hotspots de tabela única ou gargalos de shard único. Em seguida, aumente a concorrência. |
|
Intervalo de Checkpoint / Flush |
O destino faz commits frequentemente ou a sobrecarga para commits em lote é alta. |
Aumente ligeiramente o intervalo e observe o throughput e a latência de visibilidade dos dados. Não aumente demais de uma só vez. |
|
Parâmetros de gravação em lote no destino |
O tempo de espera do destino é alto. |
Ajuste os parâmetros de batch, flush, commit ou pool de conexões com base nas limitações do product de destino. |
|
Granularidade de partição dinâmica |
O destino tem muitas partições ou alta pressão de flush. |
Priorize o ajuste da granularidade da partição. Evite usar campos de alta cardinalidade para particionamento, como timestamps de nível de segundo, IDs de pedidos ou IDs de usuários. |
A inicialização completa e a sincronização incremental têm objetivos de ajuste diferentes. A inicialização completa foca em concluir as gravações de dados históricos de maneira estável. A sincronização incremental foca em reduzir continuamente a latência. Após o ajuste, observe a performance por pelo menos uma janela estável. Julgar a eficácia apenas com base no throughput de curto prazo após uma reinicialização pode ser enganoso.
Para configurações de recursos recomendadas, consulte CUs recomendadas para integração de dados. Ajuste as configurações conforme necessário.
Perguntas frequentes
As perguntas a seguir são extraídas do histórico de solução de problemas para tarefas de sincronização completa de banco de dados em tempo real e estão organizadas por fase da tarefa. Ao solucionar problemas, primeiro confirme a fase atual da sua tarefa. Em seguida, faça uma verificação cruzada usando eventos da tarefa, logs de execução, métricas, retenção de logs do source e resultados no destino.
Problemas com migração de schema
|
Problema |
Áreas principais para verificar |
Ação recomendada |
|
O mapeamento de tabelas demora para atualizar, atinge timeout ou tabelas não são selecionáveis |
Conectividade do grupo de recursos, permissões de metadados do source, número de bancos de dados e tabelas, número de campos, tipos de objetos do source e cache de source de dados |
Primeiro, restrinja o escopo de bancos de dados e tabelas para testar. Confirme que a conta tem permissões para ler bancos de dados, tabelas, campos, chaves primárias e índices. Se um objeto não for selecionável, sua disponibilidade é determinada pelo escopo suportado do canal atual. |
Problemas com inicialização completa
|
Problema |
Áreas principais para verificar |
Ação recomendada |
|
A inicialização completa está travada ou falha ao iniciar |
Fila do grupo de recursos, conectividade com source ou destino, cota de source de dados, recursos para a fase de inicialização completa e resultados de criação de tabelas no destino |
Primeiro, confirme se a migração de schema foi concluída. Em seguida, verifique se as subtarefas completas foram iniciadas. Se a cota ou o número de conexões for insuficiente, reduza a concorrência ou aumente a cota para o source ou destino. |
Problemas com sincronização incremental
|
Problema |
Áreas principais para verificar |
Ação recomendada |
|
A latência em tempo real permanece alta após a conclusão da inicialização completa |
Dados incrementais acumulados durante a inicialização completa, velocidade de leitura de logs do source, velocidade de gravação no destino, checkpoints e failover |
Observe se a latência diminui continuamente. Se não diminuir, verifique o offset de leitura, tempo de espera de gravação, falhas de checkpoint e limitação de taxa no destino. |
|
A tarefa não consegue retomar a partir do offset anterior após ser parada |
Verifique se o período de retenção para Binlog, Write-Ahead Logging (WAL), logs de mensagens ou offsets de consumo expirou. Verifique se a instância do source foi reconstruída ou se seus logs foram limpos. |
Antes de parar uma tarefa, confirme se o período de retenção de logs cobre o tempo de inatividade esperado. Se um offset estiver indisponível, geralmente é necessário redefini-lo ou reinicializar a tarefa. Avalie os riscos de duplicação e perda de dados antes de prosseguir. |
|
A tarefa falha ou a latência aumenta após uma operação de Data Definition Language (DDL) |
Os tipos de operações DDL que o source pode gerar, as ações de tratamento de DDL que o destino suporta e a estratégia e permissões de DDL da tarefa |
Revise os eventos DDL e os resultados da alteração de schema no destino. Não ignore operações DDL não suportadas. Primeiro, confirme seu impacto no schema do destino e na consistência dos dados. |
|
Dados incorretos no destino após operações DELETE ou UPDATE |
Se o destino tem uma chave primária ou única para localizar registros. Se o mapeamento da chave primária é consistente. Se o modo de gravação suporta atualizações e exclusões. |
Verifique a chave primária do source, chave primária do destino, mapeamento de tabelas e logs de dados incorretos (dirty data). Se o destino não tiver uma chave primária válida ou se o mapeamento for inconsistente, as operações UPDATE e DELETE podem não ser aplicadas aos registros corretos no destino. |
Problemas com sources de mensagens
|
Problema |
Áreas principais para verificar |
Ação recomendada |
|
Alta latência de sources de mensagens como Kafka, DataHub e LogHub |
Verifique hotspots em partições, shards ou tópicos. Verifique se a concorrência de consumo excede o número de partições que podem ser consumidas em paralelo. Verifique se o offset de consumo está significativamente atrasado. |
Primeiro, verifique gargalos em uma única partição ou shard. Se os hotspots estiverem concentrados, aumentar a concorrência total pode não ser eficaz. Ajuste as partições do source ou a capacidade de gravação do destino. |
Problemas com gravação no destino
|
Problema |
Áreas principais para verificar |
Ação recomendada |
|
Gravações lentas em destinos como MaxCompute devido a um número excessivo de partições |
Granularidade dos campos de partição dinâmica, número de partições dentro de um único checkpoint, tempo de Tunnel ou commit e limitação de taxa no destino |
Reduza a granularidade da partição ou evite usar campos de alta cardinalidade para particionamento. Em seguida, ajuste commits em lote, cache de partição e especificações de recursos com base nas capacidades do destino. |
Problemas com consistência de dados
|
Problema |
Áreas principais para verificar |
Ação recomendada |
|
Dados históricos não são sincronizados após a adição de uma nova tabela |
Verifique se a nova tabela corresponde às regras de seleção. Verifique se o mapeamento da tabela foi atualizado com sucesso. Verifique se o canal suporta inicialização completa para novas tabelas. Verifique se a nova tabela está configurada apenas para sincronização incremental. |
Se você precisar de dados históricos, confirme se a inicialização completa está habilitada ou foi acionada para a nova tabela. Se isso não for suportado, use um processo de preenchimento de dados ou uma tarefa separada de sincronização completa para popular os dados históricos. |
|
Os dados tornam-se inconsistentes após uma tabela ser excluída durante a execução ou no source |
Verifique se a tabela excluída ainda corresponde às regras da tarefa. Verifique como a estratégia de DDL lida com DROP TABLE. Verifique se há dependências downstream na tabela de destino. |
Antes de remover uma tabela durante a execução, confirme que nenhum processo de negócio depende dela. Excluir uma tabela no source não a limpa automaticamente no destino. Se necessário, gerencie a tabela de destino separadamente de acordo com suas políticas de governança de dados. |
|
Uma quantidade anormal de dados incorretos (dirty data) é gerada |
Verifique se a tarefa está configurada para tolerar dados incorretos. Verifique se houve alterações nos tipos de campos, comprimentos, chaves primárias, restrições não nulas ou limites de gravação no destino. |
Não aumente simplesmente o limiar de dados incorretos para permitir que a tarefa continue. Primeiro, determine se os dados incorretos causarão dados ausentes ou anomalias de campo no destino. Em seguida, decida se deve corrigir os dados, ajustar o mapeamento ou tolerar temporariamente os erros. |
Problemas específicos do PostgreSQL
|
Problema |
Áreas principais para verificar |
Ação recomendada |
|
Arquivos WAL acumulam no source PostgreSQL |
Atraso do slot de replicação, offset de consumo, checkpoints e se a tarefa está fazendo commit dos offsets corretamente |
Se a tarefa estiver consumindo dados normalmente, mas o tamanho do WAL não diminuir, verifique o atraso do slot de replicação e o status de commit do offset. Isso ajuda a evitar que o disco do source seja preenchido por arquivos WAL. |
Lista de verificação de operações de alto risco
Antes de remover tabelas, adicionar um grande número de tabelas, reiniciar uma tarefa, reexecutar uma inicialização completa ou fazer alterações importantes de parâmetros, verifique cada item nesta lista. Se uma verificação falhar, tome a ação recomendada antes de prosseguir.
O período de retenção de logs do source é longo o suficiente para a inicialização completa e recuperação incremental?
Se o destino tiver dados existentes ou dependências downstream, existe uma estratégia clara de sobrescrita, anexação ou limpeza antes de reexecutar a inicialização completa?
As novas tabelas requerem dados históricos e o canal atual suporta inicialização completa para elas?
Existem instruções de Data Definition Language (DDL) não processadas ou failovers frequentes?
Os alertas cobrem status da tarefa, exceções de inicialização completa, latência de negócio, failover e DDL?