Criar tarefas para replicação contínua usando o AWS DMS - AWS Database Migration Service
Replicação a partir de um ponto de início de CDCExecutar replicação bidirecional

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Criar tarefas para replicação contínua usando o AWS DMS

Você pode criar umaAWS DMS tarefa que capture as alterações contínuas do armazenamento de dados de origem. Você pode fazer essa captura enquanto migra seus dados. Também é possível criar uma tarefa que capture alterações contínuas depois de concluir a migração inicial (carregamento completo) para um armazenamento de dados de destino compatível. Esse processo é chamado de replicação contínua ou captura de dados de alteração (CDC). O AWS DMS usa esse processo ao replicar alterações contínuas de um armazenamento de dados de origem. Esse processo funciona ao coletar as alterações nos logs de banco de dados usando a API nativa do mecanismo de banco de dados.

nota

Você pode migrar exibições usando apenas tarefas de carregamento completo. Se a tarefa for somente CDC ou uma tarefa de carregamento completo que inicie a CDC após a conclusão, a migração incluirá apenas tabelas da origem. Usando uma full-load-only tarefa, você pode migrar exibições ou uma combinação de tabelas e exibições. Para obter mais informações, consulte Especificando regras de seleção e transformações de tabelas usando JSON.

Cada mecanismo de origem tem requisitos de configuração específicos para expor esse fluxo de alterações a uma conta de usuário específica. A maioria dos mecanismos exige algumas configurações adicionais para possibilitar que o processo de captura consuma os dados de alteração de forma significativa, sem perda de dados. Por exemplo, a Oracle exige a adição do registro em log suplementar e o MySQL exige o registro em log binário a nível de linha (registro binário).

Para fazer a leitura das alterações contínuas do banco de dados de origem, o AWS DMS usa ações da API específicas do mecanismo para ler alterações dos logs de transação do mecanismo de origem. Veja a seguir alguns exemplos de como o AWS DMS faz isso:

  • Para a Oracle,AWS DMS usa a LogMiner API Oracle ou a API do leitor binário (API bfile) para ler as alterações em andamento. AWS DMSlê as alterações contínuas dos redo logs on-line ou arquivados com base no número de alteração do sistema (SCN).

  • Para o Microsoft SQL Server, o AWS DMS usa MS-Replication ou MS-CDC para gravar informações no log de transações do SQL Server. Depois, ele usa a função fn_dblog() ou fn_dump_dblog() no SQL Server para ler as alterações no log de transações com base no log sequence number (LSN – número de sequência de log).

  • Para o MySQL, o AWS DMS lê as alterações dos logs binários (binlogs) baseados em linhas e migra essas alterações para o destino.

  • Para o PostgreSQL, o AWS DMS define slots de replicação lógica e usa o plugin test_decoding para ler as alterações da origem e migrá-las para o destino.

  • Para o Amazon RDS como fonte, recomendamos garantir que os backups estejam habilitados para configurar o CDC. Também recomendamos garantir que o banco de dados de origem esteja configurado para reter os registros de alterações por um tempo suficiente — 24 horas geralmente são suficientes.

Existem dois tipos de tarefas de replicação contínua:

  • Carga total mais CDC — A tarefa migra os dados existentes e, em seguida, atualiza o banco de dados de destino com base nas alterações no banco de dados de origem.

  • Somente CDC — A tarefa migra as alterações contínuas depois que você tem dados em seu banco de dados de destino.

Executar a replicação a partir de um ponto de início de CDC

