Cuestion de experiencia: Caida de servidor
 

Hola, ¿Qué tal?

Estuve buscando en foros y googleando un poco pero no encontré ninguna respuesta/thread/loquesea que se ajuste a lo que buscaba. El tema es que me parece que va mas por el tema de la experiencia, por lo que me aboco a consultar la que mas de uno de ustedes debe tener en el manejo de bases sql.

Sin importar la versión, la pregunta es bastante sencilla: ¿Qué hacen ustedes cuando se cae el servidor?

Es decir, se cae el servidor y quedan transacciones abiertas por los programas que se conectan. Estamos suponiendo que es un servidor hecho y derecho, con su correspondiente back de logs, base, etc. Supongamos también que no esta replicado, por lo que los programas no pueden apuntar a otro lado mientras.

La pregunta va por el tema del manejo de los logs. Le estoy siguiendo la pista pero todavía no termino de entender bien el concepto y cómo actúa bajo estas circunstancias. En definitiva, se me ocurre que se debería hacer un rollback de las transacciones no cerradas. Cualquier link a un tutorial o manual que explique bien esto, es agradecido.

Igualmente, quiero "nutrirme" de sus experencias y vivezas que mas de uno debe tener.

Desde ya, muchas gracias por sus respuestas.

Un saludo (no dos!)

Si la base es Firebird, cuando un servidor se cae, solo hay que esperar a que reinicie.

Las transacciones no se graban hasta que se hacen commits. Las aplicaciones conectadas empezarán a dar errores de conexión (y deberá hacer algo al respecto).

Cuando se vuelva a conectar, abrirá una nueva transacción y todo seguirá funcionando.

Hay una regla para programar bases de datos que dice que las transacciones deben estar abiertas el menor tiempo posible.

Si sigues esta regla, dificilmente tengas problemas. (Siempre que tengas un backup de la base), pues si el disco se quema...

Como dice duilio, cuando un servidor (el que sea) se cae todas las transacciones pendientes se pierden puesto que no han hecho commit. Las aplicaciones normalmente empezaran a mandar mensajes puesto que ya no tienen acceso a la sesión que estaba activa cuando iniciaron. Basta con reniciar y todo listo.

Obviamente como dice duilio, las transacciones deben ser muy pero muy cortas.

Creo que esto es denominado el principio de atomicidad, se hace todo o no se hace nada
Las bases de datos manejan esto sin necesidad de que se haga directamente desde la aplicacion, esto solo en los casos en que se manejen transacciones

Como te lo sugieren la idea es que la coneccion este abierta el menor tiempo posible, puedes guardar la informacion "commit" para cada registro editado, insertado o eliminado y no esperar a tener un gran numero de registros para hacerlo

Suerte

Exacto, con firebird no hay que hacer nada. :)
Pero... ¿cuándo se cae el servidor?, yo no recuerdo ninguna caída de ningún servidor sql firebird, ahora bien, si te refieres a caídas físicas, problemas de hardware, pues es cuestión de tener backups actualizados.
Si tienes un raid 1 (espejo), tampoco tendrás que hacer nada si se rompe el disco duro, seguirá funcionando con el otro, y es posible que ni siquiera te des cuenta que está roto uno de los discos.

En mi caso que uso MySQL sobre Linux, tengo replicado el servidor en otra oficina distinta de donde esté corriendo el principal, de hecho a algunos clientes les cobro una renta mensual por replicarles su servidor. Si algo le pasa al servidor principal, simplemente conecto el replicante y listo. Los clientes no tienen que hacer nada.

Gracias por las respuestas

Saludos