RECUPERAR

La clave de una administración de bases de datos segura es realizar copias de respaldo regularmente.

InnoDB Hot Backup es una herramienta de respaldo en línea que puede utilizarse para respaldar la base de datos InnoDB mientras ésta se está ejecutando. InnoDB Hot Backup no necesita que se detenga la base de datos y no establece ningún bloqueo ni dificulta el normal procesamiento de la base de datos. InnoDB Hot Backup es una herramienta adicional comercial (no grautita) cuyo cargo anual de licencia es de €390 por cada ordenador en el que se ejecute el servidor MySQL. Consulte la página de Internet de InnoDB Hot Backup para obtener información detallada y ver capturas de pantallas.

Si se está en condiciones de detener el servidor MySQL, puede realizarse una copia de respaldo binaria, que consiste en todos los ficheros usados por InnoDB para administrar sus tablas. Se utiliza el siguiente procedimiento:

Detener el servidor MySQL y asegurarse de que lo hace sin errores.

Copiar todos los ficheros de datos (ficheros ibdata e .ibd) en un lugar seguro.

Copiar todos los ficheros ib_logfile en un lugar seguro.

Copiar el o los ficheros de configuración my.cnf en un lugar seguro.

Copiar todos los ficheros .frm de las tablas InnoDB en un lugar seguro.

La replicación funciona con tablas InnoDB, de forma que puede emplearse para mantener una copia de la base de datos en sitios de bases de datos que necesiten alta disponibilidad.

Adicionalmente a la realización de copias de respaldo binarias como se ha descripto, también se deberían realizar regularmente volcados de las tablas con mysqldump. El motivo de esto es que un fichero binario podría corromperse sin que el usuario lo note. El volcado de las tablas se almacena en ficheros de texto que son legibles por los seres humanos, facilitando la localización de corrupción en las tablas. Además, puesto que el formato es más simple, las probabilidades de una corrupción seria de datos son menores. mysqldump también tiene una opción --single-transaction que puede usarse para capturar una imagen consistente de la base de datos sin bloquear otros clientes.

Para estar en condiciones de recuperar una base de datos InnoDB a partir del respaldo binario descripto anteriormente, se debe ejecutar el servidor MySQL con el registro binario (binary logging) activo. Entonces se puede aplicar el log binario al respaldo de la base de datos para lograr la recuperación a una fecha y hora determinadas:

mysqlbinlog nombre_de_host-bin.123 | mysql

Para recuperarse de una caida del servidor, sólo se requiere reiniciarlo. InnoDB verifica automáticamente los registros (logs) y ejecuta una recuperación de la base de datos del tipo roll-forward, es decir, hasta el momento anterior a la falla. InnoDB revierte automáticamente las transacciones no grabadas que existían al momento de la caída. Durante la recuperación, mysqld muestra información parecida a esta:

InnoDB: Database was not shut down normally.

InnoDB: Starting recovery from log files...

InnoDB: Starting log scan based on checkpoint at

InnoDB: log sequence number 0 13674004

InnoDB: Doing recovery: scanned up to log sequence number 0 13739520

InnoDB: Doing recovery: scanned up to log sequence number 0 13805056

InnoDB: Doing recovery: scanned up to log sequence number 0 13870592

InnoDB: Doing recovery: scanned up to log sequence number 0 13936128

...

InnoDB: Doing recovery: scanned up to log sequence number 0 20555264

InnoDB: Doing recovery: scanned up to log sequence number 0 20620800

InnoDB: Doing recovery: scanned up to log sequence number 0 20664692

InnoDB: 1 uncommitted transaction(s) which must be rolled back

InnoDB: Starting rollback of uncommitted transactions

InnoDB: Rolling back trx no 16745

InnoDB: Rolling back of trx no 16745 completed

InnoDB: Rollback of uncommitted transactions completed

InnoDB: Starting an apply batch of log records to the database...

InnoDB: Apply batch completed

InnoDB: Started

mysqld: ready for connections

Si la base de datos se corrompe o falla el disco, habrá que efectuar la recuperación desde una copia de respaldo. En el caso de corrupción, primero habría que encontrar una copa de respaldo realizada antes de la corrupción. Luego de restaurar la copia de respaldo base, debe realizarse la recuperación a partir de los ficheros de registro binario.

En algunos casos de corrupción de base de datos es suficiente con volcar, eliminar, y volver a crear una o unas pocas tablas corruptas. Se puede emplear la sentencia SQL CHECK TABLE para verificar si una tabla está corrupta, aunque CHECK TABLE, naturalmente, no puede detectar cada posible clase de corrupción. Se puede emplear innodb_tablespace_monitor para verificar la integridad de la gestión de espacio de ficheros dentro de los ficheros de espacio de tablas.

En algunos casos, una aparente corrupción de página de base de datos se debe en realidad a que el sistema operativo está corrompiendo su propio cache de ficheros, y los datos en el disco podrían estar en buenas condiciones. Lo mejor es, antes que nada, intentar el reinicio del ordenador. Ello puede eliminar errores que dan la sensación de tener corrupción en la página de base de datos.