É possível iniciar uma tarefa de replicação contínua do AWS DMS (somente para captura de dados de alteração) de diversos pontos. Incluindo o seguinte:

  • A partir de um horário de início personalizado do CDC — Você pode usar oAWS Management Console ouAWS CLI paraAWS DMS fornecer um carimbo de data e hora em que deseja que a replicação comece. AWS DMSem seguida, inicia uma tarefa de replicação contínua a partir desse horário de início personalizado do CDC. AWS DMSconverte o timestamp fornecido (em UTC) em um ponto inicial nativo, como um LSN para SQL Server ou um SCN para Oracle. AWS DMSusa métodos específicos do mecanismo para determinar onde iniciar a tarefa de migração com base no fluxo de alterações do mecanismo de origem.

    nota

    Somente definindo o atributo deStartFromContext conexão com o timestamp necessário, o Db2, como fonte, oferece um horário de início personalizado do CDC.

    PostgreSQL como uma origem não suporta um horário de início de CDC personalizado. Isso ocorre porque o mecanismo de banco de dados do PostgreSQL não consegue mapear um timestamp para um LSN ou SCN, como fazem o Oracle e o SQL Server.

  • De um ponto inicial nativo do CDC — Você também pode começar de um ponto nativo no registro de transações do mecanismo de origem. Em alguns casos, você pode preferir essa abordagem porque um timestamp pode indicar vários pontos nativos no log de transações. O AWS DMS oferece suporte a esse recurso para os seguintes endpoints de origem:

    • SQL Server

    • PostgreSQL

    • Oracle

    • MySQL

Quando a tarefa é criada,AWS DMS marca o ponto inicial do CDC e não pode ser alterada. Para usar um ponto inicial diferente do CDC, crie uma nova tarefa.

Determinar um ponto de início de CDC nativo

Um ponto de início de CDC nativo é um ponto no log do mecanismo do banco de dados que define um horário para começar a CDC. Como exemplo, suponha que um despejo de dados em massa já tenha sido aplicado a um destino. Você pode pesquisar o ponto de partida nativo para a tarefa contínua somente de replicação. Para evitar inconsistências de dados, escolha cuidadosamente o ponto de partida para a tarefa somente de replicação. O DMS captura transações iniciadas após o ponto inicial do CDC escolhido.

Os exemplos a seguir mostram como encontrar o ponto de partida nativo da CDC em mecanismos de origem compatíveis:

SQL Server

No SQL Server, o número de sequência de log (LSN) tem três partes:

  • Número de sequência do Arquivo de log virtual (VLF)

  • Deslocamento inicial de um bloco de log

  • Número do slot

Um exemplo de LSN é o seguinte: 00000014:00000061:0001

Para obter o ponto de início para uma tarefa de migração do SQL Server com base nas configurações de backup do log de transações, use as funções fn_dblog() ou fn_dump_dblog() no SQL Server.

Para usar o ponto inicial nativo do CDC com o SQL Server, crie uma publicação em qualquer tabela que participe da replicação contínua. AWS DMScria a publicação automaticamente quando você usa o CDC sem usar um ponto inicial nativo do CDC.

PostgreSQL

Use um ponto de verificação de recuperação de CDC para seu banco de dados de origem PostgreSQL. Esse valor de ponto de verificação é gerado em vários pontos à medida que uma tarefa de replicação contínua é executada para o banco de dados de origem (a tarefa pai). Para obter mais informações sobre pontos de verificação em geral, consulteUsar um ponto de verificação como um ponto de início de CDC.

Para identificar o ponto de verificação a ser usado como seu ponto de partida nativo, use apg_replication_slots visualização do banco de dados ou os detalhes da visão geral da tarefa principal a partir doAWS Management Console

Como encontrar os detalhes da visão geral da tarefa pai no console

  1. Faça login noAWS Management Console e abra oAWS DMS console em https://console.aws.amazon.com/dms/v2/.

    Se você estiver conectado a um usuário do IAM, verifique se tem as permissões apropriadas para acessoAWS DMS. Para obter mais informações sobre as permissões necessárias, consulte Permissões do IAM necessárias para usar o AWS DMS.

  2. No painel de navegação, escolha Tarefas de migração do banco de dados.

  3. Escolha a tarefa pai na lista na página Database migration tasks (Tarefas de migração de banco de dados). Isso abre a página da tarefa pai mostrando os detalhes da visão geral.

  4. Encontre o valor do ponto de verificação em Captura de dados de alteração (CDC), Posição inicial da captura de dados de alteração (CDC) e Ponto de verificação de recuperação da captura de dados de alteração (CDC).

    O valor é semelhante ao valor a seguir:

    checkpoint:V1#1#000004AF/B00000D0#0#0#*#0#0

    Aqui, o componente 4AF/B00000D0 é o que você precisa para especificar esse ponto inicial do CDC nativo. Defina o parâmetro CdcStartPosition da API do DMS para esse valor ao criar a tarefa CDC para iniciar a replicação neste ponto inicial para sua origem PostgreSQL. Para obter informações sobre como usar a AWS CLI para criar a tarefa de CDC, consulte Habilitando o CDC com uma instânciaAWS de banco de dados PostgreSQL gerenciada comAWS DMS.

