Como faço para usar o recurso de aplicação em lote do DMS para melhorar o desempenho da replicação do CDC?

9 minuto de leitura
0

Estou executando uma carga completa e uma tarefa de captura de dados de alteração (CDC) do AWS Database Migration Service (AWS DMS). A latência de origem não é alta, mas a latência de destino é alta ou está aumentando. Como faço para acelerar a fase de replicação do CDC?

Breve descrição

O AWS DMS usa os seguintes métodos para replicar dados na fase de captura de dados de alteração (CDC):

  • Aplicação transacional
  • Aplicação em lote

O processo CDC do AWS DMS é de encadeamento único, por padrão (aplicação transacional). Esse é o mesmo método usado para replicação de SQL e para todos os outros mecanismos de banco de dados de processamento transacional on-line (OLTP). A replicação do CDC do DMS depende dos logs de transações do banco de dados de origem. Durante a fase de replicação contínua, o DMS aplica as alterações usando um método de aplicação transacional, da seguinte forma:

  1. O DMS lê as alterações do log de transações, da origem para a memória da instância de banco de dados de replicação.
  2. O DMS traduz as alterações e as passa para um componente classificador.
  3. O componente classificador classifica as transações em ordem de confirmação e, em seguida, as encaminha para o destino, sequencialmente.

Se a taxa de alteração for alta no banco de dados de origem, esse processo poderá levar tempo. Você pode ver um aumento nas métricas de latência do destino do CDC quando o DMS recebe alta workload de entrada do banco de dados de origem.

O DMS usa um único método de replicação encadeada para processar as alterações do CDC. O DMS fornece a configuração de nível de tarefa BatchApplyEnabled para processar rapidamente as alterações em um destino usando lotes. **BatchApplyEnabled ** é útil se você tiver alta workload no banco de dados de origem e uma tarefa com alta latência do CDC de destino. Por padrão, o DMS desativa batchAplySetting. Você pode ativá-lo usando a AWS Command Line Interface (AWS CLI).

Como funciona a aplicação em lote

Se você executar uma tarefa com BatchAplyEnabled, o DMS processará as alterações da seguinte forma:

  1. O DMS coleta as alterações em lote dos registros de transações do banco de dados de origem.
  2. O DMS cria uma tabela chamada tabela de alterações líquidas, com todas as alterações do lote.
  3. Essa tabela reside na memória da instância de banco de dados de replicação e é passada para a instância de banco de dados de destino.
  4. O DMS aplica um algoritmo de mudanças líquidas que distribui todas as alterações da tabela de alterações líquidas para a tabela de destino real.

Por exemplo, se você executar uma tarefa de DMS com BatchApplyEnabled e tiver uma nova inserção de linha, dez atualizações nessa linha e uma exclusão dessa linha em um único lote, o DMS distribuirá todas essas transações e não as transferirá. Isso acontece porque a linha acaba sendo excluída e não existe mais. Esse processo reduz o número de transações reais que são aplicadas no destino.

BatchAplyEnabled aplica o algoritmo de alterações líquidas no nível da linha de uma tabela em um lote de uma tarefa específica. Portanto, se o banco de dados de origem tiver alterações frequentes (atualização, exclusão e inserção) ou uma combinação dessas workloads nas mesmas linhas, você poderá obter o melhor uso do BatchAppplyEnabled. Isso minimiza as alterações a serem aplicadas no destino. Se o lote coletado for único nas alterações (atualizar/excluir/inserir alterações em registros de linha diferentes), o processo do algoritmo da tabela de alterações líquidas não poderá filtrar qualquer evento. Com isso, todos os eventos em lote são aplicados no destino no modo de lote. As tabelas devem ter uma chave primária ou uma chave exclusiva para aplicação em lote ao trabalho.

O DMS também fornece a configuração BatchApplyPreserveTransaction para ajuste do processamento de alterações. Se você ativar BatchAplyEnabled, BatchAplyPreserveTransaction será ativado, por padrão. Se você defini-lo como true, a integridade transacional será preservada. É garantido que um lote contenha todas as alterações em uma transação a partir da origem. Essa configuração se aplica somente aos endpoints de destino da Oracle.

Observação: preste atenção às vantagens e desvantagens dessa configuração. Quando a configuração BatchApplyPreserveTransaction é definida como true, o DMS captura toda a transação de longa duração na memória da instância de banco de dados de replicação. Ele faz isso de acordo com as configurações da tarefa MemoryLimitTotal e MemoryKeepTime e troca conforme necessário antes de enviar as alterações para a tabela de alterações líquidas. Quando a configuração batchAplyPreserveTransaction é definida como false, as alterações de uma única transação podem abranger vários lotes. Isso pode levar à perda de dados quando aplicado parcialmente, por exemplo, devido à indisponibilidade do banco de dados de destino.

Para mais informações sobre a latência do DMS e o processo de aplicação em lote, consulte a Parte 2 e a Parte 3 de Depurar seus blogs de migração do AWS DMS.

Casos de uso para aplicação em lote

