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.
Ésta es una traducción del manual de referencia de MySQL, que puede encontrarse en dev.mysql.com. El manual de referencia original de MySQL está escrito en inglés, y esta traducción no necesariamente está tan actualizada como la versión original. Para cualquier sugerencia sobre la traducción y para señalar errores de cualquier tipo, no dude en dirigirse a mysql-es@vespito.com.