Oracle

Um número de alterações do sistema (SCN) é um time stamp interno e lógico usado por bancos de dados Oracle. Os SCNs ordenam os eventos que ocorrem dentro do banco de dados, o que é necessário para satisfazer as propriedades ACID de uma transação. Os bancos de dados Oracle usam SCNs para marcar o local onde todas as alterações foram gravadas em disco para que uma ação de recuperação não seja aplicada nas alterações já gravadas. A Oracle também usa SCNs para marcar o ponto onde não existem ações de restauração para um conjunto de dados, para que a recuperação possa parar.

Para obter o SCN atual em um banco de dados Oracle, execute o seguinte comando.

SELECT CURRENT_SCN FROM V$DATABASE

Se você usar o SCN atual para iniciar uma tarefa de CDC, perderá os resultados de todas as transações abertas e não conseguirá migrar esses resultados. As transações abertas são transações que foram iniciadas anteriormente, mas ainda não foram confirmadas. Você pode identificar o SCN e a data e hora para iniciar uma tarefa de CDC em um ponto que inclua todas as transações abertas. Para obter mais informações, consulte Transações na documentação on-line da Oracle.

MySQL

Antes do lançamento do MySQL versão 5.6.3, o número de sequência de log (LSN) para MySQL era um inteiro não assinado de 4 bytes. No MySQL versão 5.6.3, quando o limite de tamanho de arquivo de log redo aumentou de 4 GB para 512 GB, o LSN se tornou um inteiro não assinado de 8 bytes. O aumento reflete que bytes adicionais foram necessários para armazenar informações de tamanho extra. Os aplicativos criados no MySQL 5.6.3 ou posterior que usam valores de LSN devem usar variáveis de 64 bits em vez de 32 bits para armazenar e comparar valores de LSN. Para obter mais informações LSNs do MySQL, consulte a documentação do MySQL.

Para obter a LSN atual em um banco de dados MySQL, execute o seguinte comando.

mysql> show master status;

A consulta retorna o nome e a posição do arquivo de log binário, além de vários outros valores. O ponto de início nativo de CDC é uma combinação do nome e da posição do arquivo de log binário, por exemplo, mysql-bin-changelog.000024:373. Nesse exemplo, mysql-bin-changelog.000024 é o nome do arquivo de log binário e 373 é a posição onde o AWS DMS precisa iniciar a captura de alterações.

Usar um ponto de verificação como um ponto de início de CDC

Uma tarefa de replicação contínua migrará as alterações, e o AWS DMS armazenará em cache as informações sobre ponto de verificação específicos do AWS DMS, periodicamente. O ponto de verificação criado pelo AWS DMS contém informações para que o mecanismo de replicação conheça o ponto de recuperação para o fluxo de alterações. Você pode usar o ponto de verificação para voltar no cronograma de alterações e recuperar uma tarefa de migração com falha. Você também pode usar um ponto de verificação para iniciar outra tarefa de replicação contínua para outro destino em qualquer ponto no tempo determinado.

É possível obter as informações do ponto de verificação de uma das três maneiras a seguir:

  • Executar a operação da APIDescribeReplicationTasks e visualizar os resultados. Você pode filtrar as informações por tarefa e pesquisar o ponto de verificação. Você pode recuperar o último ponto de verificação quando a tarefa está no estado interrompida ou com falha. Essas informações serão perdidas se a tarefa for excluída.

  • Visualize a tabela de metadados chamada awsdms_txn_state na instância de destino. Você pode consultar a tabela para obter informações do ponto de verificação. Para criar a tabela de metadados, defina o parâmetro TaskRecoveryTableEnabled como Yes ao criar uma tarefa. Essa configuração faz com que o AWS DMS grave continuamente as informações do ponto de verificação na tabela de metadados de destino. Essas informações serão perdidas se uma tarefa for excluída.

    Por exemplo, o seguinte é uma verificação de exemplo na tabela de metadados: checkpoint:V1#34#00000132/0F000E48#0#0#*#0#121

  • No painel de navegação, escolha Tarefas de migração de banco de dados e escolha sua tarefa principal na lista que aparece na página Tarefas de migração de banco de dados. Sua página de tarefas principal é aberta, mostrando os detalhes da visão geral. Encontre o valor do ponto de verificação em Captura de dados de alteração (CDC), Posição inicial da captura de dados de alteração (CDC) e Ponto de verificação de recuperação da captura de dados de alteração (CDC). O valor do ponto de verificação é semelhante ao seguinte:

    checkpoint:V1#1#000004AF/B00000D0#0#0#*#0#0

