Data Transmission Service:Perguntas frequentes sobre change tracking

P: Como o change tracking funciona?

R: Para obter informações sobre o funcionamento do change tracking, consulte Architecture and features.

P: Quais dados uma instância de change tracking pode rastrear e quais informações posso obter?

É possível rastrear alterações no nível de schema (criações, exclusões e modificações) dos objetos monitorados, bem como atualizações de dados (operações INSERT, DELETE e UPDATE) nesses objetos.

P: O grupo de consumidores é excluído após o vencimento de uma tarefa de change tracking?

R: Após o vencimento de uma instância de change tracking do DTS, o grupo de consumidores de dados é retido por 7 dias. Se a instância não for renovada dentro de 7 dias após o vencimento, ela será liberada e o grupo de consumidores correspondente será excluído.

P: Uma instância somente leitura pode ser usada como instância source de uma tarefa de change tracking?

P: Como consumo os dados rastreados?

Para mais informações, consulte Consume tracked data.

P: Por que o formato de data muda após a transferência de dados pelo recurso de change tracking?

R: O formato de armazenamento padrão para valores de data no DTS é YYYY:MM:DD. O formato YYYY-MM-DD é apenas o formato de exibição; o formato de armazenamento real é YYYY:MM:DD. Portanto, independentemente do formato em que os dados são gravados durante a transferência, eles são convertidos para o formato padrão.

P: Como soluciono problemas em tarefas de change tracking?

R: Para obter informações sobre como solucionar problemas em tarefas de change tracking, consulte Troubleshoot issues with change tracking tasks.

P: O SDK pausou inesperadamente durante o download normal de dados e não consegue mais rastrear dados. Como resolvo esse problema?

R: Verifique se o código do SDK chama o método ackAsConsumed para reportar o offset do consumidor. Se ackAsConsumed não for chamado para reportar o offset, o cache de registros configurado no SDK não será limpo. Quando o cache estiver totalmente ocupado, nenhum dado novo poderá ser obtido, fazendo com que o SDK pause e pare de rastrear dados.

P: O SDK não consegue rastrear dados corretamente após ser reiniciado. Como resolvo esse problema?

R: Antes de iniciar o SDK, modifique o offset do consumidor para que ele esteja dentro do intervalo de dados. Para obter informações sobre como modificar o offset do consumidor, consulte Save and query consumption checkpoints.

P: Como um cliente especifica um ponto no tempo a partir do qual consumir dados?

R: Ao consumir dados rastreados, especifique um ponto no tempo definindo o parâmetro initCheckpoint. Para mais informações, consulte Consume subscription data using SDK sample code.

P: A tarefa de change tracking do DTS acumulou dados. Como redefinir o offset?

1. Abra o arquivo de código correspondente com base no modo de uso do cliente SDK. Por exemplo, DTSConsumerAssignDemo.java ou DTSConsumerSubscribeDemo.java.

   Nota

   Para mais informações, consulte Consume subscription data using SDK sample code.

2. Na lista de tarefas de change tracking, na coluna Data Range, visualize o intervalo de offset modificável da instância de change tracking de destino.

3. Selecione um novo offset do consumidor conforme suas necessidades e converta-o em um timestamp Unix.

4. No arquivo de código, substitua o offset do consumidor antigo (o parâmetro initCheckpoint) pelo novo offset do consumidor.

5. Reinicie o cliente.

P: O cliente não consegue se conectar à tarefa de change tracking pelo endpoint VPC. Como resolvo esse problema?

R: O servidor em que o cliente é executado pode não estar na VPC especificada durante a configuração da tarefa de change tracking (por exemplo, a VPC do cliente foi alterada). Reconfigure a tarefa.

P: Por que o offset do consumidor exibido no console é maior que o valor máximo do intervalo de dados?

R: O intervalo de dados de um canal de change tracking é atualizado a cada 1 minuto, enquanto o offset do consumidor é atualizado a cada 10 segundos. Portanto, quando os dados são consumidos em tempo real, o valor do offset do consumidor pode ser maior que o valor máximo do intervalo de dados do canal de change tracking.

P: Como o DTS garante que os dados rastreados pelo SDK formem uma transação completa?

R: Com base no offset do consumidor fornecido, o servidor DTS localiza a transação completa correspondente ao offset e distribui os dados downstream a partir da instrução BEGIN da transação. Dessa forma, você recebe o conteúdo completo da transação.

P: Como confirmo se os dados estão sendo consumidos normalmente?

R: Se os dados estiverem sendo consumidos normalmente, o offset do consumidor no console do Data Transmission Service avança conforme o esperado.

P: O que significa usePublicIp=true no SDK de change tracking?

