Obtenha arquivos WAL da instância PostgreSQL do AWS RDS

Atualização: postei sobre isso nos fóruns da AWS - entre em contato e pergunte lá .

Até o momento, o Amazon RDS não oferece suporte à replicação física fora do RDS. Você pode usar GRANTo REPLICATIONdireito de usuário usando um rds_superuserlogin, mas não pode configurar replicationentradas para IPs externos em pg_hba.conf.

Além disso, quando você cria um grupo de parâmetros de banco de dados no RDS, alguns parâmetros-chave são exibidos, mas bloqueados, por exemplo archive_command, que é bloqueado para /etc/rds/dbbin/pgscripts/rds_wal_archive %p. O AWS RDS for PostgreSQL não parece expor esses WALs para acesso externo (digamos, via S3), como seria necessário se você usasse a replicação de remessa WAL para PITR externo.

Portanto, neste ponto, se você deseja enviar pelo wal, não use o RDS. É um banco de dados enlatado e fácil de usar, mas fácil de usar geralmente significa que também é limitado, e esse certamente é o caso aqui. Como Joe Love aponta nos comentários, ele fornece remessa WAL e PITR dentro do RDS , mas você não pode acessar o WAL de fora do RDS.

Portanto, você precisa usar os próprios recursos de backup do RDS - dumps, instantâneos e seu próprio PITR baseado em WAL.

Mesmo que o RDS permitisse que você fizesse conexões de replicação (para pg_basebackupou replicação de streaming) e permitisse o acesso ao WAL arquivado, talvez você não conseguisse realmente consumir esse WAL. O RDS executa um PostgreSQL corrigido, embora ninguém saiba o quão fortemente corrigido ou se altera significativamente o formato em disco. Ele também roda na arquitetura selecionada pela Amazon, que provavelmente é x64 Linux, mas não é facilmente determinada. Como o formato e a replicação do PostgreSQL em disco dependem da arquitetura, você só pode replicar para hosts com a mesma arquitetura usada pelo Amazon RDS e somente se a compilação do PostgreSQL for compatível com a deles.

Entre outras coisas, isso significa que você não tem uma maneira fácil de migrar do RDS. Você teria que parar todas as gravações no banco de dados por tempo suficiente para obter um pg_dump, restaurá-lo e colocar o novo banco de dados em execução. Os truques usuais com replicação e failover, com rsync, etc, não funcionarão porque você não tem acesso direto ao host do banco de dados.

Mesmo se o RDS executasse um PostgreSQL sem patch, a Amazon provavelmente não permitiria que você fizesse streaming do WAL para o RDS ou importasse para o RDS usando pg_basebackuppor motivos de segurança. O PostgreSQL trata o diretório de dados como conteúdo confiável, e se você criou alguma função 'LANGUAGE c' inteligente que conecta a funcionalidade interna ou fez qualquer outra coisa complicada, você pode explorar o servidor para obter maior acesso do que deveria ter . Portanto, a Amazon não permitirá a entrada do WAL tão cedo.

Eles poderiam suportar o envio WAL de saída, mas os problemas acima com compatibilidade de formato, liberdade para fazer alterações, etc., ainda se aplicam.

Em vez disso, você deve usar uma ferramenta como Londiste ou Bucardo.

Agora isso é possível usando a replicação lógica: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html#PostgreSQL.Concepts.General.FeatureSupport.LogicalReplication

A replicação usando sistemas baseados em gatilho como Londiste e Bucardo dentro e fora do RDS agora é suportada a partir de 10 de novembro de 2014 , de acordo com uma resposta naquele tópico do fórum.

Anúncio aqui