# Trabalhar com réplicas de leitura do Amazon RDS para PostgreSQL
É possível escalar as leituras da instância de banco de dados do Amazon RDS para PostgreSQL adicionando réplicas de leitura à instância. Assim como acontece com outros mecanismos de banco de dados do Amazon RDS, o RDS para PostgreSQL usa os mecanismos de replicação nativos do PostgreSQL para manter as réplicas de leitura atualizadas com as alterações no banco de dados de origem. Para obter informações gerais sobre as réplicas de leitura e o Amazon RDS, consulte [Trabalhar com réplicas de leitura de instância de banco de dados](USER_ReadRepl.md).
A seguir, você pode encontrar informações específicas sobre como trabalhar com réplicas de leitura com o RDS para PostgreSQL.
## Limitações de réplicas de leitura com o PostgreSQL
As limitações de réplicas de leitura do PostgreSQL são as seguintes:
+ As réplicas de leitura do PostgreSQL são somente leitura. Embora uma réplica de leitura não seja uma instância de banco de dados gravável, é possível promovê-la para se tornar uma instância de banco de dados do RDS para PostgreSQL autônoma. No entanto, o processo é irreversível.
+ Não será possível criar uma réplica de leitura de outra réplica de leitura se a instância de banco de dados do RDS para PostgreSQL estiver executando uma versão do PostgreSQL anterior à 14.1. O RDS para PostgreSQL é compatível com réplicas de leitura em cascata somente no RDS para PostgreSQL versão 14.1 e versões superiores. Para obter mais informações, consulte [Usar réplicas de leitura em cascata com o RDS para PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Cascading.md).
+ Se você promover uma réplica de leitura do PostgreSQL, ela se tornará uma instância de banco de dados gravável. Ela deixa de receber arquivos de log de gravação antecipada (WAL) de uma instância de banco de dados de origem e não é mais uma instância somente leitura. É possível criar réplicas de leitura da instância de banco de dados promovida da mesma forma como você faz para qualquer instância de banco de dados do RDS para PostgreSQL. Para obter mais informações, consulte [Promoção de uma réplica de leitura a uma instância de banco de dados autônoma](USER_ReadRepl.Promote.md).
+ Se você promover uma réplica de leitura do PostgreSQL de dentro de uma cadeia de replicação (uma série de réplicas de leitura em cascata), todas as réplicas de leitura posteriores existentes continuarão recebendo arquivos WAL da instância promovida, automaticamente. Para obter mais informações, consulte [Usar réplicas de leitura em cascata com o RDS para PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Cascading.md).
+ A réplica de leitura do PostgreSQL associada mostrará um atraso de replicação de até 5 minutos se não houver nenhuma transação de usuário em execução na instância do banco de dados de origem. O atraso da réplica é calculado como `currentTime - lastCommitedTransactionTimestamp`, o que significa que quando nenhuma transação está sendo processada, o valor do atraso da réplica aumenta por um período até que o segmento do log de gravação antecipada (WAL) mude. Por padrão, o RDS para PostgreSQL alterna o segmento do WAL a cada 5 minutos, o que resulta em um registro de transação e uma diminuição no atraso relatado.
+ Não é possível ativar backups automatizados de réplicas de leitura do PostgreSQL de versões do RDS para PostgreSQL anteriores à 14.1. Os backups automatizados de réplicas de leitura são compatíveis apenas com o RDS para PostgreSQL 14.1 e versões superiores. Para o RDS para PostgreSQL 13 e versões anteriores, crie um instantâneo de uma réplica de leitura para criar um backup dele.
+ A recuperação a um ponto anterior no tempo (PITR) não é compatível com réplicas de leitura. Você pode usar PITR somente com uma instância primária (gravadora), não com uma réplica de leitura. Para saber mais, consulte [Restaurar uma instância de banco de dados para um momento especificado no Amazon RDS](USER_PIT.md).
+ As réplicas de leitura para PostgreSQL versões 12 e anteriores são reiniciadas automaticamente durante a janela de manutenção de 60 a 90 dias para aplicar a rotação de senhas. Se a réplica perder a conexão com a origem antes da reinicialização programada, ela ainda será reinicializada para retomar a replicação. Para as versões 13 e posteriores do PostgreSQL, as réplicas de leitura podem sofrer breves desconexões e reconexões de replicação durante o processo de rotação de senhas.
# Configuração de réplica de leitura com o PostgreSQL
O RDS para PostgreSQL usa a replicação de streaming nativo do PostgreSQL para criar uma cópia somente leitura de uma instância de banco de dados de origem. Essa instância de banco de dados da réplica de leitura é uma replicação física criada assincronamente da instância de banco de dados de origem. Ela é criada por uma conexão especial que transmite dados de log de gravação antecipada (WAL) da instância de banco de dados de origem e a réplica de leitura. Para obter mais informações, consulte [Streaming Replication](https://www.postgresql.org/docs/14/warm-standby.html#STREAMING-REPLICATION) (Replicação em streaming) na documentação do PostgreSQL.
O PostgreSQL faz streaming de forma assíncrona das alterações do banco de dados para essa conexão segura conforme são feitas na instância de banco de dados de origem. É possível criptografar comunicações de aplicações de clientes com a instância de banco de dados de origem ou qualquer réplica de leitura definindo o parâmetro `ssl` como `1`. Para obter mais informações, consulte [Usar o SSL com uma instância de banco de dados PostgreSQL](PostgreSQL.Concepts.General.SSL.md) .
O PostgreSQL usa um perfil de *replicação* para realizar a replicação em streaming. O perfil é privilegiado, mas não pode ser usado para modificar nenhum dado. O PostgreSQL usa um processo único para gerenciar a replicação.
É possível criar uma réplica de leitura do PostgreSQL sem afetar as operações ou os usuários da instância de banco de dados de origem. O Amazon RDS define os parâmetros e as permissões necessários na instância de banco de dados de origem e na réplica de leitura sem afetar o serviço. Um snapshot é criado da instância de banco de dados de origem, e esse snapshot é usado para criar a réplica de leitura. Se você excluir a réplica de leitura em algum momento futuro, não ocorrerá nenhuma interrupção.
Você pode criar até quinze réplicas de leitura de uma instância de banco de dados de origem na mesma região. Desde o RDS para PostgreSQL 14.1, também é possível criar até três níveis de réplica de leitura em uma cadeia (cascata) de uma instância de banco de dados de origem. Para obter mais informações, consulte [Usar réplicas de leitura em cascata com o RDS para PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Cascading.md). Em todos os casos, a instância de banco de dados de origem precisa ter backups automatizados configurados. Faça isso definindo o período de retenção do backup na instância de banco de dados como qualquer valor diferente de 0. Para obter mais informações, consulte [Como criar uma réplica de leitura](USER_ReadRepl.Create.md).
É possível criar réplicas de leitura para a instância de banco de dados do RDS para PostgreSQL na mesma Região da AWS que a instância de banco de dados de origem. Isso é conhecido como replicação *na região*. Não é possível criar uma réplica de leitura em uma Regiões da AWS diferente daquela da instância de banco de dados de origem. Isso é conhecido como Replicação *entre regiões*. Para obter mais informações sobre como configurar réplicas de leitura entre regiões, consulte [Criar uma réplica de leitura em uma diferente Região da AWS](USER_ReadRepl.XRgn.md). Os vários mecanismos compatíveis com o processo de replicação na região e entre regiões diferem ligeiramente de acordo com a versão do RDS para PostgreSQL, como explicado em [Como a replicação de streaming funciona para diferentes versões do RDS para PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.md).
Para que a replicação funcione efetivamente, cada réplica de leitura deve ter a mesma quantidade de recursos de computação e de armazenamento que a instância de banco de dados de origem. Se você dimensionar a instância de banco de dados de origem, dimensione as réplicas de leitura também.
O Amazon RDS substituirá todos os parâmetros incompatíveis em uma réplica de leitura se eles impedirem que a réplica de leitura seja iniciada. Por exemplo, suponha que o valor do parâmetro `max_connections` seja mais alto na instância do banco de dados de origem do que na réplica de leitura. Nesse caso, o Amazon RDS atualiza o parâmetro na réplica de leitura para ser o mesmo valor que o da instância de banco de dados de origem.
As réplicas de leitura do RDS para PostgreSQL têm acesso a bancos de dados externos que estão disponíveis por meio de wrappers de dados externos (FDWs) na instância de banco de dados de origem. Por exemplo, suponha que sua instância de banco de dados do RDS para PostgreSQL esteja usando o wrapper do `mysql_fdw` para acessar dados do RDS para o MySQL. Nesse caso, as réplicas de leitura também podem acessar esses dados. Outros FDWs compatíveis incluem `oracle_fdw`, `postgres_fdw` e `tds_fdw`. Para obter mais informações, consulte [Trabalhar com os invólucros de dados externos compatíveis do Amazon RDS for PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Extensions.foreign-data-wrappers.md).
## Usar réplicas de leitura do RDS para PostgreSQL com configurações multi-AZ
É possível criar uma réplica de leitura de uma instância de banco de dados single-AZ ou multi-AZ. É possível usar implantações multi-AZ para melhorar a durabilidade e a disponibilidade de dados essenciais. Uma *réplica em espera* é uma réplica de leitura dedicada que pode assumir a workload em caso de falha do banco de dados de origem. Não é possível utilizar a réplica em espera para atender ao tráfego de leitura. No entanto, é possível criar réplicas de leitura de instâncias de banco de dados multi-AZ de alto tráfego para descarregar consultas somente leitura. Para saber mais sobre implantações multi-AZ, consulte [Implantações de instâncias de banco de dados multi-AZ para o Amazon RDS](Concepts.MultiAZSingleStandby.md).
Se a instância de banco de dados de origem de uma implantação multi-AZ sofrer failover sobre a de espera, todas as réplicas de leitura associadas passarão a usar a réplica de espera (não a primária) como a origem de replicação. As réplicas de leitura podem precisar de reinicialização, de acordo com a versão do RDS para PostgreSQL, da seguinte forma:
+ **PostgreSQL 13 e versões superiores**: a reinicialização não é necessária. As réplicas de leitura são sincronizadas automaticamente com a nova primária. No entanto, em alguns casos, a aplicação cliente pode armazenar os detalhes do DNS (Domain Name Service) em cache para suas réplicas de leitura. Nesse caso, defina o valor do tempo de vida (TTL) como menos de 30 segundos. Isso impede que a réplica de leitura se mantenha em um endereço IP obsoleto (e, portanto, impede que ela sincronize com a nova primária). Para saber mais sobre essa e outras práticas recomendadas, consulte [Diretrizes operacionais básicas do Amazon RDS](CHAP_BestPractices.md#CHAP_BestPractices.DiskPerformance).
+ **PostgreSQL 12 e todas as versões anteriores**: as réplicas de leitura são reiniciadas automaticamente após um failover para a réplica em espera porque a em espera (agora primária) tem um endereço IP e um nome de instância diferentes. A reinicialização sincroniza a réplica de leitura com a nova primária.
Para saber mais sobre failover, consulte [Fazer failover de uma instância de banco de dados multi-AZ para o Amazon RDS](Concepts.MultiAZ.Failover.md). Para saber mais sobre como as réplicas de leitura funcionam em uma implantação multi-AZ, consulte [Trabalhar com réplicas de leitura de instância de banco de dados](USER_ReadRepl.md).
Para oferecer suporte a failover de uma réplica de leitura, é possível criar a réplica de leitura como uma instância de banco de dados multi-AZ para que o Amazon RDS crie uma em espera de sua réplica em outra zona de disponibilidade (AZ). Você pode criar a réplica de leitura como uma instância de banco de dados multi-AZ independentemente de o banco de dados de origem ser ou não uma instância de banco de dados multi-AZ.
# Decodificação lógica em uma réplica de leitura
O RDS para PostgreSQL comporta a replicação lógica em espera com o PostgreSQL 16.1. Isso permite criar uma decodificação lógica a partir de um modo de espera somente leitura que reduza a carga na instância de banco de dados primária. É possível ter maior disponibilidade para as aplicações que precisam sincronizar dados em vários sistemas. Esse recurso melhora a performance do data warehouse e da análise de dados.
Além disso, os slots de replicação em um modo de espera específico mantêm a promoção desse modo de espera para um primário. Isso significa que, no caso de um failover de uma instância de banco de dados primária ou da promoção de uma instância de espera para a nova primária, os slots de replicação serão mantidos e os antigos assinantes em espera não serão afetados.
**Como criar a decodificação lógica em uma réplica de leitura**
1. **Ativar a replicação lógica**: para criar a decodificação lógica em espera, é necessário ativar a replicação lógica na instância de banco de dados de origem e na réplica física. Para obter mais informações, consulte [Configuração de réplica de leitura com o PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Configuration.md).
+ **Para ativar a replicação lógica para uma instância de banco de dados do RDS para PostgreSQL recém-criada**, crie um grupo de parâmetros de banco de dados personalizado e defina o parâmetro estático `rds.logical_replication` como `1`. Depois, associe esse grupo de parâmetros de banco de dados à instância de banco de dados de origem e à réplica de leitura física. Para obter mais informações, consulte [Associar um grupo de parâmetros de banco de dados a uma instância de banco de dados no Amazon RDS](USER_WorkingWithParamGroups.Associating.md).
+ **Para ativar a replicação lógica para uma instância de banco de dados do RDS para PostgreSQL existente**: modifique o grupo de parâmetros personalizado do banco de dados da instância de banco de dados de origem e à réplica de leitura física para definir o parâmetro estático `rds.logical_replication` como `1`. Para obter mais informações, consulte [Modificar parâmetros em um grupo de parâmetros de banco de dados no Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
**nota**
É necessário reinicializar a instância de banco de dados para aplicar essas alterações de parâmetros.
É possível usar a consulta a seguir para verificar os valores para `wal_level` e `rds.logical_replication` na instância de banco de dados de origem e na réplica de leitura física.
```
Postgres=>SELECT name,setting FROM pg_settings WHERE name IN ('wal_level','rds.logical_replication');
name | setting
-------------------------+---------
rds.logical_replication | on
wal_level | logical
(2 rows)
```
1. **Criar uma tabela no banco de dados de origem**: conecte-se ao banco de dados na instância de banco de dados de origem. Para obter mais informações, consulte [Conectar a uma instância de banco de dados executando o mecanismo de banco de dados do PostgreSQL](USER_ConnectToPostgreSQLInstance.md).
Use as seguintes consultas para criar uma tabela no banco de dados de origem e inserir valores:
```
Postgres=>CREATE TABLE LR_test (a int PRIMARY KEY);
CREATE TABLE
```
```
Postgres=>INSERT INTO LR_test VALUES (generate_series(1,10000));
INSERT 0 10000
```
1. **Criar uma publicação para a tabela de origem**: use a consulta a seguir para criar uma publicação para a tabela na instância de banco de dados de origem.
```
Postgres=>CREATE PUBLICATION testpub FOR TABLE LR_test;
CREATE PUBLICATION
```
Use uma consulta SELECT para verificar os detalhes da publicação que foi criada na instância de banco de dados de origem e na instância de réplica de leitura física.
```
Postgres=>SELECT * from pg_publication;
oid | pubname | pubowner | puballtables | pubinsert | pubupdate | pubdelete | pubtruncate | pubviaroot
-------+---------+----------+--------------+-----------+-----------+-----------+-------------+------------
16429 | testpub | 16413 | f | t | t | t | t | f
(1 row)
```
1. **Criar uma assinatura a partir da instância de réplica lógica**: crie outra instância de banco de dados do RDS para PostgreSQL como a instância de réplica lógica. Verifique se a VPC está configurada corretamente para garantir que essa instância de réplica lógica possa acessar a instância de réplica de leitura física. Para obter mais informações, consulte [Amazon VPC e Amazon RDS](USER_VPC.md). Se a instância de banco de dados de origem estiver ociosa, poderão ocorrer problemas de conectividade e a primária não enviará os dados para o modo de espera.
```
Postgres=>CREATE SUBSCRIPTION testsub CONNECTION 'host=Physical replica host name port=port
dbname=source_db_name user=user password=password' PUBLICATION testpub;
NOTICE: created replication slot "testsub" on publisher
CREATE SUBSCRIPTION
```
```
Postgres=>CREATE TABLE LR_test (a int PRIMARY KEY);
CREATE TABLE
```
Use uma consulta SELECT para verificar os detalhes da assinatura na instância de réplica lógica.
```
Postgres=>SELECT oid,subname,subenabled,subslotname,subpublications FROM pg_subscription;
oid | subname | subenabled | subslotname | subpublications
-------+---------+------------+-------------+-----------------
16429 | testsub | t | testsub | {testpub}
(1 row)
postgres=> select count(*) from LR_test;
count
-------
10000
(1 row)
```
1. **Inspecionar o estado do slot de replicação lógica**: somente é possível ver o slot de replicação física na instância de banco de dados de origem.
```
Postgres=>select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots;
slot_name | slot_type | confirmed_flush_lsn
---------------------------------------------+-----------+---------------------
rds_us_west_2_db_dhqfsmo5wbbjqrn3m6b6ivdhu4 | physical |
(1 row)
```
No entanto, na instância de réplica de leitura, é possível ver o slot de replicação lógica e o valor `confirmed_flush_lsn` muda à medida que a aplicação consome ativamente as alterações lógicas.
```
Postgres=>select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots;
slot_name | slot_type | confirmed_flush_lsn
-----------+-----------+---------------------
testsub | logical | 0/500002F0
(1 row)
```
```
Postgres=>select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots;
slot_name | slot_type | confirmed_flush_lsn
-----------+-----------+---------------------
testsub | logical | 0/5413F5C0
(1 row)
```
# Usar réplicas de leitura em cascata com o RDS para PostgreSQL
Desde a versão 14.1, o RDS para PostgreSQL é compatível com réplicas de leitura em cascata. Com *réplicas de leitura em cascata*, é possível dimensionar leituras sem adicionar sobrecarga à instância de banco de dados do RDS para PostgreSQL de origem. As atualizações do log WAL não são enviadas pela instância de banco de dados de origem a cada réplica de leitura. Em vez disso, cada réplica de leitura em uma série em cascata envia atualizações de log WAL para a próxima réplica de leitura da série. Isso reduz a carga na instância de banco de dados de origem.
Com réplicas de leitura em cascata, a instância de banco de dados do RDS para PostgreSQL envia dados de WAL para a primeira réplica de leitura da cadeia. Essa réplica de leitura envia dados de WAL para a segunda réplica na cadeia e assim por diante. O resultado final é que todas as réplicas de leitura na cadeia têm as alterações da instância de banco de dados do RDS para PostgreSQL, mas sem a sobrecarga apenas na instância de banco de dados de origem.
É possível criar uma série de até três réplicas de leitura em uma cadeia de uma instância de banco de dados de origem do RDS para PostgreSQL. Por exemplo, suponha que você tenha uma instância de banco de dados do RDS para PostgreSQL 14.1, `rpg-db-main`. Você pode fazer o seguinte:
+ Começando com `rpg-db-main`, crie a primeira réplica de leitura na cadeia, `read-replica-1`.
+ Na `read-replica-1`, crie a próxima réplica de leitura na cadeia, `read-replica-2`.
+ Finalmente, na `read-replica-2`, crie a terceira réplica de leitura na cadeia, `read-replica-3`.
Não é possível criar outra réplica de leitura além dessa terceira réplica de leitura em cascata na série de `rpg-db-main`. Uma série completa de instâncias de uma instância de banco de dados de origem do RDS para PostgreSQL até o final de uma série de réplicas de leitura em cascata pode consistir em, no máximo, quatro instâncias de banco de dados.
Para que as réplicas de leitura em cascata funcionem, ative os backups automáticos no RDS para PostgreSQL. Crie a réplica de leitura primeiro e ative os backups automáticos na instância de banco de dados do RDS para PostgreSQL. O processo é igual ao de outros mecanismos de banco de dados do Amazon RDS. Para obter mais informações, consulte [Como criar uma réplica de leitura](USER_ReadRepl.Create.md).
Como em qualquer réplica de leitura, é possível promover uma réplica de leitura que faz parte de uma cascata. A promoção de uma réplica de leitura de uma cadeia de réplicas de leitura remove essa réplica da cadeia. Por exemplo, suponha que você queira mover parte da workload da instância de banco de dados `rpg-db-main` para uma nova instância para uso somente pelo departamento de contabilidade. Pressupondo a cadeia com três réplicas de leitura do exemplo, você decide promover `read-replica-2`. A cadeia é afetada da seguinte forma:
+ A promoção de `read-replica-2` a remove da cadeia de replicação.
+ Ela agora é uma instância de banco de dados de leitura/gravação completa.
+ Ela continua replicando para `read-replica-3`, da mesma forma como estava fazendo antes da promoção.
+ A `rpg-db-main` continua a replicar para a `read-replica-1`.
Para obter mais informações sobre como promover réplicas de leitura, consulte [Promoção de uma réplica de leitura a uma instância de banco de dados autônoma](USER_ReadRepl.Promote.md).
**nota**
O RDS para PostgreSQL não aceita atualizações de versão principal para réplicas em cascata. Antes de realizar uma atualização de versão principal, você precisa remover as réplicas em cascata. Você pode recriá-las depois de concluir a atualização na instância de banco de dados de origem e nas réplicas de primeiro nível.
Para réplicas de leitura em cascata, o RDS para PostgreSQL é compatível com quinze réplicas de leitura para cada instância de banco de dados de origem no primeiro nível de replicação e cinco réplicas de leitura para cada instância de banco de dados de origem no segundo e no terceiro níveis de replicação.
# Criar réplicas de leitura em cascata entre regiões com o RDS para PostgreSQL
O RDS para PostgreSQL é compatível com réplicas de leitura em cascata entre regiões. É possível criar uma réplica entre regiões com base na instância de banco de dados de origem e, depois, criar réplicas da mesma região com base nela. Você também pode criar uma réplica da mesma região com base na instância de banco de dados de origem e, depois, criar réplicas entre regiões com base nela.
**Criar uma réplica entre regiões e, depois, criar réplicas na mesma região**
É possível usar uma instância de banco de dados do RDS para PostgreSQL com a versão 14.1 ou posterior, `rpg-db-main`, para fazer o seguinte:
1. Comece com `rpg-db-main` (US-EAST-1) e crie a primeira réplica de leitura entre regiões na cadeia, `read-replica-1` (US-WEST-2).
1. Usando a primeira região cruzada `read-replica-1` (US-WEST-2), crie a segunda réplica de leitura na cadeia, `read-replica-2` (US-WEST-2).
1. Usando `read-replica-2`, crie a terceira réplica de leitura na cadeia, `read-replica-3` (US-WEST-2).
**Criar uma réplica na mesma região e, depois, criar réplicas entre regiões**
É possível usar uma instância de banco de dados do RDS para PostgreSQL com a versão 14.1 ou posterior, `rpg-db-main`, para fazer o seguinte:
1. Começando com `rpg-db-main` (US-EAST-1), crie a primeira réplica de leitura na cadeia, `read-replica-1` (US-EAST-1).
1. Usando `read-replica-1` (US-EAST-1), crie a primeira réplica de leitura entre regiões na cadeia, `read-replica-2` (US-WEST-2).
1. Usando `read-replica-2` (US-WEST-2), crie a terceira réplica de leitura na cadeia, `read-replica-3` (US-WEST-2).
**Limitações na criação de réplicas de leitura entre regiões**
+ Uma cadeia de réplicas de banco de dados em cascata entre regiões pode abranger no máximo duas regiões, com no máximo quatro níveis. Os quatro níveis incluem a origem do banco de dados e três réplicas de leitura.
**Vantagens de usar réplicas de leitura em cascata**
+ Melhor escalabilidade de leitura: ao distribuir consultas de leitura em várias réplicas, a replicação em cascata ajuda a equilibrar a carga. Isso melhora o desempenho, especialmente em aplicações com muita leitura, reduzindo a pressão sobre o banco de dados do gravador.
+ Distribuição geográfica: as réplicas em cascata podem estar em diferentes localizações geográficas. Isso reduz a latência para usuários localizados longe do banco de dados principal e fornece uma réplica de leitura local, aprimorando o desempenho e a experiência do usuário.
+ Alta disponibilidade e recuperação de desastres: no caso de uma falha no servidor primário, as réplicas podem ser promovidas para primárias, garantindo a continuidade. A replicação em cascata aprimora ainda mais isso fornecendo várias camadas de opções de failover, o que melhora a resiliência geral do sistema.
+ Flexibilidade e crescimento modular: à medida que o sistema cresce, novas réplicas podem ser adicionadas em diferentes níveis, sem exigir uma reconfiguração importante do banco de dados principal. Essa abordagem modular permite o crescimento escalável e gerenciável da configuração de replicação.
**Prática recomendada para usar réplicas de leitura entre regiões**
+ Antes de promover uma réplica, crie réplicas adicionais. Isso economizará tempo e proporcionará um processamento eficiente da workload.
# Como a replicação de streaming funciona para diferentes versões do RDS para PostgreSQL
Conforme discutido em [Configuração de réplica de leitura com o PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Configuration.md), o RDS para PostgreSQL usa o protocolo de replicação de streaming nativo do PostgreSQL para enviar dados de WAL da instância de banco de dados de origem. Ele envia dados de WAL de origem para as réplicas de leitura na região e entre regiões. Com a versão 9.4, o PostgreSQL introduziu slots de replicação física como um mecanismo de suporte para o processo de replicação.
Um *slot de replicação física* impede que uma instância de banco de dados de origem remova dados de WAL antes que sejam consumidos por todas as réplicas de leitura. Cada réplica de leitura possui seu próprio slot físico na instância de banco de dados de origem. O slot monitora o WAL mais antigo (por número de sequência lógica, LSN) que pode ser necessário para a réplica. Depois que todos os slots e conexões de banco de dados progrediram além de um determinado WAL (LSN), esse LSN se torna um candidato para remoção no próximo ponto de verificação.
O Amazon RDS usa o Amazon S3 para arquivar dados de WAL. Para réplicas de leitura na região, é possível usar esses dados arquivados para recuperar a réplica de leitura quando necessário. Um exemplo de quando isso pode ser necessário é se a conexão entre o banco de dados de origem e a réplica de leitura for interrompida por qualquer motivo.
Na tabela a seguir, é possível encontrar um resumo das diferenças entre as versões do PostgreSQL e os mecanismos de suporte para réplicas de leitura na região e entre regiões usados pelo RDS para PostgreSQL.
| Versão | Na região | Entre regiões |
| --- | --- | --- |
| PostgreSQL 14.1 e versões posteriores | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.html) |
| PostgreSQL 13 e versões anteriores | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.html) |
Para obter mais informações, consulte [Monitoração e ajuste do processo de replicação](USER_PostgreSQL.Replication.ReadReplicas.Monitor.md).
## Noções básicas dos parâmetros que controlam a replicação do PostgreSQL
Os parâmetros a seguir afetam o processo de replicação e determinam como as réplicas de leitura permanecem atualizadas com a instância de banco de dados de origem:
**max\$1wal\$1senders**
O parâmetro `max_wal_senders` especifica o número máximo de conexões com as quais a instância de banco de dados de origem é compatível ao mesmo tempo por meio do protocolo de replicação de streaming.
O valor padrão varia para versões do RDS para PostgreSQL:
+ Para as versões 13, 14 e 15, o valor padrão é 20.
+ Para as versões 16 e posteriores, o valor padrão é 35.
Esse parâmetro deve ser definido como um número um pouco maior que o número real de réplicas de leitura. Se esse parâmetro for definido muito baixo para o número de réplicas de leitura, a replicação será interrompida.
Para obter mais informações, consulte [max\$1wal\$1senders](https://www.postgresql.org/docs/devel/runtime-config-replication.html#GUC-MAX-WAL-SENDERS) na documentação do PostgreSQL.
`max_wal_senders` é um parâmetro estático que requer a reinicialização da instância de banco de dados para que as alterações sejam aplicadas.
**wal\$1keep\$1segments**
O parâmetro `wal_keep_segments` especifica o número de arquivos de log de gravação antecipada (WAL) que a instância de banco de dados de origem mantém no diretório `pg_wal`. A configuração padrão é 32.
Se `wal_keep_segments` não estiver definido como um valor grande o suficiente para sua implantação, uma réplica de leitura poderá ficar tão distante que interromperá a replicação de streaming. Se isso acontecer, o Amazon RDS gerará um erro de replicação e iniciará a recuperação na réplica de leitura. Ele faz isso reproduzindo os dados de WAL arquivados da instância de banco de dados de origem no Amazon S3. Este processo de recuperação continua até que a réplica de leitura tenha alcançado o suficiente para continuar com a replicação de streaming. É possível ver esse processo em ação, conforme capturado pelo log do PostgreSQL em [Exemplo: como uma réplica de leitura se recupera de interrupções de replicaçãoExemplo: Recuperação de réplica de leitura de interrupções de replicação](#USER_PostgreSQL.Replication.example-how-it-works).
No PostgreSQL versão 13, o parâmetro `wal_keep_segments` é chamado de `wal_keep_size`. Ele atende ao mesmo propósito que `wal_keep_segments`, mas seu valor padrão é em megabytes (MB) (2048 MB) em vez do número de arquivos. Para obter mais informações, consulte [wal\$1keep\$1segments](https://www.postgresql.org/docs/12/runtime-config-replication.html#GUC-WAL-KEEP-SEGMENTS) e [wal\$1keep\$1size](https://www.postgresql.org/docs/current/runtime-config-replication.html#GUC-WAL-KEEP-SIZE) na documentação do PostgreSQL.
**max\$1slot\$1wal\$1keep\$1size**
O parâmetro `max_slot_wal_keep_size` controla a quantidade de dados de WAL que a instância de banco de dados do RDS para PostgreSQL retém no diretório `pg_wal` para atender a slots. Esse parâmetro é usado para configurações que usam slots de replicação. O valor padrão desse parâmetro é `-1`, o que significa que não há limite para a quantidade de dados de WAL mantidos na instância de banco de dados de origem. Para obter informações sobre como monitorar os slots de replicação, consulte [Monitorar os slots de replicação da instância de banco de dados do RDS para PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Monitor.md#USER_PostgreSQL.Replication.ReadReplicas.Monitor-monitor-replication-slots).
Para obter mais informações sobre esse parâmetro, consulte [max\$1slot\$1wal\$1keep\$1size](https://www.postgresql.org/docs/devel/runtime-config-replication.html#GUC-MAX-SLOT-WAL-KEEP-SIZE) na documentação do PostgreSQL.
Quando a transmissão que fornece dados de WAL a uma réplica de leitura é interrompida, o PostgreSQL muda para o modo de recuperação. Ele restaura a réplica de leitura usando os dados de WAL arquivados no Amazon S3 ou usando dados de WAL associados ao slot de replicação. Quando esse processo é concluído, o PostgreSQL restabelece a replicação de streaming.
### Exemplo: como uma réplica de leitura se recupera de interrupções de replicação
No exemplo a seguir, você encontra os detalhes do log que demonstram o processo de recuperação de uma réplica de leitura. O exemplo é de uma instância de banco de dados do RDS para PostgreSQL que executa o PostgreSQL versão 12.9 na mesma Região da AWS que o banco de dados de origem, portanto, os slots de replicação não são usados. O processo de recuperação é o mesmo para outras instâncias de banco de dados do RDS para PostgreSQL que executam PostgreSQL anterior à versão 14.1 com réplicas de leitura na região.
Quando a réplica de leitura perde contato com a instância de banco de dados de origem, o Amazon RDS registra o problema no log como mensagem `FATAL: could not receive data from WAL stream`, junto com `ERROR: requested WAL segment ... has already been removed`. Conforme mostrado na linha em negrito, o Amazon RDS recupera a réplica reproduzindo um arquivo de WAL arquivado.
```
2014-11-07 19:01:10 UTC::@:[23180]:DEBUG: switched WAL source from archive to stream after failure
2014-11-07 19:01:10 UTC::@:[11575]:LOG: started streaming WAL from primary at 1A/D3000000 on timeline 1
2014-11-07 19:01:10 UTC::@:[11575]:FATAL: could not receive data from WAL stream:
ERROR: requested WAL segment 000000010000001A000000D3 has already been removed
2014-11-07 19:01:10 UTC::@:[23180]:DEBUG: could not restore file "00000002.history" from archive: return code 0
2014-11-07 19:01:15 UTC::@:[23180]:DEBUG: switched WAL source from stream to archive after failure recovering 000000010000001A000000D3
2014-11-07 19:01:16 UTC::@:[23180]:LOG: restored log file "000000010000001A000000D3" from archive
```
Quando o Amazon RDS reproduz arquivos de WAL arquivados suficientes na réplica para recuperar o atraso, o streaming para a réplica de leitura pode começar novamente. Quando o streaming é retomado, o Amazon RDS grava uma entrada no arquivo de log, semelhante à mostrada a seguir.
```
2014-11-07 19:41:36 UTC::@:[24714]:LOG:started streaming WAL from primary at 1B/B6000000 on timeline 1
```
## Definir os parâmetros que controlam a memória compartilhada
Os parâmetros que você define determinam o tamanho da memória compartilhada para rastrear IDs de transações, bloqueios e transações preparadas. **A estrutura de memória compartilhada de uma instância em espera deve ser igual ou maior que a de uma instância primária.** Isso garante que a primeira não fique sem memória compartilhada durante a recuperação. Se os valores dos parâmetros na réplica forem menores que os valores dos parâmetros na primária, o Amazon RDS ajustará automaticamente os parâmetros da réplica e reiniciará o mecanismo.
Os parâmetros afetados são:
+ max\$1connections
+ max\$1worker\$1processes
+ max\$1wal\$1senders
+ max\$1prepared\$1transactions
+ max\$1locks\$1per\$1transaction
Para evitar que o RDS reinicialize réplicas em decorrência de memória insuficiente, recomendamos aplicar as alterações de parâmetro como uma reinicialização contínua de cada réplica. Você deve aplicar as seguintes regras ao definir os parâmetros:
+ **Aumentar os valores dos parâmetros:**
+ Você deve sempre aumentar primeiro os valores dos parâmetros de todas as réplicas de leitura e realizar uma reinicialização contínua de todas as réplicas. Em seguida, aplique as alterações de parâmetro na instância primária e reinicialize.
+ **Diminuir os valores dos parâmetros:**
+ Primeiro, você deve diminuir os valores dos parâmetros da instância primária e realizar uma reinicialização. Em seguida, aplique as alterações de parâmetro a todas as réplicas de leitura correspondentes e execute uma reinicialização contínua.
# Monitoração e ajuste do processo de replicação
Convém monitorar rotineiramente a instância de banco de dados do RDS para PostgreSQL e as réplicas de leitura. Verifique se suas réplicas de leitura estão acompanhando as alterações na instância de banco de dados de origem. O Amazon RDS recupera suas réplicas de leitura de forma transparente quando ocorrem interrupções no processo de replicação. No entanto, é melhor evitar qualquer necessidade de recuperação. A recuperação que usa slots de replicação é mais rápida do que usar o arquivo do Amazon S3, mas qualquer processo de recuperação pode afetar a performance de leitura.
Para determinar como suas réplicas de leitura estão acompanhando a instância de banco de dados de origem, é possível fazer o seguinte:
+ **Verifique a quantidade de `ReplicaLag` entre a instância de banco de dados de origem e as réplicas.** *Atraso da réplica* refere-se ao tempo em milissegundos durante o qual uma réplica de leitura fica atrasada em relação à instância de banco de dados de origem. Essa métrica retorna o resultado a seguir.
```
SELECT extract(epoch from now() - pg_last_xact_replay_timestamp()) AS "ReplicaLag";
```
O atraso de réplica é uma indicação de como uma réplica de leitura está acompanhando a instância de banco de dados de origem. É a quantidade de latência entre a instância de banco de dados de origem e uma instância de leitura específica. Um valor alto de atraso de réplica pode indicar uma incompatibilidade entre as classes ou os tipos de armazenamento (ou ambos) usados pela instância de banco de dados de origem e suas réplicas de leitura. A classe e os tipos de armazenamento da instância de banco de dados de origem e de todas as réplicas de leitura devem ser iguais.
O atraso de réplica também pode ser o resultado de problemas de conexão intermitentes. Você pode monitorar o atraso da replicação no Amazon CloudWatch visualizando a métrica `ReplicaLag` do Amazon RDS. Para saber mais sobre `ReplicaLag` e outras métricas do Amazon RDS, consulte [Métricas do Amazon CloudWatch para o Amazon RDS](rds-metrics.md).
+ **Verifique o log do PostgreSQL para obter informações que podem ser usadas para ajustar suas configurações.** Por exemplo, em cada ponto de verificação, o log do PostgreSQL captura o número de arquivos de log de transações reciclados, como mostrado no exemplo a seguir.
```
2014-11-07 19:59:35 UTC::@:[26820]:LOG: checkpoint complete: wrote 376 buffers (0.2%);
0 transaction log file(s) added, 0 removed, 1 recycled; write=35.681 s, sync=0.013 s, total=35.703 s;
sync files=10, longest=0.013 s, average=0.001 s
```
É possível usar essas informações para descobrir quantos arquivos de transação estão sendo reciclados em um determinado período de tempo. É possível alterar a configuração para `wal_keep_segments` se necessário. Por exemplo, suponha que o log do PostgreSQL em `checkpoint complete` exibe `35 recycled` por um intervalo de 5 minutos. Neste caso, o valor padrão de 32 de `wal_keep_segments` não é suficiente para acompanhar a atividade de streaming, e recomendamos aumentar o valor desse parâmetro.
+ **Use o Amazon CloudWatch para monitorar métricas que podem prever problemas de replicação.** Em vez de analisar diretamente o log do PostgreSQL, é possível usar o Amazon CloudWatch para verificar as métricas coletadas. Por exemplo, é possível verificar o valor da métrica `TransactionLogsGeneration` para ver quantos dados de WAL estão sendo gerados pela instância de banco de dados de origem. Em alguns casos, a workload em sua instância de banco de dados pode gerar uma grande quantidade de dados de WAL. Nesse caso, talvez seja necessário alterar a classe da instância de banco de dados de origem e das réplicas de leitura. Usar uma classe de instância com alta performance de rede (10 Gbps) pode reduzir o atraso de réplica.
## Monitorar os slots de replicação da instância de banco de dados do RDS para PostgreSQL
Todas as versões do RDS para PostgreSQL usam slots de replicação para réplicas de leitura entre regiões. O RDS para PostgreSQL 14.1 e versões superiores usam slots de replicação para réplicas de leitura na região. As réplicas de leitura na região também usam o Amazon S3 para arquivar dados de WAL. Em outras palavras, se sua instância de banco de dados e réplicas de leitura estiverem executando o PostgreSQL 14.1 ou superior, os slots de replicação e os arquivos do Amazon S3 estarão disponíveis para recuperar a réplica de leitura. Recuperar uma réplica de leitura usando seu slot de replicação é mais rápido do que recuperar do arquivo do Amazon S3. Portanto, convém monitorar os slots de replicação e as métricas relacionadas.
É possível visualizar os slots de replicação em suas instâncias de banco de dados do RDS para PostgreSQL consultando a visualização `pg_replication_slots` da forma a seguir.
```
postgres=> SELECT * FROM pg_replication_slots;
slot_name | plugin | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn | wal_status | safe_wal_size | two_phase
---------------------------+--------+-----------+--------+----------+-----------+--------+------------+------+--------------+-------------+---------------------+------------+---------------+-----------
rds_us_west_1_db_555555555 | | physical | | | f | t | 13194 | | | 23/D8000060 | | reserved | | f
(1 row)
```
O `wal_status` do valor `reserved` indica que a quantidade de dados de WAL mantidos pelo slot está dentro dos limites do parâmetro `max_wal_size`. Ou seja, o slot de replicação está dimensionado corretamente. Outros valores de status possíveis são os seguintes:
+ `extended`: o slot excede a configuração de `max_wal_size`, mas os dados de WAL estão retidos.
+ `unreserved`: o slot não tem mais todos os dados de WAL necessários. Alguns deles serão removidos no próximo ponto de verificação.
+ `lost`: alguns dados de WAL necessários foram removidos. O slot não é mais utilizável.
Os estados `unreserved` e `lost` do `wal_status` são vistos somente quando `max_slot_wal_keep_size` não é negativo.
A visualização `pg_replication_slots` mostra o estado atual dos slots de replicação. Para avaliar a performance dos slots de replicação, é possível usar o Amazon CloudWatch e monitorar as seguintes métricas:
+ **`OldestReplicationSlotLag`** – mostra a quantidade de dados do log de gravação antecipada (WAL) na origem que não foi consumida pela réplica mais atrasada.
+ **`TransactionLogsDiskUsage`** – Mostra quanto armazenamento está sendo usado para dados WAL. Quando uma réplica de leitura atrasa significativamente, o valor dessa métrica pode aumentar substancialmente.
Para saber mais sobre o uso do Amazon CloudWatch e suas métricas para o RDS para PostgreSQL, consulte [Monitorar métricas do Amazon RDS com o Amazon CloudWatch](monitoring-cloudwatch.md). Para obter mais informações sobre como monitorar a replicação de streaming em suas instâncias de bancos de dados do RDS para PostgreSQL, consulte [Práticas recomendadas para replicação do Amazon RDS para PostgreSQL](https://aws.amazon.com/blogs/database/best-practices-for-amazon-rds-postgresql-replication/) no *Blog de banco de dados da AWS*.
# Configurar replicação atrasada com RDS para PostgreSQL
## Visão geral e benefícios
O recurso de replicação atrasada no RDS para PostgreSQL permite que você adie intencionalmente a replicação de alterações de dados do seu banco de dados principal para um ou mais servidores em espera (réplica de leitura). Esse recurso oferece uma proteção valiosa contra corrupção de dados, perda acidental de dados ou transações errôneas que, de outra forma, poderiam ser propagadas imediatamente para todas as réplicas.
A replicação atrasada é aceita nas seguintes versões do RDS para PostgreSQL:
+ 14.19 e versões 14 posteriores
+ 15.14 e versões 15 posteriores
+ 16.10 e versões 16 posteriores
+ 17.6 e versões 17 posteriores
Ao introduzir um intervalo de tempo no processo de replicação, você ganha uma janela de oportunidade para detectar e responder a incidentes relacionados a dados antes que eles afetem todo o seu cluster de banco de dados. Os principais benefícios da replicação atrasada incluem os seguintes:
+ Permite que você se recupere de exclusões acidentais, atualizações ou outros erros lógicos.
+ Fornece um buffer contra a disseminação de dados corrompidos em seu cluster de banco de dados.
+ Oferece uma opção adicional de ponto de recuperação para complementar suas estratégias tradicionais de backup.
+ Permite que você configure o período de atraso com base nas necessidades específicas da sua organização e na tolerância ao risco.
## Habilitar e configurar a replicação atrasada
Para habilitar a replicação atrasada em uma réplica de leitura do RDS para PostgreSQL, siga estas etapas:
**nota**
Para réplicas de leitura em cascata, use o mesmo parâmetro `recovery_min_apply_delay` e as etapas descritas abaixo.
**Como habilitar a replicação atrasada**
1. Crie um grupo de parâmetros personalizado ou modifique um existente. Para obter mais informações, consulte [Grupos de parâmetros de banco de dados para instâncias de banco de dados do Amazon RDS](USER_WorkingWithDBInstanceParamGroups.md).
1. No grupo de parâmetros, configure o parâmetro `recovery_min_apply_delay`:
+ Defina o valor para o atraso desejado em milissegundos. Por exemplo, 3.600.000 para um atraso de 1 hora.
+ Intervalo permitido: 0 a 86.400.000 ms (0 a 24 horas).
+ Padrão: 0
1. Aplique o grupo de parâmetros à instância de réplica de leitura que você deseja configurar para replicação atrasada.
1. Reinicialize a instância de réplica de leitura para que as alterações tenham efeito.
**nota**
O parâmetro `recovery_min_apply_delay` é dinâmico. Se você modificar um grupo de parâmetros existente que já esteja anexado à instância, as alterações entrarão em vigor imediatamente sem a necessidade de reinicialização. No entanto, ao aplicar um novo grupo de parâmetros à instância, você deverá reinicializar para que as alterações entrem em vigor.
## Gerenciar a recuperação de replicação atrasada
A replicação atrasada é particularmente útil em cenários em que os métodos tradicionais de recuperação para um ponto no tempo podem ser insuficientes ou muito demorados.
Durante o período de replicação atrasada, você pode usar as seguintes funções do PostgreSQL para gerenciar o processo de recuperação:
+ `pg_wal_replay_pause()`: solicitação para pausar o processo de recuperação da réplica atrasada.
+ `pg_wal_replay_resume()`: reinicie o processo de recuperação se ele tiver sido pausado anteriormente.
+ `pg_is_wal_replay_paused()`: confira se o processo de recuperação está pausado no momento.
+ `pg_get_wal_replay_pause_state()`: recupere o estado atual do processo de recuperação (não pausado, pausa solicitada ou pausada).
Os usuários com o perfil `rds_superuser` têm privilégios EXECUTE em `pg_wal_replay_pause()` e `pg_wal_replay_resume()`. Se outros usuários do banco de dados precisarem acessar essas funções, você deverá conceder a eles o perfil `rds_superuser`. Para obter mais informações sobre a função `rds_superuser`, consulte [Noções básicas sobre o perfil rds\$1superuser](Appendix.PostgreSQL.CommonDBATasks.Roles.rds_superuser.md).
O acesso a outras funções, como `pg_is_wal_replay_paused()` e `pg_get_wal_replay_pause_state()`, não exige o perfil `rds_superuser`.
Você pode usar os parâmetros de destino de recuperação a seguir para controlar com precisão o momento em que a réplica atrasada é recuperada. Estes parâmetros são estáticos e exigem a reinicialização do banco de dados para aplicar as alterações:
+ recovery\$1target
+ recovery\$1target\$1lsn
+ recovery\$1target\$1name
+ recovery\$1target\$1time
+ recovery\$1target\$1xid
+ recovery\$1target\$1inclusive
**Importante**
Você só pode especificar um parâmetro de destino de recuperação por vez. Configurar vários parâmetros de destino de recuperação no arquivo de configuração gera um erro.
## Considerações sobre planejamento
Pense no seguinte ao planejar uma replicação atrasada com o RDS para PostgreSQL:
+ Durante a alternância automática de credenciais `rdsrepladmin` (que ocorre a cada 90 dias), as réplicas de leitura atrasadas podem entrar temporariamente no estado `REPLICATION_ERROR`. Se a réplica atrasada tiver logs WAL suficientes para manter o atraso configurado, ela poderá pausar o processo do receptor WAL, causando o acúmulo de WAL na origem. Você deve monitorar o status da replicação na réplica e o consumo de armazenamento na origem para evitar que o armazenamento fique cheio.
+ Quando as réplicas de leitura atrasadas encontram eventos do sistema (como reinicialização ou reinicialização), elas entram no estado `REPLICATION_ERROR` em que o processo do receptor WAL permanece inativo até que o período de atraso configurado expire. Esse comportamento pode causar o acúmulo de WAL na instância de origem, podendo gerar o esgotamento do armazenamento. Pense nas seguintes medidas preventivas:
+ Configure os alarmes do CloudWatch para monitorar a utilização do armazenamento nas instâncias de origem.
+ Habilite o ajuste de escala automático do armazenamento para lidar com o crescimento inesperado do WAL.
+ Defina o parâmetro `max_slot_wal_keep_size` na instância de origem para limitar a retenção de WAL por slot de replicação.
+ Monitore regularmente o atraso na replicação e o status do slot.
+ Atrasos maiores aumentam os logs do WAL nas réplicas, consumindo mais armazenamento. Monitore o espaço de armazenamento usando os alarmes do CloudWatch, habilite o ajuste de escala automático ou acompanhe as réplicas quando necessário.
+ Ao promover uma réplica de leitura atrasada, o parâmetro `recovery_min_apply_delay` não é respeitado e todos os registros pendentes do WAL são aplicados imediatamente.
+ O parâmetro `recovery_min_apply_delay` é independente em cada nível de uma configuração de replicação em cascata. Definir um atraso em uma réplica não aumenta o atraso de nenhuma réplica em cascata.
Para acessar mais informações, consulte a [documentação de réplicas de leitura do RDS para PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html) e a [documentação de recuperação de desastres do RDS para PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Disaster-Recovery.html).
## Noções básicas sobre limitações
O recurso de replicação atrasada do Amazon RDS para PostgreSQL tem as seguintes limitações:
+ As implantações azul/verde têm as seguintes limitações ao configurar a replicação atrasada:
+ **Instância de origem verde**: o `recovery_min_apply_delay parameter` é ignorado, mesmo se configurado no grupo de parâmetros. Nenhuma configuração de atraso na instância de origem verde entra em vigor.
+ **Instância de réplica verde**: o `recovery_min_apply_delay parameter` é totalmente aceito e aplicado ao arquivo de configuração do PostgreSQL. As configurações de atraso funcionam conforme o esperado durante o fluxo de trabalho de transição.
+ Implantações azul/verde do RDS para atualizações de versões principais
+ Durante as atualizações de versões principais, todas as réplicas de leitura atrasadas serão automaticamente encerradas para permitir que a instância de origem continue com o processo de atualização, a fim de garantir o mínimo de tempo de inatividade. Depois que a instância de origem concluir a atualização, você deverá recriar manualmente as réplicas atrasadas.
+ A replicação atrasada não é compatível com os recursos apresentados a seguir.
+ Replicação lógica do RDS para PostgreSQL
+ Clusters multi-AZ do RDS para PostgreSQL (incluindo replicação de entrada e saída)
+ Aurora PostgreSQL
# Solução de problemas da réplica de leitura do RDS para PostgreSQL
A seguir, é possível encontrar ideias de solução de alguns problemas comuns de réplicas de leitura do RDS para PostgreSQL.
**Encerrar a consulta que causa o atraso da réplica de leitura**
As transações ativas ou ociosas no estado de transação que estão sendo executadas por um longo tempo no banco de dados podem interferir no processo de replicação do WAL, aumentando assim o atraso na replicação. Portanto, monitore o tempo de execução dessas transações com a visualização `pg_stat_activity` do PostgreSQL.
Execute uma consulta na instância primária semelhante à seguinte para encontrar o ID do processo (PID) da consulta que está sendo executada por um longo tempo:
```
SELECT datname, pid,usename, client_addr, backend_start,
xact_start, current_timestamp - xact_start AS xact_runtime, state,
backend_xmin FROM pg_stat_activity WHERE state='active';
```
```
SELECT now() - state_change as idle_in_transaction_duration, now() - xact_start as xact_duration,*
FROM pg_stat_activity
WHERE state = 'idle in transaction'
AND xact_start is not null
ORDER BY 1 DESC;
```
Depois de identificar o PID da consulta, você pode optar por encerrá-la.
Execute uma consulta na instância primária semelhante à seguinte para encerrar a consulta que está sendo executada por um longo tempo:
```
SELECT pg_terminate_backend(PID);
```