Ideas de vacaciones: Replicación remota de servidores Postgresql vía LVM snapshots

Estas ideas de vacaciones son pensamientos - brainstorming - que fui teniendo mientras mi cerebro hacía cosas extrañas típicas de un ambiente libre de stress, requerimientos de proyecto, constrains de proyectos, etc.

Básicamente sería el espejado de Postgresql (de aquí en adelante pgsql), en condiciones "adversas", ellas serían:

• no poder tocar la BD, nada,
• ni configuración,
• ni procesos internos (SPs varios),
• ni externos (scripts que hacen trabajar a la BD),

etc.

La consideración a tener es que el mirroring no va a ser en tiempo real y tendría la utilidad práctica real de un backup muy actualizado, no de un stand-by-mirror, aparte de tener un servidor de BD totalmente funcional con un par de cambios (IP-host del server y habilitar comunicaciones capa 3 con las mismas variables - puertos, ACLs, reglas de FW, protocolos permitidos - que se manejen para el server en locación primaria).

Se puede implementar esto usando LVM snapshots, SSH (vpns permanentes) , rsync (para bajar el tiempo de transporte de los datos de una locación a otra) , CRON y poco más, algo - muy poco - de scripting (para no complicar, son comandos individuales a correr regularmente).

Para poder tener listo el server haría falta tener la instalación secundaria en el server remoto replicando la instalación del server primario con un plus: el directorio (NO necesariamente una partición aparte), donde están ubicados los archivos de la BD (típicamente /var), que va a estar semivacío en el servidor secundario remoto, al tiempo que existirá un directorio que va a contener al directorio de la BD que trajimos del server primario.

Acá hay decisiones que tomar, se puede automatizar bastante, podríamos tener una o las dos posibilidades (ya hablamos en el contexto del servidor secundario remoto siempre):

A) Manejar la disponibilidad de los datos de la BD (archivos binarios, logs, etc.) directamente vía enlaces simbólicos (previa bajada de servicios); estos enlaces ya podrían estar preparados esperando el start del servicio para empezar a usar los datos traídos del snapshot LVM (o si necesitamos algo muy dinámico, se puede scriptear el enlazado/desenlazado para cuando haga falta).
Si queremos igualar un reemplazo del /var original por el /var del servidor remoto habría que enlazar los directorios de la BD Y también una cantidad muy respetable de archivos relacionados (logs a full, etc.).

Claro, si no queda remedio y no se puede/quiere rebootear el server secundario remoto, el enlazado va a evitar eso al coste que uno esté dispuesto a afrontar ¿enlazamos solo la BD+logs originales?, ¿enlazamos los logs del sistema?, etc.

B) Por otra parte en un rebooteo se puede montar /var para que use una partición diferente donde estarían los archivos snapshoteados; o - menos elegante pero más práctico - se puede montar como partición el directorio donde se copien los archivos del snapshot.

El plus de esto es que no se toca el /var original del server y se conservan automáticamente todos los logs y registros del servidor secundario sin alterar.

Fin del brainstorming, y los snapshots LVM dan para mucho más, por eso y la excelente escalabilidad de LVM fue que propuse es su momento la implementación de LVM en el target de mi idea.