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" <alvhe...@2ndquadrant.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 >
