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

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

É possível criar uma tarefa do AWS DMS que capture as alterações em andamento no armazenamento de origem. É possível fazer essa captura enquanto migra seus dados. Também é possível criar uma tarefa que capture alterações em andamento depois de concluir a migração inicial (carga máxima) 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 utiliza esse processo ao replicar alterações em andamento de um armazenamento de dados de origem. Esse processo funciona coletando as alterações nos logs de banco de dados utilizando a API nativa do mecanismo de banco de dados.

nota

É possível migrar visualizações utilizando apenas tarefas de carga máxima. Se a tarefa for somente CDC ou uma tarefa de carga máxima que inicie a CDC após a conclusão, a migração incluirá apenas tabelas da origem. Usando uma tarefa somente de carga máxima, é possível migrar exibições ou uma combinação de tabelas e exibições. Para obter mais informações, consulte Especificar a seleção de tabelas e as regras de transformação utilizando 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 em a nível de linha (log binário).

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

Para o Oracle, o AWS DMS utiliza a API Oracle LogMiner ou a API do leitor binário (API bfile) para ler alterações em andamento. O AWS DMS faz a leitura de alterações em andamento a partir dos logs online ou redo de arquivamento com base no número de alterações do sistema (SCN).
Para o Microsoft SQL Server, o AWS DMS utiliza MS-Replication ou MS-CDC para gravar informações no log de transações do SQL Server. Ele utiliza o perfil fn_dblog() ou fn_dump_dblog() no SQL Server para ler as alterações no log de transações com base no número de sequência do log (LSN).
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 utiliza o plugin test_decoding para ler as alterações da origem e migrá-las para o destino.
Para o Amazon RDS como origem, é recomendável garantir que os backups estejam ativados para configurar a CDC. Também é recomendável garantir que o banco de dados de origem esteja configurado para reter os logs de alterações por um tempo suficiente, 24 horas geralmente é suficiente. Para obter as configurações específicas de cada endpoint, consulte o seguinte:
- Amazon RDS para Oracle: Configurando uma fonte Oracle AWS gerenciada para AWS DMS
- Amazon RDS para MySQL e Aurora MySQL: Utilizar um banco de dados compatível com MySQL gerenciado pela AWS como origem do AWS DMS.
- Amazon RDS para SQL Server: Configurar a replicação contínua em uma instância de banco de dados SQL Server na nuvem
- Amazon RDS para PostgreSQL e Aurora PostgreSQL: o PostgreSQL mantém automaticamente o WAL necessário.

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

Carga máxima mais CDC: a tarefa migra os dados existentes e atualiza o banco de dados de destino com base nas alterações do banco de dados de origem.
Somente CDC: a tarefa migra alterações em andamento depois que os dados estão no 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:

Em um horário de início de CDC personalizado: é possível utilizar a AWS CLI ou o AWS DMS com um timestamp em que você deseja que a replicação seja iniciada. O AWS DMS iniciará uma tarefa de replicação contínua a partir desse horário de início da CDC personalizada. O AWS DMS converterá o timestamp fornecido (em UTC) para um ponto de início nativo, como um LSN para SQL Server ou um SCN para Oracle. O AWS DMS usará 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 de conexão StartFromContext com o timestamp necessário, o Db2 como origem oferece um horário de início personalizado da CDC.
O PostgreSQL como origem não é compatível com um horário de início personalizado da CDC. 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.
Em um ponto de início nativo de CDC: também é possível iniciar em um ponto nativo no log de transações do mecanismo de origem. Em alguns casos, é possível preferir essa abordagem porque um timestamp pode indicar vários pontos nativos no log de transações. O AWS DMS é compatível com esse recurso para os seguintes endpoints de origem:
- SQL Server
- PostgreSQL
- Oracle
- MySQL
- MariaDB

Quando a tarefa é criada, o AWS DMS marca o ponto de início da CDC e não pode ser alterada. Para utilizar um ponto de início diferente da CDC, crie uma nova tarefa.

Determinar um ponto de início nativo de CDC

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

Os exemplos a seguir mostram como encontrar o ponto de início 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, utiliza o perfil fn_dblog() ou fn_dump_dblog() no SQL Server.

Para utilizar o ponto de início nativo da CDC com o SQL Server, crie uma publicação em qualquer tabela que participe da replicação contínua. O AWS DMS cria a publicação automaticamente quando você utiliza a CDC sem utilizar um ponto de início nativo da CDC.

PostgreSQL

Utilize um ponto de verificação de recuperação de CDC para o 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, consulte Utilizar um ponto de verificação como um ponto de início da CDC.

Para identificar o ponto de verificação a ser utilizado como ponto de início nativo, utilize a visualização pg_replication_slots do banco de dados ou os detalhes da visão geral da tarefa pai no AWS Management Console.

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

Faça login no AWS Management Console e abra o console do AWS DMS em https://console.aws.amazon.com/dms/v2/.

