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.