Después del apagón

No todos los fallos son iguales

Las propiedades de atomicidad y durabilidad no se cumplen por arte de magia: el sistema se prepara antes de que algo falle. El esquema de recuperación se encarga de devolver la base de datos al último estado consistente, y de hacerlo rápido, para que no quede fuera de servicio mucho tiempo. Primero hay que distinguir qué puede fallar:

• Fallo en la transacción. Un error lógico (datos incorrectos, un registro que no existe, un límite excedido) o un error del sistema, como ser víctima de un interbloqueo. Afecta a una sola transacción, que se deshace y quizá se reintenta.
• Caída del sistema. Se va la luz o falla el software: se pierde todo lo que estaba en la memoria, pero el disco queda intacto. Es una caída blanda y afecta a todas las transacciones en curso.
• Fallo de disco. Se daña físicamente parte del almacenamiento. Es una caída dura, y solo se recupera con copias guardadas en otro lado.

La bitácora y la escritura anticipada

Por rendimiento, la base de datos trabaja en memoria y escribe al disco de vez en cuando. Por eso, al caerse, el disco puede estar atrasado (le faltan cambios confirmados) o adelantado (tiene cambios que nunca se confirmaron).

Para arreglar ambos casos usa la bitácora (log): una secuencia de registros que describe cada escritura con cuatro datos:

<transacción, dato, valor anterior, valor nuevo>

Con el valor anterior puede deshacer; con el nuevo, rehacer. Y hay una regla de oro, la escritura anticipada: el registro de la bitácora llega al disco antes que el dato que describe, y una transacción no termina su COMMIT hasta que su bitácora está en disco.

Rehacer lo confirmado, deshacer lo demás

Al reiniciar, ¿cómo sabe el sistema qué rehacer y qué deshacer sin leer toda la bitácora desde el principio de los tiempos? Gracias al punto de verificación (checkpoint). Cada cierto tiempo, el sistema:

1. escribe en el disco las páginas que están en memoria;
2. escribe en la bitácora un registro especial con la lista de transacciones en curso en ese momento.

Todo lo anterior al punto de verificación ya está en disco. Al reiniciar, basta con revisar desde ahí:

• Las transacciones que confirmaron después del punto de verificación se rehacen: su COMMIT está en la bitácora, aunque sus datos quizá no llegaron al disco.
• Las que seguían en curso al caerse se deshacen, aunque hayan empezado antes del punto de verificación.
• Las que terminaron antes del punto de verificación no necesitan nada.

Respaldo más bitácora

Ante un fallo de disco, la bitácora sola no basta: falta la base de la que partir. La recuperación consiste en restaurar el último respaldo en otro disco y luego usar la bitácora, que se guarda en un dispositivo distinto, para rehacer todas las transacciones confirmadas desde ese respaldo. No hay que deshacer nada de lo que estaba en curso: sus cambios ya se perdieron con la memoria.

Por eso todo sistema necesita una utilidad de vaciado y restauración: la parte de vaciado crea los respaldos, que pueden ir a cualquier medio, aunque no sea de acceso directo, y la de restauración reconstruye la base de datos a partir de uno.

Failover y failback

La tolerancia a fallos es la capacidad de seguir accediendo a la información aunque algo falle. Exige redundancia: guardar la misma información en más de un soporte físico o en un equipo externo.

• Failover: pasar temporalmente la producción al ambiente de respaldo, tras un desastre o durante un mantenimiento.
• Failback: devolver la producción a su lugar y estado original, sincronizando lo que cambió mientras tanto.

Antes de leer la respuesta