Se estiver conectado como usuário do IAM, verifique se você tem as permissões necessárias para acessar o AWS DMS. Para obter mais informações sobre as permissões necessárias, consulte Permissões do IAM necessárias para utilizar o AWS DMS.
No painel de navegação, escolha Tarefas de migração do banco de dados.
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.
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 de início nativo da CDC. Defina o parâmetro CdcStartPosition da API do DMS como esse valor ao criar a tarefa de CDC para iniciar a replicação neste ponto de início para a origem do PostgreSQL. Para obter informações sobre como utilizar a AWS CLI para criar a tarefa de CDC, consulte Ativar a CDC com uma instância de banco de dados PostgreSQL gerenciado pela AWS com o AWS DMS.

Oracle

Um número de alterações do sistema (SCN) é um timestamp interno e lógico utilizado 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 utilizam SCNs para marcar o local em que 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 utiliza SCNs para marcar o ponto em que não existem redos para um conjunto de dados, para que a recuperação possa ser interrompida.

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


SELECT CURRENT_SCN FROM V$DATABASE

Se você utilizar o SCN ou o timestamp para iniciar uma tarefa de CDC, perderá os resultados de qualquer transação aberta e haverá falha na migração. Transações abertas são transações que foram iniciadas antes da posição de início da tarefa e confirmadas após a posição de início da tarefa. É possível identificar o SCN e o timestamp 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 do Oracle. Com a versão 3.5.1 e superior, o AWS DMS é compatível com transações abertas para uma tarefa somente de CDC utilizando a configuração openTransactionWindow do endpoint se você utilizar o SCN ou o timestamp para iniciar a tarefa.

Ao utilizar a configuração openTransactionWindow, forneça a janela, em número de minutos, para tratar as transações abertas. O AWS DMS muda a posição de captura e encontra a nova posição para iniciar a captura de dados. O AWS DMS utiliza a nova posição de início para verificar todas as transações abertas dos redos necessários do Oracle ou dos redo logs arquivados.

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. As aplicações criadas no MySQL 5.6.3 ou superior que utilizam valores de LSN devem utilizar 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 o 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.

Utilizar um ponto de verificação como um ponto de início da 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. É possível utilizar o ponto de verificação para voltar no cronograma de alterações e recuperar uma tarefa de migração com falha. Também é possível utilizar um ponto de verificação para iniciar outra tarefa de replicação contínua para outro destino em qualquer ponto determinado no tempo.

É possível obter as informações do ponto de verificação de uma das seguintes formas:

Execute a operação da API DescribeReplicationTasks e visualize os resultados. É possível filtrar as informações por tarefa e pesquisar o ponto de verificação. É possível 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. É possível 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 a tarefa pai na lista que aparece na página Tarefas de migração de banco de dados. A página da tarefa pai é 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 nativos de CDC, 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

É possível modificar uma tarefa e definir uma hora em UTC para interrompê-la, conforme necessário. A tarefa é interrompida automaticamente com base no tempo da confirmação ou do servidor definido. Ou, se você souber um tempo adequada 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.

nota

Pode demorar até 40 minutos para inicializar todos os recursos na primeira vez que você inicia uma nova replicação do AWS DMS com Tecnologia Sem Servidor. Observe que a opção server_time só é aplicável após a conclusão da inicialização do recurso.

Executar replicação bidirecional

É possível utilizar 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, é possível copiar uma tabela EMPLOYEE do banco de dados A para o banco de dados B e replicar as alterações na tabela do banco de dados A para o banco de dados B. Também é possível 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.

Utilize 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.

O AWS DMS é compatível com a replicação bidirecional nos seguintes mecanismos de banco de dados:

Oracle
SQL Server
MySQL
PostgreSQL
Amazon Aurora Edição compatível com MySQL
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 utilizar o AWS DMS para instanciar um novo conjunto de dados (banco de dados) no nó B, do nó A, faça o seguinte:

Utilize uma tarefa de carga máxima e CDC para mover dados do banco de dados A para B. Verifique se nenhuma aplicação esteja modificando dados no banco de dados B durante esse período.
Quando a carga máxima estiver concluída e antes que as aplicações possam modificar os dados no banco de dados B, observe o horário ou a posição de início da 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.
Crie uma tarefa somente CDC que mova dados do banco de dados B de volta para A utilizando esse horário de início ou posição inicial de CDC.

nota

Apenas uma tarefa em um par bidirecional pode ser tanto carga máxima 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.

Uma segunda tarefa, T2, lê logs de alterações do banco de dados de origem B e aplica-as de volta no banco de dados de destino A. Antes que a T2 faça isso, o DMS deve verificar se as mesmas alterações feitas no banco de dados de destino B a partir do banco de dados de origem A não sejam feitas no banco de dados de origem A. Em outras palavras, o DMS deve verificar se essas alterações não são ecoadas (looped) de volta para o banco de dados de destino A. Caso contrário, os dados no banco de dados A poderão 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 utilizar a AWS CLI, utilize 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 é compatível com a 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 utilizam prevenção de loopback não são compatíveis com a confirmação de alterações em lote. Para configurar uma tarefa com prevenção de loopback, defina 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, utilize a validação de dados nas duas tarefas.

Atenção O Javascript está desativado ou não está disponível no seu navegador.

Para usar a documentação da AWS, o Javascript deve estar ativado. Consulte as páginas de Ajuda do navegador para obter instruções.

Convenções do documento

Criar várias tarefas

Modificar uma tarefa