Actualización: He publicado sobre esto en los foros de AWS. Por favor, intervenga y solicítelo allí .
Al momento de escribir, Amazon RDS no admite la replicación física fuera de RDS. Puede GRANTusar los usuarios REPLICATIONcorrectamente mediante un rds_superuserinicio de sesión, pero no puede configurar replicationentradas para IP externas en pg_hba.conf.
Además, cuando crea un grupo de parámetros de base de datos en RDS, algunos parámetros clave se muestran pero están bloqueados, por ejemplo archive_command, que está bloqueado /etc/rds/dbbin/pgscripts/rds_wal_archive %p. AWS RDS para PostgreSQL no parece exponer estos WAL para acceso externo (por ejemplo, a través de S3), ya que sería necesario si usara la replicación de envío WAL para PITR externo.
Por lo tanto, en este punto, si desea un envío de wal, no use RDS. Es una base de datos enlatada fácil de usar, pero fácil de usar a menudo significa que también es limitada, y ese es ciertamente el caso aquí. Como Joe Love señala en los comentarios, proporciona envío WAL y PITR dentro de RDS , pero no puede acceder a WAL desde fuera de RDS.
Por lo tanto, debe utilizar las propias instalaciones de respaldo de RDS: volcados, instantáneas y su propio PITR basado en WAL.
Incluso si RDS le permitiera hacer conexiones de replicación (para pg_basebackupreplicación o transmisión) y le permitiera acceder a WAL archivado, es posible que no pueda consumir ese WAL. RDS ejecuta un PostgreSQL parcheado, aunque nadie sabe cuánto parcheado o si altera significativamente el formato en el disco. También se ejecuta en la arquitectura seleccionada por Amazon, que probablemente sea Linux x64, pero no es fácil de determinar. Dado que el formato y la replicación de PostgreSQL en el disco dependen de la arquitectura, solo puede replicar en hosts con la misma arquitectura que la utilizada por Amazon RDS, y solo si su compilación de PostgreSQL era compatible con la de ellos.
Entre otras cosas, esto significa que no tiene una forma fácil de migrar fuera de RDS. Tendría que detener todas las escrituras en la base de datos durante el tiempo suficiente para tomar un pg_dumparchivo, restaurarlo y ejecutar la nueva base de datos. Los trucos habituales con replicación y conmutación por error, con rsync, etc., no funcionarán porque no tienes acceso directo al host de la base de datos.
Incluso si RDS ejecutó un PostgreSQL Amazon sin parches, probablemente no le gustaría permitirle hacer streaming WAL en RDS o importarlo a RDS pg_basebackuppor razones de seguridad. PostgreSQL trata el directorio de datos como contenido confiable, y si ha creado funciones inteligentes de 'IDIOMA c' que enganchan la funcionalidad interna o ha hecho algo más complicado, podría explotar el servidor para obtener un mayor acceso del que se supone que tiene . Por lo tanto, Amazon no permitirá la entrada de WAL en el corto plazo.
Podrían admitir el envío saliente de WAL, pero los problemas anteriores con compatibilidad de formatos, libertad para realizar cambios, etc., aún se aplican.
En su lugar, debe usar una herramienta como Londiste o Bucardo.