Interromper uma tarefa em um ponto de tempo de confirmação ou servidor

Com a introdução dos pontos de início de CDC nativos, o AWS DMS também pode interromper uma tarefa nos seguintes pontos:

  • Um tempo de confirmação na origem

  • Um tempo do servidor na instância de replicação

Você pode modificar uma tarefa e definir um tempo em UTC para interrompê-la, conforme necessário. A tarefa é interrompida automaticamente com base nos tempos de confirmação ou servidor definidos. Ou, se souber um tempo adequado para interromper a tarefa de migração durante a criação da tarefa, defina também um tempo de interrupção ao criar a tarefa.

Executar replicação bidirecional

Você pode usar as tarefas do AWS DMS para executar a replicação bidirecional entre dois sistemas. Na replicação bidirecional, replique os dados da mesma tabela (ou conjunto de tabelas) entre dois sistemas nas duas direções.

Por exemplo, você pode copiar uma tabela EMPLOYEE do banco de dados A para o banco de dados B e replicar alterações na tabela do banco de dados A para o banco de dados B. Você também pode replicar alterações na tabela EMPLOYEE do banco de dados B de volta para A. Assim, você estará executando a replicação bidirecional.

nota

A replicação bidirecional do AWS DMS não pretende ser uma solução completa de vários mestres, incluindo nó primário, resolução de conflitos e assim por diante.

Use a replicação bidirecional para situações em que os dados em diferentes nós são segregados operacionalmente. Em outras palavras, vamos supor que você tenha um elemento de dados alterado por um aplicativo operando no nó A e que o nó A execute a replicação bidirecional com o nó B. Esse elemento de dados no nó A nunca será alterado por nenhum aplicativo que opere no nó B.

AWS DMSoferece suporte à replicação bidirecional nesses mecanismos de banco de dados:

  • Oracle

  • SQL Server

  • MySQL

  • PostgreSQL

  • Amazon Aurora MySQL-Compatible Edition

  • Aurora Edição compatível com PostgreSQL

Criar tarefas de replicação bidirecional

Para habilitar a replicação bidirecional do AWS DMS, configure os endpoints de origem e de destino para os dois bancos de dados (A e B). Por exemplo, configure um endpoint de origem para o banco de dados A, um endpoint de origem para o banco de dados B, um endpoint de destino para o banco de dados A e um endpoint de destino para o banco de dados B.

Crie, então, duas tarefas: uma tarefa para a origem A mover dados para o destino B e outra para a origem B mover dados para o destino A. Além disso, verifique se cada tarefa está configurada com prevenção de loopback. Fazer isso impede que alterações idênticas sejam aplicadas aos destinos das duas tarefas, corrompendo os dados de, pelo menos, uma delas. Para obter mais informações, consulte Evitar loopback.

Para obter a abordagem mais fácil, comece com conjuntos de dados idênticos no banco de dados A e B. Crie duas tarefas somente CDC, uma tarefa para replicar dados de A para B e outra tarefa para replicar dados de B para A.

Para usar o AWS DMS para instanciar um novo conjunto de dados (banco de dados) no nó B, do nó A, faça o seguinte:

  1. Use uma tarefa CDC e carregamento completo para mover dados do banco de dados A para B. Certifique-se de que nenhum aplicativo esteja modificando dados no banco de dados B durante esse período.

  2. Quando o carregamento completo estiver concluído e antes que os aplicativos possam modificar dados no banco de dados B, observe o horário ou a posição inicial de CDC do banco de dados B. Para obter instruções, consulte Executar a replicação a partir de um ponto de início de CDC.

  3. Crie uma tarefa somente CDC que mova dados do banco de dados B de volta para A usando esse horário de início ou posição inicial de CDC.

