jueves, 23 de junio de 2011

Técnicas de Recuperación de Bases de Datos

Conceptos de Recuperación
Descripción de la Recuperación y Clasificación de los Algoritmos  de Recuperació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 las 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 ultima alcance su punto  de confirmación.

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 cache (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 cache o en búfer en la memoria principal, Normalmente se reserva una colección de búferes en memoria, denominados cache 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 cache se está accediendo actualmente.
Actualización en el lugar (in place) escribe en el búfer el mismo 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 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

1 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! Interrogación 10000?: no sabemos si la información está en disco o en memoria


1.1   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. 
 

  1.2   Actualización Diferida con ejecución concurrente en un entorno  multiusuario

 
Planificación de la ejecución de las transacciones 
Cuando se tomo el punto de control en el momento t1 la transacción T1 se habría confirmado.

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:
  • Ti debe deshacerse si el diario contiene el registro starts pero no el commit.
  • 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.

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

1.       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.

2.       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.

3.       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:
  • Copia de seguridad (backup) más reciente de la BD (Debe existeir).
  • 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.

 

 

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 mas 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;

Ok, ya tenemos nuestro respaldo ahora: ¿como la importamos? pues bien para cargarlo existen varias formas aquí les presento una que nos sirve bastante:

    #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.