5.4.1 Definición
Recuperarse al fallo de una transacción significa que la base de datos se restaura al estado coherente más reciente, inmediatamente anterior al momento del fallo para esto el sistema guarda la información sobre los cambios de las transacciones esta información se guarda en el registro del sistema.
1. Si hay un fallo como la caída del disco, el sistema restaura una copia se seguridad del registro, hasta el momento del fallo.
2. Cuando el daño se vuelve inconsistente, se pueden rehacer algunas operaciones para restaurar a un estado consistente. En este caso no se necesita una copia archivada.
Actualización Diferida: No se actualiza físicamente la base de datos Hasta que no haya alcanzado su punto de confirmación.
Actualización Inmediata: La base de datos puede ser actualizada por Algunas Operaciones antes de que esta última alcance su punto de confirmación.
5.4.2 Tipos de Almacenamiento
• Almacenamiento Volátil: no sobrevive a las caídas del sistema.
• Almacenamiento no Volátil: disco, cinta...: existen accidentes.
• Almacenamiento Estable Frente al no Estable: la información no se pierde “nunca”, se repite en varios medios no volátiles (disco) con modos de fallo independientes.
Almacenamiento en Caché (Búfer) de los Bloques de Disco
El proceso de recuperación se entrelaza con funciones del sistema operativo en particular con el almacenamiento en caché o en búfer en la memoria principal, Normalmente se reserva una colección de búferes en memoria, denominados caché DBMS. Se utiliza un directorio para rastrear los elementos de la base de datos que se encuentra en los búferes.
Bit Sucio: que puede incluirse en la entrada del directorio, para indicar si se ha modificado o no el búfer.
Pin: Un pin dice que una página en caché se está accediendo actualmente.
Actualización en el Lugar (In Place): Escribe en el búfer la misma ubicación de disco original.
Shadowing (en la Sombra): Escribe un búfer actualizado en una ubicación diferente.
BFIM (Before Image): Imagen antes de la actualización.
AFIM (After Image): Imagen después de la actualización.
Registro Antes de la Escritura, Robar/No-Robar y Forzar no Forzar
En este caso, el mecanismo de recuperación debe garantizar la grabación de la BFIM de los datos en la entrada apropiada del registro del sistema y que esa entrada se vuelque en el disco antes que la BFIM sea sobrescrita con la AFIM de la base de datos del disco.
Puntos de Control en el Registro del Sistema y Puntos de Control Difusos
Otro tipo de entrada en el registro es el denominado punto de control (checkpoint). En este punto el sistema escribe en la base de datos, en disco, todos los búferes del DBMS que se han modificado.
No tienen que rehacer sus operaciones, es decir, ESCRIBIR en caso de una caída del sistema.
El gestor de recuperaciones de un DBMS debe decidir en qué intervalos tomar un punto de control.
La toma de un punto de control consiste en las siguientes acciones:
1. Suspender temporalmente la ejecución de las transacciones.
2. Forzar la escritura de disco de todos los búferes de memoria que se hayan modificado.
3. Escribir un registro (checkpoint) en el registro del sistema y forzar la escritura del registro en el disco.
4. Reanudar la ejecución de las transacciones.
Diarios para Recuperación
• Se utilizan también los términos log y journal.
• Mantiene un registro de todas las operaciones que afectan a ítems de la base de datos.
• Esta información permite recuperar.
• Se almacena en disco.
• Operaciones posibles a reflejar:
[start, T]
[write, T, X, valor_viejo, valor_nuevo] (Opcional)
[read, T, X]
[commit, T]
[abort, T]
undo, redo
5.4.3 Técnicas de Recuperación Basadas en la Actualización Diferida
• Graba todas las actualizaciones de la BD en el diario, pero aplaza la ejecución de todas las operaciones de escritura (write) de una transacción hasta que ésta se encuentre parcialmente cometida.
• Solamente requiere el nuevo valor del dato.
• Si la transacción aborta (no llega a committed), simplemente hay que ignorar las anotaciones en el diario.
• Para recuperaciones usa el procedimiento: redo (Ti), que asigna los nuevos valores a todos los datos que actualiza Ti.
• Después de ocurrir un fallo, se consulta el diario para determinar que transacciones deben repetirse y cuales anularse.
Ti debe anularse si el diario contiene el registro start pero no el commit.
Ti debe repetirse si el diario contiene el registro start y el commit.
• La operación redo debe ser idempotencia, es decir, ejecutarla varias veces debe producir el mismo resultado que ejecutarla una sola vez.
Los Redo comienzan a hacerse en el último checkpoint no sabemos si la información está en disco o en memoria.
Recuperación Mediante la Actualización Diferida en un Entorno Monousuario
El algoritmo RDU se utiliza un procedimiento rehacer, proporcionado con posterioridad.
Para rehacer determinadas operaciones escribir elemento.
Imagen 6: Técnica de recuperación diferida
Actualización Diferida con Ejecución Concurrente en un Entorno Multiusuario
Imagen 7: ejemplo de recuperación de entorno multiusuario
5.4.4 Recuperaciones Basadas en Actualizaciones Inmediatas
• Permite que las actualizaciones se graben en la BD mientras la transacción está todavía en estado activo (actualizaciones no cometidas).
• Antes de ejecutar un output (X), deben grabarse en memoria estable los registros del diario correspondientes a X.
• Los registros del diario deben contener tanto el valor antiguo como el nuevo.
• El esquema de recuperación utiliza dos procedimientos de recuperación:
undo (Ti): Restaura los datos que Ti actualiza a los valores que tenían antes.
redo (Ti): Asigna los nuevos valores a todos los datos que actualiza Ti.
• Después de ocurrir un fallo, el procedimiento de recuperación consulta el diario para determinar qué transacciones deben repetirse y cuáles deshacerse:
1. Ti debe deshacerse si el diario contiene el registro starts, pero no el commit.
2. Ti debe repetirse si el diario contiene el registro starts y el commit.
• Las operaciones undo y redo deben ser idempotencias para garantizar la consistencia de la BD aun cuando se produzcan fallos durante el proceso de recuperación.
5.4.5 Recuperación Hasta un Punto de Validación
1. Examina el diario hacia atrás hasta localizar un registro <checkpoint>.
2. Considera sólo los registros existentes entre este punto y el final del diario.
3. Ejecuta undo (Tj) para las transacciones que no tengan registro <Tj commits>, partiendo del final del fichero.
4. Ejecuta redo (Ti) para las transacciones que tengan su registro <Ti commits>, partiendo desde el punto de verificación hasta el final del diario.
Procedimientos de Recuperación
Recuperación Normal
• Tiene lugar después de una parada normal de la máquina, en la que se escribe un punto de verificación como último registro del diario.
• Este procedimiento se ejecuta cuando el último registro del diario es un punto de verificación o recuperación del sistema.
• Este tipo de recuperación también tiene lugar cuando aborta una transacción, debido a la razón que sea.
Recuperación en Caliente
• Después de un error del sistema.
• Se ejecuta cuando el último registro del diario no es un punto de verificación y el operador no indica pérdida de memoria secundaria.
• El procedimiento de recuperación es el indicado en el apartado referente a los puntos de verificación en el diario.
Recuperación en Frío
• Después de un incidente con la memoria masiva dañada.
• Se ejecuta si se pierden datos o la BD ya no es coherente.
• Se utiliza:
1. Copia de seguridad (backup) más reciente de la BD (Debe existir).
Diario de las actividades posteriores.
Se aplican las imágenes posteriores al respaldo.
• Puede encadenar una recuperación en caliente.
• Se deben realizar copias de seguridad de la BD periódicamente:
Toda la BD debe copiarse en memoria secundaria.
El proceso de transacciones debe pararse durante el procedimiento de copia (Costoso).
Algoritmo de Recuperación ARIES
a) El registro del sistema en el momento de la caída.
b) Las tablas de transacciones y de páginas sucias en el momento de punto de control.
c) Las tablas de transacciones y de páginas sucias después de la fase de análisis.
Imagen 8: tablas de transacciones
5.4.6 Respaldos de Bases de Datos
Siempre es necesario tener un respaldo de nuestras bases de datos, pero que pasa cuando nuestras bases de datos están tan pesadas que el phpMyAdmin se queda colgado. Para eso nos sirve mysqldump un comando que nos trae MySQL para hacer respaldos de nuestras bases de datos su sintaxis es la siguiente:
mysqldump [OPTIONS] database [tables]
O mysqldump [OPTIONS] –databases [OPTIONS] DB1 [DB2 DB3...]
O mysqldump [OPTIONS] –all-databases [OPTIONS]
Algunos de sus parámetros más utilizados son los siguientes:
-A, –all-databases Dump all the databases. This will be same as –databaseswith all databases selected.
add-drop-database Add a ‘DROP DATABASE’ before each create.
add-drop-table Add a ‘drop table’ before each create.
add-locks Add locks around insert statements.
allow-keywords Allow creation of column names that are keywords.
create-options Include all MySQL specific create options.
e, –extended-insert Allows utilization of the new, much faster INSERT syntax.
p, –password[=name] Password to use when connecting to server. If password is not given it’s solicited on the tty.
u, –user=name User for login if not current user.
Bien, ahora colocamos un ejemplo de su uso:
#Respaldando una única base de datos
mysqldump -uroot -p –all –add-locks -e mibase > bkmibase.sql;
#Respaldar todas mis bases de datos
mysqldump -uroot -p –all –all-databases –add-locks -e > bkmisbases.sql;
#Nos conectamos a mysql
mysql -uroot -p
USE mibase;
source /path/TO/mibase.sql;
Como comentario para importar tablas tipo innodb se recomienda agregar:
SET FOREIGN_KEY_CHECKS=0;
Al inicio del archivo y al final con el fin de no obtener errores.
SET FOREIGN_KEY_CHECKS=1;
Soporte para Control de Transacciones y Recuperación de Fallas
Se conoce como transacción toda operación que se haga sobre la base de datos. Las transacciones deben por lo tanto ser controladas de manera que no alteren la integridad de la base de datos. La recuperación de fallas tiene que ver con la capacidad de un sistema DBMS de recuperar la información que se haya perdido durante una falla en el software o en el hardware.
5.4.7 Comandos para Recuperación
Hacer una Copia de Seguridad
El comando a utilizar es mysqldump que tiene la siguiente sintaxis:
mysqldump -u [user] -p [dbname] > [backup.sql]
Puesto que se pretende obtener un “foto fija” de la base de datos, es conveniente evitar que un acceso inoportuno pueda dejar el fichero volcado es un estado inconsistente. Esto se puede conseguir con varias opciones, aunque la recomendada es --single-transaction.
Recuperar la Base de Datos desde un Fichero
Se utiliza el método habitual para ejecutar sentencias SQL desde un fichero. Para el ejemplo sería:
# mysql -u admin -p drupal < drupal_backup.sql
5.4.8 Ventajas y Desventajas de cada Método
Ventajas
• Facilidad de manejo de grandes volúmenes de información.
• Gran velocidad en muy poco tiempo.
• Independencia del tratamiento de información.
• Seguridad de la información (acceso a usuarios autorizados), protección de información, de modificaciones, inclusiones, consulta.
• No hay duplicidad de información, comprobación de información en el momento de introducir la misma.
• Integridad referencial el terminar los registros.
Desventajas
• El costo de actualización del hardware y software son muy elevados.
• Costo (salario) del administrador de la base de datos es costoso.
• El mal diseño de esta puede originar problemas a futuro.
• Un mal adiestramiento a los usuarios puede originar problemas a futuro.
• Si no se encuentra un manual del sistema no se podrán hacer relaciones con facilidad.
• Generan campos vacíos en exceso.
• El mal diseño de seguridad genera problemas.
5.4.9 Aplicación de cada Método
Copia Simple
Puede ser aplicado en situaciones en las que no requiera de varias instancias o datos duplicados, como una Red de Oficina.
Copia Doble
Cuando requiera de un soporte estable y práctico a la hora de fallos en el sistema.
Ejemplo:
Supóngase que se deterioró físicamente parte del disco, afectando la aplicación. Por lo cual es necesario recuperarla. Se toma el primer juego de respaldo, se intenta hacer la copia del respaldo al disco y aparece error de lectura en el respaldo. Se usa entonces el segundo juego y ocurre lo mismo. Al analizar lo ocurrido se detecta que además de haberse deteriorado el disco, está dañada la unidad encargada de grabar los respaldos y al tratar de leer los mismos los daña.
Resultado:
La aplicación en disco no funciona y los dos juegos de respaldo quedaron inutilizados. De aquí se concluye la necesidad de hacer otra copia del respaldo, antes de intentar la recuperación.
Copia Generacional
Cuando este contenga mayores instancias y requiera de un gran rendimiento de los datos, como los Bancos.
No hay comentarios.:
Publicar un comentario