Re: PITR Point in Time Recovery en linea administrado

Hola Alvaro y lista

Mucha gracias por los comentarios, yo estoy completamente de acuerdo con
ustedes sobre reforzar y formalizar un entorno de desarrollo pleno que
aísle la base de producción de las manos inquietas de desarrollo y así lo
tenemos en varias organizaciones, pero asi mismo también doy soporte a
varios empresas pequeñas que el área de "desarrollo, sistemas e
infraestructura" se reduce un ingeniero todero con un servidor donde tiene
instalado toda su plataforma y ahí hace todo y cuanod digo todo es todo!!
Con esfuerzo he logrado al menos implementarles replicación y backups
diarios para contar al menos con un backup en linea en un equipo aparte
(muchas veces en un pc) y son las condiciones donde igual se debe brindar
el soporte y minimizar los riesgos de perdida de información.

El nov. 21, 2015 2:51 PM, "Alvaro Herrera" <alvherre(at)2ndquadrant(dot)com>
escribió:

> Hellmuth Vargas escribió:
>
> > - Aplicación de cambios hasta un timestamp defnido
> > - Aplicación de WAL interactivamente, algo como aplique el siguiente WAL
> > para que por tanteo se pueda llegar a los datos mas próximos antes de la
> > calamidad
>
> Con un restore_command suficientemente complicado podrías hacerlo. Por
> ejemplo podrías hacer uno que consdere un archivo "trigger", que hace
> que el restore_command entre en modo "uno a uno" (digamos
> /tmp/modo_1a1); en este modo, en vez de retornar inmediatamente con el
> archivo que el servidor le pide, el restore_command se pondría a dormir
> hasta que apareciera un archivo trigger distinto (digamos
> /tmp/continuar_restore). Cuando aparece, deja de dormir, elimina
> /tmp/continuar_restore y envía el archivo. (Es importante eliminar el
> archivo, para que la creación de ese archivo sólo autorice un único
> segmento WAL a restaurar).
>
> Eso te provee la interactividad. Cuando elimines el /tmp/modo_1a1
> entonces el restore_command se comporta normalmente, para evitar
> apilamientos de archivos WAL cuando no necesitas esta funcionalidad.
>
> Para aplicar hasta un timestamp determinado, podrías hacer que tu
> restore_command verifique existencia de otro archivo trigger. Si
> existe, lo lee y en él encuentra un recovery_target, y lo graba en el
> recovery.conf, luego da un reload que si mal no recuerdo debería ser
> suficiente para que el recovery no continúe indefinidamente sino que se
> detenga cuando llegue al punto indicado.
>
> Esa es la ventaja de que el restore_command y archive_command sean
> programas arbitrarios que tú escribes: puedes hacer lo que se te ocurra,
> siempre y cuando tengas la imaginación suficiente.
>
> Ahora, estoy totalmente de acuerdo con César Erices: si tu problema es
> que los DBAs se mandan cagadas por estar operando en la BD de producción
> con exceso de alcohol en sangre, lo que deberías hacer en vez de perder
> tiempo en esto es mejorar el entorno para que tengan donde jugar.
>
> --
> Álvaro Herrera http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>