Usar a replicação lógica do PostgreSQL com o Aurora - Amazon Aurora
Configurar a replicação lógicaDesativar a replicação lógicaMonitorar o cache de gravação de replicação lógicaGerenciar slots lógicos Exemplo: usar a replicação lógica Exemplo: replicação lógica usando o Aurora PostgreSQL e o AWS DMS

Usar a replicação lógica do PostgreSQL com o Aurora

Ao usar o recurso de replicação lógica do PostgreSQL com seu cluster de banco de dados do Aurora PostgreSQL, você pode replicar e sincronizar tabelas individuais em vez de toda a instância do banco de dados. A replicação lógica usa um modelo de publicação e de assinatura para replicar as alterações de uma fonte para um ou mais destinatários. Ela funciona usando registros de alterações do log de gravação antecipada (WAL) do PostgreSQL. A fonte, ou o editor, envia os dados WAL das tabelas especificadas a um ou mais destinatários (assinante), replicando, dessa forma, as alterações e mantendo a tabela do assinante sincronizada com a tabela do editor. O conjunto de alterações do editor é identificado por meio de uma publicação. Os assinantes recebem as alterações criando uma assinatura que define a conexão com o banco de dados do editor e suas publicações. Um slot de replicação é o mecanismo utilizado nesse esquema para monitorar o andamento de uma assinatura.

Para clusters de banco de dados do Aurora PostgreSQL, os registros WAL são salvos no armazenamento do Aurora. O cluster de banco de dados do Aurora PostgreSQL que atua como editor em um cenário de replicação lógica lê os dados WAL do armazenamento do Aurora, os decodifica e os envia ao assinante para que as alterações possam ser aplicadas à tabela nessa instância. O editor usa um decodificador lógico para decodificar os dados a serem utilizados pelos assinantes. Por padrão, os clusters de banco de dados do Aurora PostgreSQL usam o plug-in pgoutput nativo do PostgreSQL ao enviar dados. Outros decodificadores lógicos estão disponíveis. Por exemplo, o Aurora PostgreSQL também é compatível com o plug-in wal2json que converte dados WAL em JSON.

A partir das versões 14.5, 13.8, 12.12 e 11.17 do Aurora PostgreSQL, o Aurora PostgreSQL incrementa o processo de replicação lógica do PostgreSQL com um cache de gravação para melhorar a performance. Os logs de transações do WAL são armazenados em cache localmente, em um buffer, para reduzir a quantidade de E/S do disco, ou seja, a leitura do armazenamento do Aurora durante a decodificação lógica. O cache de gravação é usado por padrão sempre que você usa a replicação lógica para o cluster de banco de dados do Aurora PostgreSQL. O Aurora fornece várias funções que você pode usar para gerenciar o cache. Para obter mais informações, consulte Gerenciar o cache de gravação de replicação lógica do Aurora PostgreSQL.

A replicação lógica é compatível com todas as versões do Aurora PostgreSQL atualmente disponíveis. Para obter informações, Amazon Aurora PostgreSQL updates (Atualizações do Amazon Aurora PostgreSQL) nas Release Notes for Aurora PostgreSQL (Notas de versão do Aurora PostgreSQL).

A replicação lógica é compatível com o Babelfish para Aurora PostgreSQL a partir das seguintes versões:

  • 15.7 e versões posteriores

  • 16.3 e versões posteriores

nota

Além do recurso nativo de replicação lógica do PostgreSQL introduzido no PostgreSQL 10, o Aurora PostgreSQL também é compatível com a extensão pglogical. Para ter mais informações, consulte Usar pglogical para sincronizar dados entre instâncias.

Para obter informações detalhadas sobre a replicação lógica do PostgreSQL, consulte Logical replication (Replicação lógica) e Logical decoding concepts (Conceitos da decodificação lógica) na documentação do PostgreSQL.

Nos tópicos a seguir, você pode encontrar informações sobre como configurar a replicação lógica entre clusters de banco de dados do Aurora PostgreSQL.

Configurar a replicação lógica para seu cluster de banco de dados do Aurora PostgreSQL

A configuração da replicação lógica exige privilégios rds_superuser. Seu cluster de banco de dados do Aurora PostgreSQL deve estar configurado para usar um grupo de parâmetros de cluster de banco de dados personalizado para que você possa definir os parâmetros necessários conforme detalhado no procedimento a seguir. Para obter mais informações, consulte Grupos de parâmetros do cluster de banco de dados para clusters de banco de dados do Amazon Aurora.

