Obtenga archivos WAL de la instancia de AWS RDS PostgreSQL

Tenemos una instancia de Postgres RDS en Amazon Web Services. Tenemos respaldos automáticos habilitados y tomamos instantáneas diariamente. Nos gustaría generar una copia de seguridad local 'actualizada' de la instancia de RDS que podamos administrar nosotros mismos. Ejecutar pg_dump contra la instancia no es suficiente porque queremos poder restaurar la base de datos en cualquier momento. Preferiríamos tener una copia de seguridad local de RDS y todos los archivos WAL desde que se realizó esa copia de seguridad. Preguntas:

1. ¿Es posible acceder a los archivos WAL y las copias de seguridad que RDS genera automáticamente en su rutina de copia de seguridad? Esto sería ideal Me gustaría descargar una copia local de ellos. Después de la investigación inicial, siento que la respuesta a esta pregunta es 'no'. Parece que RDS está almacenando sus archivos WAL y copias de seguridad en S3, pero los hace inaccesibles para nosotros. Me encantaría la confirmación.

2. ¿Hay alguna otra forma de acceder a las transacciones (archivos WAL) que se han producido en la instancia de RDS? Me imagino que deberíamos poder crear una base de datos Postgres en un EC2 y 'alimentar' las transacciones de nuestra instancia RDS 'en vivo' primaria en esta instancia EC2. Una vez que se actualiza nuestra instancia EC2, podríamos extraer archivos WAL desde allí. Sin embargo, qué dolor de cabeza: / ¿Es posible esta configuración? ¿Cuál es la magia para 'alimentar' desde nuestra instancia RDS a la instancia EC2 para que siempre esté actualizada?

¡Gracias!

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.

Esto ahora es posible mediante la replicación lógica: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html#PostgreSQL.Concepts.General.FeatureSupport.LogicalReplication

La replicación utilizando sistemas basados ​​en disparadores como Londiste y Bucardo dentro y fuera de RDS ahora es compatible a partir del 10 de noviembre de 2014 , según una respuesta en ese hilo del foro.

Anuncio aquí