Trabalhar com réplicas de leitura do Amazon RDS para PostgreSQL - Amazon Relational Database Service
Decodificação lógica em uma réplica de leituraLimitações de réplicas de leitura com o PostgreSQLConfiguração de réplica de leitura com o PostgreSQLUsar réplicas de leitura em cascataCriar réplicas de leitura em cascata entre regiõesComo a replicação funciona para diferentes versões do RDS para PostgreSQLMonitoração e ajuste do processo de replicaçãoSolução de problemas da réplica de leitura do RDS para PostgreSQL

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.

A seguir, você pode encontrar informações específicas sobre como trabalhar com réplicas de leitura com o RDS para PostgreSQL.

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 ter mais informações, consulte Configuração de réplica de leitura com o PostgreSQL.

    • 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 ter 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.

    • 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 ter mais informações, consulte Modificar parâmetros em um grupo de parâmetros de banco de dados no Amazon RDS.

    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)

  2. 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 ter mais informações, consulte Conectar a uma instância de banco de dados executando o mecanismo de banco de dados do PostgreSQL.

    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

  3. 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)

  4. 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 ter mais informações, consulte Amazon VPC e Amazon RDS. 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)

  5. 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)

Limitações de réplicas de leitura com o PostgreSQL

As limitações de réplicas de leitura do PostgreSQL são as seguintes:

nota

Uma réplica de leitura da instância de banco de dados multi-AZ e Single-AZ do RDS para PostgreSQL que execute o PostgreSQL versão 12 e anterior é reinicializada automaticamente para aplicar a troca da senha durante a janela de manutenção de sessenta a noventa dias. Se a conexão da réplica com a origem for interrompida antes da reinicialização programada, a instância ainda será reinicializada para que a replicação seja retomada.

  • 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 ter mais informações, consulte Usar réplicas de leitura em cascata com o RDS para PostgreSQL.

  • 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 ter mais informações, consulte Promoção de uma réplica de leitura a uma instância de banco de dados autônoma.

  • 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 ter mais informações, consulte Usar réplicas de leitura em cascata com o RDS para PostgreSQL.

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

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 (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, consulteUsar o SSL com uma instância de banco de dados PostgreSQL

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 ter mais informações, consulte Usar réplicas de leitura em cascata com o RDS para PostgreSQL. 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, consulteComo criar uma réplica de leitura

É 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 Região da AWS diferente. 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.

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, consulteTrabalhar com os invólucros de dados externos compatíveis do Amazon RDS for PostgreSQL

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.

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.

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

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.

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, consulteComo criar uma réplica de leitura

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.

nota

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

  2. 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).

  3. 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).

  2. 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).

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

Consulte mais informações sobre as vantagens de usar a replicação em Sobre a replicação no Cloud SQL.

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

Version (Versão) Na região Entre regiões
PostgreSQL 14.1 e versões posteriores

  • Slots de replicação

  • Arquivo do Amazon S3

  • Slots de replicação
PostgreSQL 13 e versões anteriores

  • Arquivo do Amazon S3

  • Slots de replicação

Para obter mais informações, consulteMonitoração e ajuste do processo de replicação

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_wal_senders

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 padrão do RDS para PostgreSQL 13 e versões superiores é 20. 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_wal_senders na documentação do PostgreSQL.

wal_keep_segments

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ção.

nota

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_keep_segments e wal_keep_size na documentação do PostgreSQL.

max_slot_wal_keep_size

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.

Para obter mais informações sobre esse parâmetro, consulte 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_connections

  • max_worker_processes

  • max_wal_senders

  • max_prepared_transactions

  • max_locks_per_transaction

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.

  • 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: lista o slot que tem o maior atraso, ou seja, está mais distante do primário Esse atraso pode estar associado à réplica de leitura, mas também à conexão.

  • 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. 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 no Blog de banco de dados da AWS.

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);