Como configurar a replicação lógica PostgreSQL para seu cluster de banco de dados do Aurora PostgreSQL

  1. Faça login no AWS Management Console e abra o console do Amazon RDS em https://console.aws.amazon.com/rds/.

  2. No painel de navegação, selecione seu cluster de banco de dados do Aurora PostgreSQL.

  3. Abra a guia Configuration (Configuração). Entre os detalhes da instância, encontre o link do Grupo de parâmetros com Grupo de parâmetros do cluster de banco de dados para Tipo.

  4. Clique no link para abrir os parâmetros personalizados associados ao seu cluster de banco de dados do Aurora PostgreSQL.

  5. No campo Parameters (Parâmetros), digite rds para encontrar o parâmetro rds.logical_replication. O valor padrão para esse parâmetro é 0, o que significa que ele está desativado por padrão.

  6. Selecione Edit parameters (Editar parâmetros) para acessar os valores das propriedades e depois selecione 1 no seletor para ativar o recurso. Dependendo do uso esperado, talvez você também precise alterar as configurações dos parâmetros a seguir. No entanto, em muitos casos, os valores padrão são suficientes.

    • max_replication_slots: defina esse parâmetro com um valor que seja pelo menos igual ao número total planejado de publicações e assinaturas de replicação lógica. Se você estiver usando AWS DMS, esse parâmetro deverá se igualar pelo menos às suas tarefas planejadas de captura de dados de alteração do cluster, além de publicações e assinaturas de replicação lógica.

    • max_wal_senders e max_logical_replication_workers: defina esses parâmetros como um valor pelo menos equivalente ao número de slots de replicação lógica que você planeja manter ativos ou ao número de tarefas AWS DMS ativas para a captura de dados de alterações. Deixar um slot de replicação lógica inativo evita que o vácuo remova tuplas obsoletas das tabelas. Por isso, recomendamos monitorar os slots de replicação e remover os inativos conforme necessário.

    • max_worker_processes: defina esse parâmetro com um valor que seja pelo menos igual ao total dos valores max_logical_replication_workers, autovacuum_max_workers e max_parallel_workers. Em classes de instância de banco de dados pequenas, os processos de operador em segundo plano podem afetar as workloads de aplicações. Por isso, monitore a performance do banco de dados se você definir max_worker_processes como maior do que o valor padrão. (O valor padrão é o resultado de GREATEST(${DBInstanceVCPU*2},8}, o que significa que, por padrão, isso é oito ou duas vezes o equivalente de CPU da classe da instância de banco de dados, o que for maior).

    nota

    Você pode modificar valores de parâmetros em um grupo de parâmetros de banco de dados criado pelo cliente, mas não pode alterar os valores dos parâmetros em um grupo de parâmetros de banco de dados padrão.

  7. Escolha Salvar alterações.

  8. Reinicialize a instância do gravador de seu cluster de banco de dados do Aurora PostgreSQL para que as alterações tenham efeito. No console do Amazon RDS, selecione a instância de banco de dados primária do cluster e selecione Reboot (Reinicializar) no menu Actions (Ações).

  9. Quando a instância estiver disponível, você poderá verificar se a replicação lógica está ativada da forma a seguir.

    1. Use o psql para se conectar à instância do gravador do cluster de banco de dados do Aurora PostgreSQL.

      psql --host=your-db-cluster-instance-1.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb

    2. Verifique se a replicação lógica foi habilitada usando o comando a seguir.

      labdb=> SHOW rds.logical_replication;
 rds.logical_replication
-------------------------
 on
(1 row)

    3. Verifique se o wal_level está definido como logical. 

      labdb=> SHOW wal_level;
  wal_level
-----------
 logical
(1 row)

Para ver um exemplo de como usar a replicação lógica para manter uma tabela de banco de dados sincronizada com as alterações de um cluster de banco de dados do Aurora PostgreSQL de origem, consulte Exemplo: usar a replicação lógica com clusters de banco de dados do Aurora PostgreSQL.

Desativar a replicação lógica

Depois de concluir suas tarefas de replicação, você deve interromper o processo de replicação, eliminar os slots de replicação e desativar a replicação lógica. Antes de descartar os slots, garanta que eles não sejam mais necessários. Os slots de replicação ativos não podem ser descartados.

