Necesitaríamos registrar en un Log cada INSERT, UPDATE, y DELETE que se haga sobre la base.
Por ejemplo:
El backup de nuestra base se realiza periódicamente a una cierta hs, por ej. 22hs.
Si el disco rígido falla a las 10hs del día siguiente, tendríamos que restaurar la base, del ultimo backup (22hs), tengamos en cuenta que se trabajo desde las 7 a las 10hs, entonces como recuperar esos datos que se cargaron?.
La pregunta es: si tenemos habilitado un Log de transacciones pongamos por caso el ultimo Log antes del fallo del disco se envió a otro servidor a las 9:50hs entonces es posible ejecutar el script del Log (con los insert, etc.) a la base?.
Gracias!
Hola Ines,
no se si estuvieron leyendo el siguiente link http://www.postgresql.org/docs/8.3/interactive/continuous-archiving.html por ahi puede ser justo lo que andan buscando, de todas formas tene en cuenta que un log continuo de toda operacion realizada va a impactar altamente en la performance del sistema. Probablemente Emanuel o Nico puedan ayudarte mejor con respecto a ese tema.
Veo que en la situacion que presentas Murphy y el diablo se compadecieron un poco al hacerte perder solo 10 minutos XD. Por otro lado, la rotura de un disco no siempre es de un segundo a otro, quizas puedas ir teniendo corrupcion de datos hasta que finalmente explota, un log como el del link te va a ayudar a reprocesar las operaciones, pero nada te asegura que el log mismo no se corrompa y quede inservible a pesar de haberse copiado a otro servidor.
En definitiva, lo mejor que se puede hacer es tener hardware redundante que nos brinde la posibilidad de recibir alertas tempranas de problemas, un buen esquema de backups (+log de ayuda)… y lo mas importante … usuarios educados que entiendan que cuando el diablo mete la cola… no queda otra que armarse de paciencia y volver a cargar lo pasado :).
Saludos
Richard
Gracias Richard me esta siendo de gran utilidad el link que me pasaste.
Saludos, Inés.
Buenas!
Perdón que me meta, pero tené en cuenta que Pilagá no soporta la versión 8.3 de postgres Ines.
La verdad que no me lo puse a leer, pero por las dudas el link sería este. (en la 8.3 dice “Continuous Archiving” y en la 8.1 “On-line backup”)
Saludos, Esteban.
Registrar en un LOG las sentencias? Esto se peude setear desde el postgresql.conf en la opción :
#log_statement = ‘none’ # none, mod, ddl, all
(deberías poner en vez de ‘none’ cualquiera de las otras)
Ahora bien. Implementar Continuous Archiving en 8.2 (es compatible con Pilaga, revisar doc en http://www.postgresql.org/docs/8.2/interactive/continuous-archiving.html ) es posible. El problema es que implementar CA sin antes haber implementado un RAID por lo menos por software , es una opción no muy viable. Basicamente CA requiere al menos 2 servidores en linea, con buena comunicación entre ambos y tampoco asegura que ‘la ultima transacción o MOD’ entre en el backup.
Basicamente esta técnica envia los segmentos de la WAL (de 16 MB cada una) una vez que se ‘switchea’. Quiere decir que si aún se esta usando un segmento de la WAL (el ultimo) y falla el servidor, ese segmento no se envió al backup. De ahí que la mejor solución para mantener más actualizado un servidor es con un RAID y una vez implementado esto, implementar un CA.
La idea de guardar en un log , las transacciones y en caso de fallo ejecutarlas nuevamente no es muy consistente. Esto se debe a que la performance del servidor disminuirá notablemente. La otra, requeriría que el Log esté en otro servidor (en un dispositivo montado) ya que si almacenas en el mismo disco y falla el mismo, perdés también el log.
Por lo tanto, antes de implementar CA, traten de implementar aunque sea un RAID 1 en el servidor. De otra manera necesitarían un servidor adicional para el backup incremental.
Para info de RAID por software visitá: http://desarrollos.siu.edu.ar/trac/postgresql/attachment/wiki/Documentos/Paso%20a%20paso%20un%20servidor%20afinado.pdf