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
-
Crie um grupo de parâmetros personalizado ou modifique um existente. Para ter mais informações, consulte Grupos de parâmetros de banco de dados para instâncias de banco de dados do Amazon RDS.
-
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
-
-
Aplique o grupo de parâmetros à instância de réplica de leitura que você deseja configurar para replicação atrasada.
-
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_superuser.
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_target
-
recovery_target_lsn
-
recovery_target_name
-
recovery_target_time
-
recovery_target_xid
-
recovery_target_inclusive
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 estadoREPLICATION_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_ERRORem 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_sizena 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_delaynã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 e a documentação de recuperação de desastres do RDS para PostgreSQL.
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
-