Você pode usar a aplicação em lote nas seguintes circunstâncias:

  • A tarefa tem um grande número de transações capturadas da origem e isso está causando a latência do destino.
  • A tarefa tem uma workload da origem que é uma combinação de inserção, atualização e exclusão nas mesmas linhas.
  • Não há necessidade de manter uma integridade referencial estrita no destino (FKs desativados).

Limitações

Atualmente, a aplicação em lote tem as seguintes limitações**:**

  • O destino do Amazon Redshift usa a aplicação em lote, por padrão. O destino do Amazon Simple Storage Service (Amazon S3) é forçado a usar a aplicação transacional.
  • A aplicação em lote só pode funcionar em tabelas com chave primária/índice exclusivo. Para tabelas sem chave primária/índice exclusivo, a aplicação em massa aplicará somente a inserção no modo em massa, mas executará atualizações e exclusões uma a uma. Se a tabela tiver chave primária/índice exclusivo, mas for observado o modo alternado um a um, consulte Como faço para solucionar o motivo pelo qual o Amazon Redshift mudou para o modo um a um porque uma operação em massa falhou durante uma tarefa do AWS DMS?
  • Quando colunas LOB são incluídas na replicação, você pode usar BatchAplyEnabled somente no modo LOB limitado. Para mais informações, consulte Target metadata task settings (Configurações da tarefa de metadados do destino).
  • Quando batchApplyEnabled é definido como true, o AWS DMS gera uma mensagem de erro se uma tabela de destino tiver uma restrição exclusiva.

Resolução

Observação: se você receber erros ao executar comandos da AWS Command Line Interface (AWS CLI), certifique-se de estar usando a versão mais recente da AWS CLI.

BatchAplySetting é desativado por padrão. Você pode ativar essa configuração usando o AWS CLI ou o console do AWS DMS. Conclua as seguintes tarefas de configuração em seu sistema antes de ativar a configuração em lote:

Verificar o status da configuração em lote de uma tarefa existente

  1. Abra o console do AWS DMS.
  2. No painel de navegação, escolha Database migration tasks (Tarefas de migração de banco de dados)
  3. Escolha sua tarefa e, em seguida, escolha Configuração da tarefa (JSON). No JSON, BatchAplyEnabled está listado no status disabled.

Ative a configuração em lote usando o AWS CLI

  1. Abra o sistema com o AWS CLI instalado.
  2. Execute o comando aws configure para abrir o prompt da AWS CLI.
  3. Insira seu ID de chave de acesso da AWS e pressione Enter.
  4. Insira seu ID de chave secreta da AWS e pressione Enter.
  5. Insira o nome da região dos seus recursos de DMS e pressione Enter.
  6. Insira o formato de saída e pressione Enter.
  7. Execute o comando modify-replication-task com o ARN da tarefa e as condições de configuração em lote.

Observação: confirme se a tarefa está no estado stopped antes de modificá-la. Altere o ARN no comando a seguir com base na sua tarefa e, em seguida, execute-o para alterar a configuração da tarefa.

Depois que o comando for executado com êxito na CLI da AWS, abra o console do DMS e verifique novamente o status da configuração em lote da sua tarefa. BatchAplyEnabled agora está listado como “enabled” na Configuração da tarefa (JSON).

Agora você pode iniciar a tarefa do DMS e observar o desempenho da migração.

aws dms modify-replication-task --replication-task-arn arn:aws:dms:us-east-1:123456789123:task:4VUCZ6ROH4ZYRIA25M3SE6NXCM --replication-task-settings "{\"TargetMetadata\":{\"BatchApplyEnabled\":true}}"

Ativar a configuração em lote usando o console do AWS DMS

  1. Abra o console do AWS DMS.
  2. No painel de navegação, escolha Tarefa de migração de banco de dados.
  3. Escolha sua tarefa e, em seguida, escolha Modificar.
  4. Na seção Configurações da tarefa, escolha Editor JSON.
  5. Modifique as configurações da tarefa que você deseja alterar. Por exemplo, na seção TargetMetadata, altere BatchApplyEnabled para true (o padrão é false).
  6. Clique em Salvar para modificar a tarefa.

Verifique se as alterações entraram em vigor seguindo estas etapas:

  1. Na página Lista de tarefas, escolha a tarefa que você modificou.
  2. Na guia Visão geral dos detalhes, expanda Configurações da tarefa (JSON).
  3. Revise as configurações da tarefa.

Solucionar problemas de CDCLatencyTarget alta após executar a tarefa no modo em lote

Se CDCLatencyTarget estiver alto após a execução da tarefa no modo em lote, a latência poderá ser causada pelo seguinte:

  • Transação de longa duração atingida devido à falta de índice primário e secundário
  • Disponibilidade insuficiente de recursos para processar a workload no destino
  • Alta contenção de recursos na instância de replicação do DMS

Siga as Melhores práticas do DMS para solucionar esses problemas.


Informações relacionadas

Monitorar tarefas do AWS DMS

Como criar um script de migração de banco de dados

Automatizar tarefas de migração do AWS DMS

Como faço para criar endpoints de origem ou de destino usando o AWS DMS?

Alterar configurações de ajuste de processamento

AWS OFICIAL
AWS OFICIALAtualizada há 2 anos