A sincronização offline de um banco de dados inteiro envolve várias etapas, como migração de schema, sincronização completa e sincronização incremental offline. O grande volume de tabelas e a alta densidade de instâncias agendadas tornam as operações de O&M complexas. Este tópico descreve as principais operações de O&M, incluindo início e parada de tarefas, modificação de configurações e reexecução para backfill de dados. Também apresenta métodos de solução de problemas e recomendações de ajuste para ajudar você a gerenciar essas tarefas com eficiência. Para obter informações sobre como configurar essas tarefas, consulte Configurar uma tarefa de sincronização offline para um banco de dados inteiro.
Observações de uso
Antes de solucionar problemas na sincronização offline de um banco de dados inteiro, avalie o tipo de tarefa, os recursos do canal e o foco da investigação para confirmar se este tópico se aplica ao seu cenário.
|
Critério |
Cenários aplicáveis |
Cenários não aplicáveis/Foco principal |
|
Tipo de tarefa |
Sincronização em lote offline de um banco de dados inteiro ou de múltiplas tabelas: sincronização completa única, sincronização completa periódica ou sincronização incremental periódica que utiliza valores de campo para definir condições incrementais. |
Tarefas de CDC em tempo real ou consumo de mensagens. Os métodos de solução de problemas offline não se aplicam. |
|
Canais típicos |
Source: Leitura offline de bancos de dados, data warehouses ou arquivos. Destino: MaxCompute, Hologres, Hive, DLF, Elasticsearch, StarRocks, entre outros. |
Não trate uma tarefa como sincronização incremental offline se não houver um campo incremental estável disponível. |
|
Foco da solução de problemas |
Instância agendada, data de negócio, condições WHERE, splitPk, partições de source, mapeamentos de campos, partições de destino, modo de escrita e idempotência para reexecuções. |
Não envolve offsets de log em tempo real ou failover. |
A sincronização offline de um banco de dados inteiro depende das capacidades de leitura e escrita offline. Ela não utiliza Binlog, WAL ou Oplog e não oferece semântica de recuperação de offset de log em tempo real.
Etapas da tarefa
A sincronização offline de um banco de dados inteiro geralmente inclui as seguintes etapas. Cada etapa possui prioridades diferentes de O&M.
|
Etapa |
Descrição |
Foco de O&M |
|
Migração de schema |
Lê os schemas das tabelas do source e cria ou atualiza as tabelas no destino. |
Permissões de metadados, permissões de criação de tabelas no destino, mapeamentos de tipos de colunas e mapeamentos de nomes de tabelas. |
|
Sincronização completa única |
Escreve dados históricos do source para o destino em lote. |
Chave de divisão, concorrência offline, contagem de conexões do source, capacidade de escrita do destino e especificações de recursos. |
|
Sincronização incremental offline periódica |
Sincroniza dados novos ou alterados conforme o agendamento. |
Horário do agendamento, dependências upstream, parâmetros de data de negócio, partições de destino e nomes de saída. |
A sincronização incremental offline requer um campo capaz de identificar dados incrementais, como um campo de hora de atualização ou um campo autoincremental. Caso a tabela de source não possua um campo incremental estável, geralmente é necessário optar pela sincronização completa periódica ou modificar a tabela de source antes de configurar a sincronização incremental offline.
Tarefas offline para um banco de dados inteiro costumam gerar múltiplas subtarefas offline. Quanto maior o número de tabelas envolvidas, mais significativo será o impacto nas instâncias agendadas, no consumo de recursos e na pressão de escrita no destino.
Operações de O&M
Iniciar e parar
Após enviar uma tarefa de sincronização completa única, verifique se todas as subtarefas completas estão em execução adequada. Para tarefas offline periódicas, confirme também se as instâncias agendadas foram geradas conforme esperado, se as dependências upstream foram atendidas e se a data de negócio está correta.
Antes de parar uma tarefa, verifique se já houve escrita de dados em algumas tabelas ou partições no destino. Se a tarefa utilizar uma estratégia de escrita por sobrescrita ou limpeza de partição, atente-se à idempotência e a possíveis conflitos de sobrescrita simultânea ao reexecutar a tarefa.
Para operações gerais de agendamento e gerenciamento de tarefas, como pausa, retomada e backfill de dados, consulte O&M for scheduled instances.
Modificar configurações
As modificações comuns em tarefas offline para um banco de dados inteiro incluem adição de tabelas, remoção de tabelas, ajuste de mapeamentos de tabelas, ajuste de regras de partição, alteração de configurações de agendamento e ajuste de concorrência e recursos.
|
Tipo de alteração |
Risco |
Recomendação |
|
Adicionar tabelas |
Novas tabelas exigem migração de schema e geração de instâncias agendadas. |
Após enviar a alteração, verifique se as novas tabelas geraram tarefas ou instâncias offline correspondentes. |
|
Remover tabelas |
Pode afetar nós de agendamento existentes e dependências downstream. |
Antes de remover tabelas, confirme que as tarefas downstream não dependem mais das saídas correspondentes. |
|
Modificar regras de partição |
Pode causar escrita de dados em partições incorretas ou sobrescrita de partições erradas. |
Antes de enviar a alteração, valide os parâmetros de data de negócio e as expressões de partição de destino. |
|
Modificar agendamentos |
Pode impactar dependências upstream e o tempo de saída downstream. |
Após a modificação, verifique se as instâncias agendadas estão sendo geradas nos novos horários. |
|
Ajustar concorrência e recursos |
Pode aumentar a carga de conexões no source, a pressão de escrita no destino e o consumo do grupo de recursos. |
Faça ajustes graduais e monitore a carga no source, no destino e no grupo de recursos. |
Reexecutar e fazer backfill de dados
É comum reexecutar tarefas offline de um banco de dados inteiro ou utilizá-las para backfill de dados a fim de reparar partições ausentes no destino. Antes de prosseguir, confirme os seguintes pontos:
As tabelas e o intervalo de datas de negócio que precisam ser reparados.
O modo de escrita no destino (anexar, sobrescrever ou truncar e escrever).
Se outras instâncias estão escrevendo simultaneamente na mesma tabela ou partição de destino.
Se tarefas downstream já consumiram dados incorretos.
Se as tarefas downstream precisam ser reexecutadas após a reexecução atual.
Caso o modo de escrita no destino envolva limpeza de partição, não execute múltiplas tarefas simultaneamente na mesma partição. Se necessário, pause instâncias conflitantes ou escalone os horários de execução.
Para mais informações sobre backfill de dados, consulte O&M for backfill instances.
Solução de problemas
Falha na atualização do mapeamento de tabelas ou tabelas não selecionáveis
As causas mais frequentes incluem permissões insuficientes no source, problemas de conectividade de rede do grupo de recursos, volume excessivo de metadados no source, escopo muito amplo de filtros de banco de dados/tabelas, excesso de tabelas selecionadas e permissões insuficientes no destino. Siga esta ordem para solucionar o problema:
Use o grupo de recursos especificado na configuração da tarefa para testar novamente a conectividade com o source e o destino.
Verifique se a conta do source tem permissões para ler metadados de banco de dados, tabelas e colunas.
Se o escopo do filtro de banco de dados/tabelas for amplo ou houver muitas tabelas selecionadas, reduza o escopo inicialmente para validar.
Confira se a conta de destino possui permissões de criação de tabelas ou de escrita.
Verifique se ocorrem timeouts na API de metadados quando o source possui um grande número de tabelas.
Falha na migração de schema
Quando a migração de schema falhar, verifique primeiramente as permissões de criação de tabelas no destino, a existência do banco de dados ou schema de destino, a compatibilidade dos tipos de colunas e possíveis conflitos nos mapeamentos de nomes de tabelas. Para tabelas particionadas, valide também se as colunas de partição, os níveis de partição e as expressões de partição atendem aos requisitos do destino.
Tarefa de sincronização completa lenta
|
Item |
Como identificar |
Recomendação |
|
Consultas lentas no source |
CPU elevada, I/O alto, SQL lento ou esperas por bloqueio no banco de dados de source. |
Otimize as consultas no source, evite horários de pico de negócios e reduza a concorrência se necessário. |
|
Divisão desigual de dados |
Algumas subtarefas demoram significativamente mais que as demais. |
Escolha uma chave de divisão mais adequada ou divida tabelas grandes em tarefas separadas. |
|
Baixa concorrência |
Throughput baixo apesar da carga reduzida tanto no source quanto no destino. |
Aumente gradualmente a concorrência offline e as especificações de recursos. |
|
Conexões insuficientes |
Logs indicam falta de conexões ou cota esgotada. |
Aumente o número máximo de conexões no source ou a cota da fonte de dados e monitore a estabilidade do banco de dados de source. |
|
Escrita lenta no destino |
Throttling no destino, excesso de partições ou commits em lote lentos. |
Resolva primeiro problemas de recursos do destino, throttling e design de partições. |
|
Recursos insuficientes |
CPU, memória ou rede próximos dos limites superiores. |
Aumente as especificações de recursos ou CUs e monitore GC e taxas de falha. |
Ao ajustar a sincronização offline de um banco de dados inteiro, evite aumentar significativamente a concorrência logo no início. O aumento da concorrência eleva o número de conexões no source, a pressão de escrita no destino e o consumo do grupo de recursos. Se o gargalo estiver no source ou no destino, aumentar a concorrência geralmente apenas amplifica o problema.
Para soluções gerais relacionadas à lentidão na sincronização de dados, consulte Troubleshoot slow data synchronization.
Instância agendada sem produção de saída
Quando uma instância offline periódica não gera saída ou produz uma saída inesperada, verifique os seguintes itens nesta ordem:
Se o agendamento periódico está ativado e se o horário está conforme o esperado.
Se as dependências upstream foram concluídas.
Se os parâmetros de data de negócio estão corretos.
Se os nomes de saída e as expressões de partição de destino estão corretos.
Se existem falhas de escrita ou problemas de permissão no destino.
Se tarefas downstream dependem de saídas ou partições incorretas.
Instâncias incrementais offline dependem tanto das condições incrementais quanto dos parâmetros de agendamento para determinar o intervalo de dados. Ao solucionar problemas em instâncias agendadas, verifique se o campo de condição incremental existe, se o tipo de campo permite comparação e se os parâmetros de agendamento estão sendo passados corretamente para a partição de destino ou para as condições de filtro WHERE.
Recomendações de ajuste
|
Item de ajuste |
Recomendação |
|
CUs totais de recursos |
Aumente o total de recursos quando o número de tabelas ou subtarefas paralelas for elevado. Aumentar apenas as CUs tem efeito limitado quando ocorre throttling no source ou no destino. |
|
CUs por tarefa |
Aumente os recursos por tarefa para tabelas largas, campos grandes ou tabelas com grande volume de dados. |
|
Concorrência offline |
Aumente gradualmente com base na capacidade de conexões do source e na capacidade de escrita do destino. |
|
Máximo de conexões no source |
Ajuste em coordenação com a concorrência offline. Definir esse valor muito alto pode comprometer a estabilidade do banco de dados de source. |
|
Configuração de throttling |
Quando o throttling está ativado, o throughput é limitado ativamente. Antes de ajustar, determine se é necessário desativar ou aumentar o limite de throttling. |
|
Design de partições |
Evite partições excessivamente granulares que gerem arquivos pequenos, excesso de partições ou alta sobrecarga de escrita. |
Em tarefas offline que envolvem um grande número de tabelas, monitore separadamente tabelas grandes, tabelas largas e tabelas pequenas. Algumas poucas tabelas grandes podem determinar o tempo total de conclusão, e o throughput médio não reflete necessariamente o gargalo real.
Para informações sobre a relação entre concorrência e throttling, consulte Relationship between concurrency and throttling for batch synchronization.
Alertas e monitoramento
Para tarefas offline de um banco de dados inteiro, concentre-se nos alertas de agendamento e de instâncias offline. Geralmente, os alertas precisam ser configurados após localizar as subtarefas agendadas ou instâncias offline geradas no Operation Center. Não confie apenas no status geral da tarefa da solução.
Recomendamos configurar as seguintes regras de monitoramento:
Falha na instância: Dispara um alerta imediatamente quando uma tarefa falha.
Timeout da instância: Dispara um alerta quando uma tarefa excede o tempo de execução esperado.
Dependência upstream não concluída: A tarefa upstream da qual a tarefa atual depende não foi finalizada no prazo.
Instância agendada não gerada: Nenhuma instância é gerada após o horário agendado.
Partição de destino não produzida: A partição de destino esperada não é gerada no prazo.
Falha de conexão com source ou destino: A conexão com a fonte de dados apresenta anomalias.
Se as tarefas offline de um banco de dados inteiro forem sensíveis ao tempo para consumo downstream, configure regras de timeout de instância e validação de saída. Configurar apenas alertas de falha não detecta casos em que uma tarefa roda por um período prolongado sem produzir a saída no prazo.
Para obter informações sobre como configurar regras de alerta, consulte Configure a task for offline synchronization for an entire database > Step 6: Configure alert rules.
Checklist de operações de alto risco
Antes de realizar reexecuções em larga escala, backfill de dados, remoção de tabelas, modificação de regras de partição ou aumento significativo de concorrência, confirme os seguintes pontos: quais tabelas e datas de negócio serão afetadas, se o modo de escrita no destino irá sobrescrever ou limpar partições, se outras instâncias estão escrevendo na mesma tabela ou partição de destino, se tarefas downstream já consumiram os dados afetados, se o source e o destino suportam maior concorrência e se as tarefas downstream precisam ser reexecutadas.
FAQ
As perguntas abaixo derivam principalmente de soluções históricas de problemas em tarefas offline periódicas para bancos de dados inteiros. Ao investigar um problema, identifique primeiro o tipo de tarefa, o source e o destino, e depois faça uma validação cruzada verificando a configuração da página, as instâncias agendadas, os logs de execução e os resultados no destino.
Se eu remover uma tabela e adicioná-la novamente, as antigas instâncias incrementais serão interrompidas?
Como verificar: Após remover a tabela e aplicar a atualização, os nós de agendamento periódico subsequentes deixam de ser implantados. No entanto, não assuma que instâncias já geradas ou em execução serão interrompidas automaticamente.
Ação recomendada: Se for necessário interromper as escritas imediatamente, verifique o status das instâncias agendadas correspondentes no Operation Center. Pare ou pause manualmente as instâncias relevantes se necessário e, em seguida, adicione a tabela novamente, reexecute ou faça o backfill de dados.
Schema ou nome do banco de dados de destino não corresponde ao esperado após adicionar uma tabela
Como verificar: Valide se as regras de mapeamento de schema, nome do banco de dados ou nome da tabela foram alteradas e confirme se a nova tabela utilizou o mapeamento padrão.
Ação recomendada: Verifique e configure as regras de mapeamento de schema, nome do banco de dados ou nome da tabela para evitar que novas tabelas sejam escritas em um destino não intencional.
Atualização do mapeamento de tabelas lenta, com timeout ou tabelas não selecionáveis
Como verificar: Verifique a conectividade do grupo de recursos, a duração da consulta de metadados no source, o número de tabelas selecionadas e as permissões da conta do source.
Ação recomendada: Reduza inicialmente o escopo de bancos de dados/tabelas para validar. Confira os parâmetros de conexão da fonte de dados e o desempenho da consulta de metadados no source. Se um objeto não for selecionável, consulte os objetos suportados na página.
Condição incremental periódica produz resultados inconsistentes com a configuração
Como verificar: Valide se as condições incrementais foram modificadas, se os parâmetros de agendamento são calculados com base na data de negócio ou no tempo de execução e se a partição de destino e as condições de filtro utilizam o mesmo conjunto de parâmetros.
Ação recomendada: Verifique conjuntamente as condições incrementais, os parâmetros de agendamento e as expressões de partição de destino. Ao fazer backfill de dados, confirme o intervalo de datas de negócio.
Instância agendada permanece aguardando upstream
Como verificar: Verifique se IDs adicionais de nós upstream ou regras de nomes de nós upstream foram configurados nos parâmetros avançados.
Ação recomendada: Limpe configurações desnecessárias de dependência upstream, reimplemente a tarefa e monitore as relações de dependência da instância.
Partição de destino não produzida ou escrita em partição incorreta
Como verificar: Confirme se a coluna de partição realmente existe, se a expressão de partição está correta e se o nível de partição, a diferenciação de maiúsculas/minúsculas e os espaçamentos atendem aos requisitos do destino.
Ação recomendada: Faça uma validação cruzada dos metadados da tabela de destino e dos parâmetros periódicos. Se necessário, valide a escrita de partições com uma única tabela ou um pequeno conjunto de tabelas primeiro.
Nome de saída downstream conflitante ou com caracteres especiais
Como verificar: Verifique se as regras de nomenclatura de saída do nó de agendamento produzem saídas duplicadas ou contêm caracteres especiais não suportados pelo sistema de agendamento de destino.
Ação recomendada: Ajuste as regras de nomenclatura de saída e evite caracteres especiais como $. Após salvar e implantar as alterações, valide as dependências downstream.
Views ou objetos especiais não selecionáveis
Como verificar: Valide se o tipo de objeto do source é suportado pelo canal atual de sincronização offline para o banco de dados inteiro.
Ação recomendada: Utilize os objetos selecionáveis na página como referência. Se um objeto não for suportado, utilize a sincronização em lote de tabela única ou materialize os resultados da view em uma tabela física antes da sincronização.
splitPk não surte efeito ou causa divisão desigual
Como verificar: Valide se o tipo da coluna da chave de divisão é suportado pela fonte de dados e pelo canal de sincronização, se a distribuição dos dados é uniforme e se existe um grande número de valores nulos.
Ação recomendada: Alterne para uma chave de divisão suportada com distribuição mais uniforme. Tabelas grandes podem ser divididas em tarefas separadas para ajuste individual.
Para informações sobre limitações da chave de divisão, consulte Configure a task for offline synchronization for an entire database > Quotas and limits.
Referências
Configure a task for offline synchronization for an entire database — O processo completo de configuração para tarefas de sincronização offline de um banco de dados inteiro.
Troubleshoot slow data synchronization — Soluções gerais para cenários de sincronização de dados lenta.
Relationship between concurrency and throttling for batch synchronization — Detalhes de configuração para concorrência e throttling no Channel Control.