Re: PITR Point in Time Recovery en linea administrado

Hola lista.. Y no sobra agregar que es justo que con el Ultimo tipo de
empresas, con las cuales más retos y aprendizaje se obtiene.. Todos los
días nos sorprenden con algo nuevo... :-)
El nov. 21, 2015 5:08 PM, "Hellmuth Vargas" <hivs77(at)gmail(dot)com> escribió:

> 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
>>
>