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" <hiv...@gmail.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" <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 >> >
