Obter arquivos WAL da instância do AWS RDS PostgreSQL

Temos uma instância do Postgres RDS no Amazon Web Services. Temos backups automáticos ativados e tiramos instantâneos diariamente. Gostaríamos de gerar um backup local 'atualizado' da instância do RDS que possamos gerenciar por nós mesmos. A execução do pg_dump na instância não é suficiente porque queremos poder restaurar o banco de dados para qualquer ponto no tempo. Preferimos ter um backup local do RDS e de todos os arquivos WAL desde que esse backup foi realizado. Questões:

1. É possível acessar os arquivos e backups WAL que o RDS está gerando automaticamente em sua rotina de backup? Isso seria ideal. Eu gostaria de baixar uma cópia local deles. Após a investigação inicial, sinto que a resposta a esta pergunta é 'não'. Parece que o RDS está armazenando seus arquivos WAL e backups no S3, mas os torna inacessíveis para nós. Eu adoraria confirmação.

2. Existe alguma outra maneira de acessar transações (arquivos WAL) que ocorreram na instância do RDS? Eu imagino que poderíamos criar um banco de dados do Postgres em um EC2 e 'alimentar' transações da nossa instância principal do RDS 'ativa' nesta instância do EC2. Depois que nossa instância do EC2 for atualizada, poderemos extrair arquivos WAL a partir daí. Mas que dor de cabeça: / Esta configuração é possível? Qual é a mágica de 'alimentar' nossa instância do RDS para a instância do EC2 para que ela esteja sempre atualizada?

Obrigado!

Atualização: eu postei sobre isso nos fóruns da AWS - entre na conversa e peça por lá .

No momento da escrita, o Amazon RDS não suporta 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 mostrados, mas bloqueados, por exemplo archive_command, aos quais está bloqueado /etc/rds/dbbin/pgscripts/rds_wal_archive %p. O AWS RDS para PostgreSQL não parece expor esses WALs para acesso externo (por exemplo, via S3), pois seria necessário se você usasse a replicação de envio do WAL para PITR externo.

Portanto, neste ponto, se você quiser usar o transporte marítimo, não use o RDS. É um banco de dados fácil de usar enlatado, 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 no RDS , mas você não pode obter acesso ao WAL a partir do exterior do RDS.

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

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

Entre outras coisas, isso significa que você não tem nenhuma maneira fácil de migrar para longe do RDS. Você precisaria interromper 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 comuns 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 Amazon sem patch, provavelmente não seria permitido permitir a transmissão WAL para o RDS ou a importação para o RDS pg_basebackuppor motivos de segurança. O PostgreSQL trata o diretório de dados como um conteúdo confiável e, se você criou quaisquer funções inteligentes 'LANGUAGE c' que conectam funcionalidade interna ou fizeram algo mais complicado, você pode explorar o servidor para obter um acesso maior do que deveria . Portanto, a Amazon não permitirá o WAL de entrada tão cedo.

Eles poderiam suportar o envio de 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 acionador como Londiste e Bucardo dentro e fora do RDS agora é suportada a partir de 10 de novembro de 2014 , por uma resposta nesse segmento do fórum.

Anúncio aqui