# Replicação com Amazon Aurora PostgreSQL
A seguir, você recebe informações sobre replicação com o Amazon Aurora PostgreSQL, que incluem como monitorar e usar a replicação lógica.
**Topics**
+ [Usar réplicas do Aurora](#AuroraPostgreSQL.Replication.Replicas)
+ [Melhorar a disponibilidade de leitura das réplicas do Aurora](#AuroraPostgreSQL.Replication.Replicas.SRO)
+ [Monitorar a replicação do Aurora PostgreSQL](#AuroraPostgreSQL.Replication.Monitoring)
+ [Visão geral da replicação lógica do PostgreSQL com o Aurora](AuroraPostgreSQL.Replication.Logical.md)
+ [Configurar a replicação lógica para seu cluster de banco de dados do Aurora PostgreSQL](AuroraPostgreSQL.Replication.Logical.Configure.md)
+ [Desativar a replicação lógica](AuroraPostgreSQL.Replication.Logical.Stop.md)
+ [Monitorar o cache de gravação simultânea e os slots lógicos para a replicação lógica do Aurora PostgreSQL](AuroraPostgreSQL.Replication.Logical-monitoring.md)
+ [Exemplo: usar a replicação lógica com clusters de banco de dados do Aurora PostgreSQL](AuroraPostgreSQL.Replication.Logical.PostgreSQL-Example.md)
+ [Exemplo: replicação lógica usando o Aurora PostgreSQL e o AWS Database Migration Service](AuroraPostgreSQL.Replication.Logical.DMS-Example.md)
+ [Configurar a autenticação do IAM para conexões de replicação lógica](AuroraPostgreSQL.Replication.Logical.IAM-auth.md)
## Usar réplicas do Aurora
Uma *Aurora réplica* é um endpoint independente em um cluster de banco de dados do Aurora, cuja melhor utilidade é dimensionar operações de leitura e aumentar a disponibilidade. Um cluster de banco de dados do Aurora pode incluir até réplicas de 15 Aurora localizadas nas zonas de disponibilidade da região da AWS do cluster de banco de dados do Aurora.
O volume do cluster de banco de dados é composto por várias cópias dos dados do cluster de banco de dados. Contudo, os dados no volume do cluster são representados como um volume lógico, único, para a instância de banco de dados do gravador principal e para réplicas do Aurora no cluster de banco de dados. Para mais informações sobre réplicas do Aurora, consulte [Réplicas do Aurora](Aurora.Replication.md#Aurora.Replication.Replicas).
As réplicas do Aurora funcionam bem para a escalabilidade de leitura porque são totalmente dedicadas a operações de leitura em seu volume de cluster. A instância de banco de dados do gravador grava operações. O volume do cluster é compartilhado com todas as instâncias em seu cluster de banco de dados Aurora PostgreSQL. Assim, nenhum trabalho extra é necessário para replicar uma cópia dos dados para cada réplica do Aurora.
Com o Aurora PostgreSQL, quando a réplica do Aurora é excluída, o endpoint da instância é removido imediatamente, e a réplica do Aurora é removida do endpoint leitor. Se houver instruções em execução na réplica do Aurora que está sendo excluída, haverá um período de carência de três minutos. As instruções existentes podem ser concluídas durante o período de carência. Quando o período de carência termina, a réplica do Aurora é fechada e excluída.
Os clusters de banco de dados do Aurora PostgreSQL são compatíveis com réplicas do Aurora em diferentes regiões da AWS, usando o banco de dados global do Aurora. Para obter mais informações, consulte [Usar o Amazon Aurora Global Database](aurora-global-database.md).
**nota**
Com o atributo de disponibilidade de leitura, se você quiser reinicializar as réplicas do Aurora no cluster de banco de dados, terá que fazê-lo manualmente. Para os clusters de banco de dados criados antes desse recurso, a reinicialização da instância de banco de dados do gravador reinicializa automaticamente as réplicas do Aurora. A reinicialização automática restabelece um ponto de entrada que garante a consistência de leitura/gravação no cluster de banco de dados.
## Melhorar a disponibilidade de leitura das réplicas do Aurora
O Aurora PostgreSQL melhora a disponibilidade de leitura no cluster de banco de dados atendendo continuamente às solicitações de leitura quando a instância de banco de dados do gravador é reiniciada ou quando a réplica do Aurora não consegue acompanhar o tráfego de gravação.
O recurso de disponibilidade de leitura está disponível por padrão nas seguintes versões do Aurora PostgreSQL:
+ 16.1 e todas as versões posteriores
+ Versão 15.2 e versões 15 posteriores
+ Versão 14.7 e versões 14 posteriores
+ Versão 13.10 e versões 13 posteriores
+ Versão 12.14 e versões 12 posteriores
O recurso de disponibilidade de leitura é compatível com as seguintes versões do banco de dados do Aurora:
+ 16.1 e todas as versões posteriores
+ 15.4 e versões 15 posteriores
+ 14.9 e versões 14 posteriores
+ 13.12 e versões 13 posteriores
+ 12.16 e versões 12 posteriores
Para usar o recurso de disponibilidade de leitura para um cluster de banco de dados criado em uma dessas versões antes desse lançamento, reinicie a instância do gravador do cluster de banco de dados.
Ao modificar parâmetros estáticos do cluster de banco de dados do Aurora PostgreSQL, é necessário reiniciar a instância do gravador para que as alterações entrem em vigor. Por exemplo, é necessário reiniciar a instância do gravador ao definir o valor de `shared_buffers`. Com o recurso de disponibilidade de leitura das réplicas do Aurora, o cluster de banco de dados mantém a disponibilidade aprimorada, o que reduz o impacto nelas quando a instância do gravador é reiniciada. As instâncias do leitor não são reiniciadas e continuam respondendo às solicitações de leitura. Para aplicar alterações de parâmetros estáticos, reinicialize cada instância individual do leitor.
A réplica do Aurora de um cluster de banco de dados do Aurora PostgreSQL pode se recuperar de erros de replicação, como reinicializações do gravador, failover, replicação lenta e problemas de rede, recuperando-se rapidamente para o estado do banco de dados na memória após a reconexão com o gravador. Essa abordagem permite que as instâncias de réplica do Aurora alcancem a consistência com as atualizações de armazenamento mais recentes enquanto o banco de dados do cliente ainda está disponível.
As transações em andamento que entram em conflito com a recuperação da replicação podem receber um erro, mas o cliente pode repetir essas transações depois que os leitores acompanharem o gravador.
### Monitorar réplicas do Aurora
É possível monitorar as réplicas do Aurora ao se recuperar de uma desconexão do gravador. Use as métricas abaixo para verificar as informações mais recentes sobre a instância do leitor e rastrear transações em andamento somente leitura.
+ A função `aurora_replica_status` é atualizada para retornar as informações mais atualizadas para a instância do leitor quando ela ainda está conectada. O carimbo de data/hora da última atualização no `aurora_replica_status` está sempre vazio para a linha correspondente à instância de banco de dados na qual a consulta é executada. Isso indica que a instância do leitor tem os dados mais recentes.
+ Quando a réplica do Aurora se desconecta da instância do gravador e se reconecta, o seguinte evento do banco de dados é emitido:
`Read replica has been disconnected from the writer instance and reconnected.`
+ Quando uma consulta somente leitura é cancelada devido a um conflito de recuperação, você pode ver uma ou mais das seguintes mensagens de erro no log de erros do banco de dados:
`Canceling statement due to conflict with recovery`.
`User query may not have access to page data to replica disconnect.`
`User query might have tried to access a file that no longer exists.`
`When the replica reconnects, you will be able to repeat your command.`
### Limitações
As seguintes limitações aplicam-se às réplicas do Aurora com o recurso de disponibilidade de leitura:
+ As réplicas do Aurora do cluster de banco de dados secundário poderão ser reiniciadas se os dados não puderem ser transmitidos da instância de gravador durante a recuperação da replicação.
+ As réplicas do Aurora não serão compatíveis com a recuperação de replicação on-line se uma já estiver em andamento e for reiniciada.
+ As réplicas do Aurora serão reiniciadas quando sua instância de banco de dados estiver próxima da conclusão do ID da transação. Para obter mais informações sobre a conclusão de ID de transação, consulte [Evitar falhas de conclusão de ID de transação](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND ).
+ As réplicas do Aurora podem ser reiniciadas quando o processo de replicação é bloqueado em determinadas circunstâncias.
## Monitorar a replicação do Aurora PostgreSQL
A escalabilidade de leitura e a alta disponibilidade dependem de um tempo de atraso mínimo. Você pode monitorar até que ponto uma réplica do Aurora está atrasada em relação à instância de banco de dados do gravador do cluster de banco de dados do Aurora PostgreSQL monitorando a métrica `ReplicaLag` do Amazon CloudWatch. Como as réplicas do Aurora leem no mesmo volume do cluster que a instância de banco de dados do gravador, a métrica `ReplicaLag` tem um significado diferente para um cluster de banco de dados do Aurora PostgreSQL. A métrica `ReplicaLag` de uma réplica do Aurora indica o atraso do cache da página da réplica do Aurora em comparação com o da instância de banco de dados do gravador.
Para obter mais informações sobre como monitorar as instâncias do RDS e as métricas do CloudWatch, consulte [Monitorar métricas em um cluster do Amazon Aurora](MonitoringAurora.md).
# Visão geral da 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](https://github.com/eulerto/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 [Monitorar o cache de gravação simultânea de replicação lógica do Aurora PostgreSQL](AuroraPostgreSQL.Replication.Logical-monitoring.md#AuroraPostgreSQL.Replication.Logical-write-through-cache).
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](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html) (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 obter mais informações, consulte [Usar pglogical para sincronizar dados entre instâncias](Appendix.PostgreSQL.CommonDBATasks.pglogical.md).
Para obter informações detalhadas sobre a replicação lógica do PostgreSQL, consulte [Logical replication](https://www.postgresql.org/docs/current/logical-replication.html) (Replicação lógica) e [Logical decoding concepts](https://www.postgresql.org/docs/current/logicaldecoding-explanation.html) (Conceitos da decodificação lógica) na documentação do PostgreSQL.
**nota**
O PostgreSQL 16 adicionou suporte para decodificação lógica por meio de réplicas de leitura. Esse recurso não é aceito no 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](USER_WorkingWithDBClusterParamGroups.md).
**Como configurar a replicação lógica PostgreSQL para seu cluster de banco de dados do Aurora PostgreSQL**
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. No painel de navegação, selecione seu cluster de banco de dados do Aurora PostgreSQL.
1. 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**.
1. Clique no link para abrir os parâmetros personalizados associados ao seu cluster de banco de dados do Aurora PostgreSQL.
1. 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.
1. 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.
1. Escolha **Salvar alterações**.
1. 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).
1. 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
```
1. 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)
```
1. 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](AuroraPostgreSQL.Replication.Logical.PostgreSQL-Example.md).
# 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.
1. 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](AuroraPostgreSQL.Replication.Logical.Configure.md), 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 de cluster de banco de dadosno Amazon Aurora](USER_WorkingWithParamGroups.ModifyingCluster.md).
1. Reinicie o cluster de banco de dados do Aurora PostgreSQL do editor para que a alteração no `rds.logical_replication` tenha efeito.
# Monitorar o cache de gravação simultânea e os slots lógicos para a replicação lógica do Aurora PostgreSQL
Monitore o cache de gravação simultânea de replicação lógica e gerencie slots lógicos para melhorar a performance do cluster de banco de dados do Aurora PostgreSQL. A seguir, encontre mais informações sobre o cache de gravação simultânea e os slots lógicos.
**Topics**
+ [Monitorar o cache de gravação simultânea de replicação lógica do Aurora PostgreSQL](#AuroraPostgreSQL.Replication.Logical-write-through-cache)
+ [Gerenciar slots lógicos para o Aurora PostgreSQL](#AuroraPostgreSQL.Replication.Logical.Configure.managing-logical-slots)
## Monitorar o cache de gravação simultânea 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 simultânea minimiza a dependência da camada de armazenamento do Aurora. Em vez de gravar e ler dessa camada de maneira consistente, o Aurora PostgreSQL usa um buffer para armazenar em cache o fluxo lógico do WAL para uso durante o processo de replicação, reduzindo a necessidade de acessar o disco. Esse buffer é o cache nativo do PostgreSQL usado na replicação lógica e é identificado nos parâmetros do cluster de banco de dados do Aurora PostgreSQL como `rds.logical_wal_cache`.
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\$1stat\$1logical\$1wal\$1cache](aurora_stat_logical_wal_cache.md).
O Aurora PostgreSQL fornece as duas funções a seguir para monitorar o cache de gravação.
+ A função `aurora_stat_logical_wal_cache`: para obter a documentação de referência, consulte [aurora\$1stat\$1logical\$1wal\$1cache](aurora_stat_logical_wal_cache.md).
+ A função `aurora_stat_reset_wal_cache`: para obter a documentação de referência, consulte [aurora\$1stat\$1reset\$1wal\$1cache](aurora_stat_reset_wal_cache.md).
Se você achar que o tamanho do cache do WAL ajustado automaticamente não é suficiente para as workloads, altere o valor de `rds.logical_wal_cache` manualmente. Considere o seguinte:
+ Quando o parâmetro `rds.logical_replication` está desabilitado, `rds.logical_wal_cache` é definido como zero (0).
+ Quando o parâmetro `rds.logical_replication` está habilitado, `rds.logical_wal_cache` tem um valor padrão de 16 MB.
+ O parâmetro `rds.logical_wal_cache` é estático e requer a reinicialização da instância de banco de dados para que as alterações sejam aplicadas. Esse parâmetro é definido em termos de blocos de 8 Kb. Observe que qualquer valor positivo menor que 32 Kb é tratado como 32 Kb. Para ter mais informações sobre `wal_buffers`, consulte [Write Ahead Log](https://www.postgresql.org/docs/current/runtime-config-wal.html#RUNTIME-CONFIG-WAL-SETTINGS) 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](AuroraPostgreSQL.Replication.Logical.Configure.md).
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](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) 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);
```
1. Insira dados no banco de dados publisher usando a seguinte instrução SQL.
```
INSERT INTO LogicalReplicationTest VALUES (generate_series(1,10000));
```
1. Verifique se os dados existem na tabela usando a declaração SQL a seguir.
```
SELECT count(*) FROM LogicalReplicationTest;
```
1. Crie uma publicação para essa tabela usando a declaração `CREATE PUBLICATION`, conforme explicado a seguir.
```
CREATE PUBLICATION testpub FOR TABLE LogicalReplicationTest;
```
1. **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);
```
1. Verifique se essa tabela está vazia.
```
SELECT count(*) FROM LogicalReplicationTest;
```
1. 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.
1. 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 [Manual do usuário do AWS Database Migration Service](https://docs.aws.amazon.com/dms/latest/userguide/).
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](AuroraPostgreSQL.Replication.Logical.PostgreSQL-Example.md).
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](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.PostgreSQL.html#CHAP_Source.PostgreSQL.v10) (Usar PostgreSQL versão 10.x e posterior como origem para o DMS) no *Manual do usuário do AWS Database Migration Service.*
1. Faça login no Console de gerenciamento da AWS e abra o console do AWS DMS em [https://console.aws.amazon.com/dms/v2](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.
1. 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.
1. 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**.
1. 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**.
1. 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](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Tasks.html), 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.
# Configurar a autenticação do IAM para conexões de replicação lógica
A partir das versões 11 e posterior do Aurora PostgreSQL, você pode usar a autenticação do AWS Identity and Access Management (IAM) para conexões de replicação. Esse recurso aprimora a segurança ao permitir que você gerencie o acesso ao banco de dados usando perfis do IAM em vez de senhas. Ele funciona em nível de cluster e segue o mesmo modelo de segurança da autenticação padrão do IAM.
A autenticação do IAM para conexões de replicação é um atributo opcional. Para habilitá-lo, defina o parâmetro `rds.iam_auth_for_replication` como `1` no seu grupo de parâmetros do cluster de banco de dados. Como esse é um parâmetro dinâmico, seu cluster de banco de dados não precisa ser reiniciado, permitindo que você aproveite a autenticação do IAM com workloads existentes sem tempo de inatividade. Antes de habilitar esse atributo, você deve atender aos [Pré-requisitos](#AuroraPostgreSQL.Replication.Logical.IAM-auth-prerequisites) listados abaixo.
## Pré-requisitos
Para usar a autenticação do IAM para conexões de replicação, você precisa cumprir todos os requisitos abaixo:
+ Seu cluster de banco de dados do Aurora PostgreSQL deve ser da versão 11 ou posterior.
+ No cluster de banco de dados do Aurora PostgreSQL do publicador:
+ Habilite a autenticação do banco de dados do IAM.
Para obter mais informações, consulte [Habilitar e desabilitar a autenticação de banco de dados do IAM](UsingWithRDS.IAMDBAuth.Enabling.md).
+ Habilite a replicação lógica definindo o parâmetro `rds.logical_replication` como `1`.
Para obter mais informações, consulte [Configurar a replicação lógica para seu cluster de banco de dados do Aurora PostgreSQL](AuroraPostgreSQL.Replication.Logical.Configure.md).
Na replicação lógica, o publicador é o cluster de banco de dados do Aurora PostgreSQL de origem que envia dados aos clusters de assinantes. Para acessar mais informações, consulte [Visão geral da replicação lógica do PostgreSQL com o Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Replication.Logical.html).
**nota**
Tanto a autenticação do IAM quanto a replicação lógica devem estar habilitadas no cluster de banco de dados do Aurora PostgreSQL do publicador. Se nenhuma delas estiver habilitada, você não poderá usar a autenticação do IAM para conexões de replicação.
## Habilitar a autenticação do IAM para conexões de replicação
Conclua as etapas a seguir para habilitar a autenticação do IAM para a conexão de replicação.
1. Verifique se seu cluster de banco de dados do Aurora PostgreSQL atende a todos os pré-requisitos para autenticação do IAM com conexões de replicação. Para obter detalhes, consulte [Pré-requisitos](#AuroraPostgreSQL.Replication.Logical.IAM-auth-prerequisites).
1. Configure o parâmetro `rds.iam_auth_for_replication` modificando o grupo de parâmetros do cluster de banco de dados:
+ Defina o parâmetro `rds.iam_auth_for_replication` como `1`. Esse parâmetro dinâmico não exige reinicialização.
1. Conecte-se ao seu banco de dados e conceda os perfis necessários ao seu usuário de replicação:
Os comandos SQL a seguir concedem os perfis necessários para habilitar a autenticação do IAM para conexões de replicação:
```
-- Grant IAM authentication role
GRANT rds_iam TO replication_user_name;
-- Grant replication privileges
ALTER USER replication_user_name WITH REPLICATION;
```
Depois de concluir essas etapas, o usuário especificado deve usar a autenticação do IAM para conexões de replicação.
**Importante**
Quando você habilita o recurso, os usuários com os perfis `rds_iam` e `rds_replication` devem usar a autenticação do IAM para conexões de replicação. Isso se aplicará se os perfis forem atribuídos diretamente ao usuário ou herdados por meio de outros perfis.
## Desabilitar a autenticação do IAM para conexões de replicação
Você pode desabilitar a autenticação do IAM para conexões de replicação usando qualquer um dos seguintes métodos:
+ Defina o parâmetro `rds.iam_auth_for_replication` para `0` no grupo de parâmetros do cluster do banco de dados.
+ Você também pode desabilitar qualquer um desses recursos em seu cluster de banco de dados do Aurora PostgreSQL:
+ Desabilitar a replicação lógica definindo o parâmetro `rds.logical_replication` como `0`
+ Desabilitar a autenticação do IAM
Quando você desabilita o recurso, as conexões de replicação podem usar senhas de banco de dados para autenticação, se configuradas.
**nota**
As conexões de replicação para usuários sem o perfil `rds_iam` podem usar a autenticação por senha mesmo quando o recurso está habilitado.
## Limitações e considerações
As limitações e as considerações se aplicam quando você usa a autenticação do IAM para conexões de replicação.
+ A autenticação do IAM para conexões de replicação está disponível somente para as versões 11 e posterior do Aurora PostgreSQL.
+ O publicador deve oferecer suporte à autenticação do IAM para conexões de replicação.
+ Por padrão, o token de autenticação do IAM expira após 15 minutos. Talvez seja necessário atualizar as conexões de replicação de longa duração antes que o token expire.