nota

Apenas uma tarefa em um par bidirecional pode ser tanto carregamento total quanto CDC.

Evitar loopback

Para exibir o loopback de prevenção, vamos supor que em uma tarefa T1 o AWS DMS leia logs de alteração do banco de dados de origem A e aplique as alterações no banco de dados de destino B.

Em seguida, uma segunda tarefa, T2, lê os registros de alterações do banco de dados de origem B e os aplica de volta ao banco de dados de destino A. Antes que o T2 faça isso, o DMS deve garantir que as mesmas alterações feitas no banco de dados de destino B do banco de dados A não sejam feitas no banco de dados de origem A. Em outras palavras, o DMS deve garantir que essas alterações não sejam repetidas (repetidas) de volta ao banco de dados de destino A. Caso contrário, os dados no banco de dados A podem ser corrompidos.

Para evitar o loopback de alterações, adicione as seguintes configurações de tarefa a cada tarefa de replicação bidirecional. Isso garante que os dados de loopback não sejam corrompidos em nenhuma das direções.

{
. . .

  "LoopbackPreventionSettings": {
    "EnableLoopbackPrevention": Boolean,
    "SourceSchema": String,
    "TargetSchema": String
  },

. . .
}

As configurações de tarefa LoopbackPreventionSettings determinam se uma transação é nova ou um eco da tarefa de replicação oposta. Quando o AWS DMS aplica uma transação a um banco de dados de destino, ele atualiza uma tabela do DMS (awsdms_loopback_prevention) com uma indicação da alteração. Antes de aplicar cada transação a um destino, o DMS ignora qualquer transação que inclua referência a essa tabela awsdms_loopback_prevention. Portanto, ele não aplica a alteração.

Inclua essas configurações de tarefa com cada tarefa de replicação em um par bidirecional. Essas configurações habilitam a prevenção de loopback. Elas também especificam o esquema para cada banco de dados de origem e destino na tarefa que inclui a tabela awsdms_loopback_prevention para cada endpoint.

Para permitir que cada tarefa identifique esse eco e o descarte, defina EnableLoopbackPrevention como true. Para especificar um esquema na origem que inclua awsdms_loopback_prevention, defina SourceSchema para o nome desse esquema no banco de dados de origem. Para especificar um esquema no destino que inclua a mesma tabela, defina TargetSchema para o nome desse esquema no banco de dados de destino.

No exemplo a seguir, as configurações SourceSchema e TargetSchema para uma tarefa de replicação T1 e sua tarefa de replicação oposta T2 são especificadas com configurações opostas.

As configurações para a tarefa T1 são as seguintes.

{
. . .

  "LoopbackPreventionSettings": {
    "EnableLoopbackPrevention": true,
    "SourceSchema": "LOOP-DATA",
    "TargetSchema": "loop-data"
  },

. . .
}

As configurações para a tarefa oposta T2 são as seguintes.

{
. . .

  "LoopbackPreventionSettings": {
    "EnableLoopbackPrevention": true,
    "SourceSchema": "loop-data",
    "TargetSchema": "LOOP-DATA"
  },

. . .
}
nota

Ao usar a AWS CLI, use somente os comandos create-replication-task ou modify-replication-task para configurar LoopbackPreventionSettings em suas tarefas de replicações bidirecionais.

Limitações da replicação bidirecional

A replicação bidirecional para AWS DMS tem as seguintes limitações:

  • A prevenção de loopback rastreia apenas instruções de linguagem de manipulação de dados (DML). O AWS DMS não oferece suporte à prevenção de loopback da linguagem de definição de dados (DDL). Para fazer isso, configure uma das tarefas em um par bidirecional para filtrar instruções DDL.

  • As tarefas que usam prevenção de loopback não oferecem suporte à confirmação de alterações em lotes. Para configurar uma tarefa com prevenção de loopback, certifique-se de definir BatchApplyEnabled como false.

  • A replicação bidirecional do DMS não inclui detecção ou resolução de conflitos. Para detectar inconsistências de dados, use a validação de dados nas duas tarefas.