R: Definir usePublicIp=true no SDK de change tracking indica que o SDK acessa o canal de change tracking do DTS pela Internet.

P: Meu negócio é afetado quando ocorre uma troca primário/secundário ou uma reinicialização do banco de dados primário na instância RDS source de uma tarefa de change tracking?

R: Quando ocorre uma troca primário/secundário ou uma reinicialização em uma instância ApsaraDB RDS for MySQL, ApsaraDB RDS for PostgreSQL, PolarDB for MySQL, PolarDB for PostgreSQL ou PolarDB-X 1,0 (com o tipo de armazenamento RDS MySQL), o DTS se adapta automaticamente à troca e seu negócio não é afetado.

P: O ApsaraDB RDS oferece suporte ao download automático de binlogs para um servidor local?

R: O change tracking do DTS oferece suporte ao rastreamento em tempo real de binlogs do ApsaraDB RDS. Ative o serviço de change tracking do DTS e use o DTS SDK para rastrear os dados de binlog do ApsaraDB RDS e sincronizá-los com um servidor local em tempo real.

P: Os dados incrementais em tempo real rastreados pelo change tracking incluem apenas dados recém-adicionados ou também incluem dados modificados?

R: Os dados incrementais que o change tracking do DTS pode rastrear incluem todas as inserções, exclusões e atualizações, além de alterações de schema (DDL).

P: Um registro no lado do consumidor de uma tarefa de change tracking não recebeu ACK. Por que o SDK recebe dados duplicados após ser reiniciado?

R: Quando o SDK tem uma mensagem sem ACK, o servidor continua enviando todas as mensagens no buffer. Após a conclusão do envio, o SDK não consegue mais receber mensagens. Nesse momento, o offset do consumidor salvo no servidor é o offset da última mensagem anterior à mensagem sem ACK. Quando o SDK é reiniciado, para garantir que nenhuma mensagem seja perdida, o servidor envia os dados novamente a partir do offset correspondente à mensagem anterior à que estava sem ACK. Por isso, o SDK recebe algumas mensagens duplicadas.

P: Com que frequência o offset do consumidor de change tracking é atualizado? Por que o SDK às vezes recebe dados duplicados após ser reiniciado?

R: Após o SDK de change tracking consumir cada mensagem, ele deve chamar ackAsConsumed para enviar um ACK ao servidor. Depois que o servidor recebe o ACK, atualiza o offset do consumidor em memória e persiste o offset a cada 10 segundos. Se o SDK for reiniciado antes que o ACK mais recente seja persistido, o servidor envia mensagens a partir do offset do consumidor persistido anteriormente para garantir que nenhuma mensagem seja perdida. Como resultado, o SDK recebe mensagens duplicadas.

P: Uma instância de change tracking pode rastrear múltiplas instâncias RDS?

R: Não. Atualmente, uma instância de change tracking pode rastrear apenas uma instância RDS.

P: Pode ocorrer inconsistência de dados em uma instância de change tracking?

R: Não. Uma tarefa de change tracking apenas obtém alterações do banco de dados source e não envolve inconsistência de dados. Se os dados consumidos pelo cliente não corresponderem ao esperado, investigue o problema no seu lado.

P: Como trato a mensagem UserRecordGenerator que aparece ao consumir dados rastreados?

R: Ao consumir dados rastreados, se aparecer uma mensagem como UserRecordGenerator: haven't receive records from generator for 5s, verifique se o offset do consumidor está dentro do intervalo de offset do módulo de coleta de dados incrementais e certifique-se de que o consumidor esteja em execução corretamente.

P: Um tópico oferece suporte a múltiplas partições?

R: Não. Para garantir a ordenação global das mensagens, cada tópico de change tracking possui apenas uma partição, que é fixa e atribuída à partição 0.

P: O SDK de change tracking oferece suporte a Go?

R: Sim. Para código de exemplo, consulte dts-subscribe-demo.

P: O SDK de change tracking oferece suporte a Python?

R: Sim. Para código de exemplo, consulte dts-subscribe-demo.

P: O flink-dts-connector oferece suporte ao consumo concorrente com múltiplas threads dos dados rastreados?

R: Não.

P: O que fazer se eu esquecer o nome de usuário ou a senha do grupo de consumidores de uma instância de change tracking?

R: Se o seu negócio permitir, exclua o grupo de consumidores e crie um novo (com o nome de usuário original e uma nova senha).

P: É possível configurar uma tarefa de change tracking e uma tarefa de sincronização de dados na mesma instância RDS simultaneamente?

R: Sim. Ambas as tarefas podem ser configuradas ao mesmo tempo sem interferir uma na outra. O change tracking e a sincronização de dados são dois tipos de tarefas independentes que coexistem na mesma instância RDS sem causar conflitos.