Como desativar a replicação lógica

  1. Descarte todos os slots de replicação.

    Para descartar todos os slots de replicação, conecte-se ao editor e execute o comando SQL a seguir

    SELECT pg_drop_replication_slot(slot_name)
  FROM pg_replication_slots
 WHERE slot_name IN (SELECT slot_name FROM pg_replication_slots);

    Os slots de replicação não poderão estar ativos quando você executar esse comando.

  2. Modifique o grupo de parâmetros de cluster de banco de dados personalizado que está associado ao editor, conforme detalhado em Configurar a replicação lógica para seu cluster de banco de dados do Aurora PostgreSQL, mas defina o parâmetro rds.logical_replication como 0.

    Para obter mais informações sobre grupos de parâmetros personalizados, consulte Modificar parâmetros em um grupo de parâmetros do cluster de banco de dados no Amazon Aurora.

  3. Reinicie o cluster de banco de dados do Aurora PostgreSQL do editor para que a alteração no rds.logical_replication tenha efeito.

Gerenciar o cache de gravação de replicação lógica do Aurora PostgreSQL

Por padrão, as versões 14.5, 13.8, 12.12 e 11.17 e posteriores do Aurora PostgreSQL usam um cache de gravação para melhorar a performance da replicação lógica. Sem o cache de gravação, o Aurora PostgreSQL usa a camada de armazenamento do Aurora em sua implementação do processo nativo de replicação lógica do PostgreSQL. Ele faz isso gravando dados WAL no armazenamento e, depois, lendo os dados do armazenamento para decodificá-los e enviá-los (replicar) para seus destinos (assinantes). Isso pode causar gargalos durante a replicação lógica para clusters de banco de dados do Aurora PostgreSQL.

O cache de gravação reduz a necessidade de usar a camada de armazenamento do Aurora. Em vez de sempre gravar e ler da camada de armazenamento do Aurora, o Aurora PostgreSQL usa um buffer para armazenar em cache o fluxo lógico do WAL para que ele possa ser usado durante o processo de replicação, em vez de sempre extraí-lo do disco. Esse buffer é o cache nativo do PostgreSQL usado pela replicação lógica, identificado nos parâmetros do cluster de banco de dados do Aurora PostgreSQL como rds.logical_wal_cache. Por padrão, esse cache usa 1/32 da configuração de cache de buffer (shared_buffers) do cluster de banco de dados do Aurora PostgreSQL, mas não menos que 64 kB nem mais do que o tamanho de um segmento WAL, normalmente, 16 MB.

Ao usar a replicação lógica com seu cluster de banco de dados do Aurora PostgreSQL (para as versões que são compatíveis com o cache de gravação), você pode monitorar a taxa de acerto do cache para ver se ela está funcionando bem em seu caso de uso. Para fazer isso, conecte-se à instância de gravação do cluster de banco de dados do Aurora PostgreSQL usando psql e, depois, use a função do Aurora, aurora_stat_logical_wal_cache, conforme mostrado no exemplo a seguir.

SELECT * FROM aurora_stat_logical_wal_cache();

A função retorna o resultado a seguir.

name       | active_pid | cache_hit | cache_miss | blks_read | hit_rate | last_reset_timestamp
-----------+------------+-----------+------------+-----------+----------+--------------
test_slot1 | 79183      | 24        | 0          | 24        | 100.00%  | 2022-08-05 17:39...
test_slot2 |            | 1         | 0          |  1        | 100.00%  | 2022-08-05 17:34...
(2 rows)

Os valores last_reset_timestamp foram reduzidos para facilitar a leitura. Para ter mais informações sobre essa função, consulte aurora_stat_logical_wal_cache.

O Aurora PostgreSQL fornece as duas funções a seguir para monitorar o cache de gravação.

Se você achar que o tamanho do cache WAL ajustado automaticamente não é suficiente para suas workloads, você pode alterar o valor de rds.logical_wal_cache manualmente, modificando o parâmetro em seu grupo de parâmetros de cluster de banco de dados personalizado. Observe que qualquer valor positivo menor que 32 kB é tratado como 32 kB. Para obter mais informações sobre wal_buffers, consulte Write Ahead Log (Log write ahead) na documentação do PostgreSQL.

Gerenciar slots lógicos para o Aurora PostgreSQL

A atividade de streaming é capturada na visualização pg_replication_origin_status. Para ver o conteúdo dessa visualização, use a função pg_show_replication_origin_status(), conforme mostrado a seguir:

SELECT * FROM pg_show_replication_origin_status();

Você pode obter uma lista dos seus slots lógicos usando a consulta SQL a seguir.

SELECT * FROM pg_replication_slots;

Para descartar um slot lógico, use o pg_drop_replication_slot com o nome do slot, conforme mostrado no comando a seguir.

SELECT pg_drop_replication_slot('test_slot');

Exemplo: usar a replicação lógica com clusters de banco de dados do Aurora PostgreSQL

O procedimento a seguir mostra como iniciar a replicação lógica entre dois clusters de banco de dados do Aurora PostgreSQL. Tanto o editor quanto o assinante devem ser configurados para replicação lógica, conforme detalhado em Configurar a replicação lógica para seu cluster de banco de dados do Aurora PostgreSQL.

O cluster de banco de dados do Aurora PostgreSQL que é o editor designado também deve permitir o acesso ao slot de replicação. Para fazer isso, modifique o grupo de segurança associado à nuvem pública virtual (VPC) do cluster de banco de dados do Aurora PostgreSQL com base no serviço da Amazon VPC. Permita o acesso de entrada adicionando o grupo de segurança associado à VPC do assinante ao grupo de segurança do editor. Para obter mais informações, consulte Controle o tráfego para recursos usando grupos de segurança no Guia do usuário da Amazon VPC.

Com essas etapas preliminares concluídas, você pode usar os comandos do PostgreSQL CREATE PUBLICATION no editor e CREATE SUBSCRIPTION no assinante, conforme detalhado no procedimento a seguir.

Como iniciar o processo de replicação lógica entre dois clusters de banco de dados do Aurora PostgreSQL.

Essas etapas pressupõem que seus clusters de banco de dados do Aurora PostgreSQL tenham uma instância do gravador com um banco de dados para criar as tabelas de exemplo.

  1. No cluster de banco de dados do Aurora PostgreSQL do editor

    1. Crie uma tabela usando a declaração SQL a seguir.

      CREATE TABLE LogicalReplicationTest (a int PRIMARY KEY);

    2. Insira dados no banco de dados publisher usando a seguinte instrução SQL.

      INSERT INTO LogicalReplicationTest VALUES (generate_series(1,10000));

    3. Verifique se os dados existem na tabela usando a declaração SQL a seguir.

      SELECT count(*) FROM LogicalReplicationTest;

    4. Crie uma publicação para essa tabela usando a declaração CREATE PUBLICATION, conforme explicado a seguir.

      CREATE PUBLICATION testpub FOR TABLE LogicalReplicationTest;

  2. No cluster de banco de dados do Aurora PostgreSQL do assinante

    1. Crie a mesma tabela LogicalReplicationTest no assinante que você criou no editor, da forma a seguir.

      CREATE TABLE LogicalReplicationTest (a int PRIMARY KEY);

    2. Verifique se essa tabela está vazia.

      SELECT count(*) FROM LogicalReplicationTest;

    3. Crie uma assinatura para receber as alterações do editor. Você precisa usar os detalhes a seguir sobre o cluster de banco de dados do Aurora PostgreSQL do editor.

      • host: a instância de banco de dados do gravador do cluster de banco de dados do Aurora PostgreSQL do editor.

      • port: a porta na qual a instância de banco de dados do gravador está escutando. O padrão do PostgreSQL é 5432.

      • dbname: o nome do banco de dados.

      CREATE SUBSCRIPTION testsub CONNECTION 
   'host=publisher-cluster-writer-endpoint port=5432 dbname=db-name user=user password=password' 
   PUBLICATION testpub;
      nota

      Especifique uma senha diferente do prompt mostrado aqui como prática recomendada de segurança.

      Depois da criação da assinatura, um slot da replicação lógica é criado no publisher.

    4. Para verificar neste exemplo se os dados iniciais são replicados no assinante, use a seguinte instrução SQL no banco de dados assinante.

      SELECT count(*) FROM LogicalReplicationTest;

Todas as alterações adicionais no publisher são replicadas para o assinante.

A replicação lógica afeta a performance. Recomendamos que você desative a replicação lógica após a conclusão das tarefas de replicação.

Exemplo: replicação lógica usando o Aurora PostgreSQL e o AWS Database Migration Service

É possível usar o AWS Database Migration Service (AWS DMS) para replicar um banco de dados como uma parte de um banco de dados. Use o AWS DMS para migrar os dados de um banco de dados do Aurora PostgreSQL para outro banco de dados de código aberto ou comercial. Para obter mais informações sobre o AWS DMS, consulte o Guia do usuário do AWS Database Migration Service.

O exemplo a seguir mostra como configurar a replicação lógica de um banco de dados do Aurora PostgreSQL como publisher e usar o AWS DMS para migração. Este exemplo usa os mesmos publisher e assinante criados em Exemplo: usar a replicação lógica com clusters de banco de dados do Aurora PostgreSQL.

Para configurar a replicação lógica com o AWS DMS, são necessários os detalhes do publisher e do assinante no Amazon RDS. Especificamente, você precisa dos detalhes da instância de banco de dados do gravador do publisher e da instância de banco de dados do assinante.

Obtenha as seguintes informações da instância de banco de dados do gravador do publisher:

  • O identificador da nuvem privada virtual (VPC)

  • O grupo de sub-redes

  • A zona de disponibilidade (AZ)

  • O grupo de segurança da VPC

  • O ID da instância de banco de dados

Obtenha as seguintes informações da instância de banco de dados do assinante:

  • O ID da instância de banco de dados

  • O mecanismo de origem

Para usar o AWS DMS para a replicação lógica com o Aurora PostgreSQL

  1. Prepare o banco de dados publisher para trabalhar com o AWS DMS.

    Para isso, os bancos de dados PostgreSQL 10.x e posteriores exigem a aplicação de funções de wrapper do AWS DMS no banco de dados publisher. Para obter detalhes sobre isso e as etapas posteriores, consulte as instruções em Using PostgreSQL version 10.x and later as a source for AWS DMS (Usar PostgreSQL versão 10.x e posterior como origem para o DMS) no Guia do usuário do AWS Database Migration Service.

  2. Faça login no AWS Management Console e abra o console do AWS DMS em https://console.aws.amazon.com/dms/v2. Na parte superior direita, escolha a mesma região da AWS em que o publisher e o assinante estão localizados.

  3. Crie uma instância de replicação do AWS DMS.

    Escolha valores que sejam iguais aos da instância de banco de dados do gravador do publisher. Esses valores incluem as seguintes configurações:

    • Para VPC, escolha a mesma VPC da instância de banco de dados do gravador.

    • Para Replication Subnet Group (Grupo de sub-redes de replicação), escolha o mesmo grupo de sub-redes da instância de banco de dados de gravador. Crie um novo, se necessário.

    • Para Availability zone (Zona de disponibilidade), escolha a mesma zona da instância de banco de dados do gravador.

    • Para VPC Security Group (Grupo de segurança da VPC), escolha o mesmo grupo da instância de banco de dados do gravador.

  4. Crie um endpoint do AWS DMS para a origem.

    Especifique o publisher como o endpoint de origem usando as seguintes configurações:

    • Em Endpoint Type (Tipo de endpoint), escolha Source endpoint (Endpoint de origem).

    • Escolha Select RDS DB Instance (Selecionar instância de banco de dados RDS).

    • Em RDS Instance (Instância do RDS), escolha o identificador da instância de banco de dados do gravador do publisher.

    • Em Source engine (Mecanismo de origem), escolha postgres.

  5. Crie um endpoint do AWS DMS para o destino.

    Especifique o assinante como o endpoint de destino usando as seguintes configurações:

    • Em Endpoint Type (Tipo de endpoint), selecione Target endpoint (Endpoint de destino).

    • Escolha Select RDS DB Instance (Selecionar instância de banco de dados RDS).

    • Em RDS Instance (Instância do RDS), escolha o identificador da instância de banco de dados do gravador do assinante.

    • Escolha um valor para Source engine (Mecanismo de origem). Por exemplo, se o assinante for um banco de dados RDS para PostgreSQL, escolha postgres. Se o assinante for um banco de dados Aurora PostgreSQL, escolha aurora-postgresql.

  6. Crie uma tarefa de migração de banco de dados do AWS DMS.

    Você usa uma tarefa de migração de banco de dados para especificar as tabelas a serem migradas, mapear dados usando um esquema de destino e criar tabelas novas no banco de dados de destino. No mínimo, use as seguintes configurações para Task configuration (Configuração da tarefa):

    • Em Replication instance (Instância de replicação), escolha a instância de replicação criada em uma etapa anterior.

    • Em Source database endpoint (Endpoint do banco de dados de origem), escolha a origem do publisher criada em uma etapa anterior.

    • Em Target database endpoint (Endpoint do banco de dados de destino), escolha o destino do assinante criado em uma etapa anterior.

    O restante dos detalhes da tarefa dependem de seu projeto de migração. Para obter mais informações sobre como especificar todos os detalhes para tarefas do DMS, consulte o tópico sobre como Trabalhar com tarefas do AWS DMS, no Manual do usuário do AWS Database Migration Service.

Depois que o AWS DMS cria a tarefa, ele começa a migrar os dados do publisher para o assinante.