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
ibdatae.ibd) en un lugar seguro. -
Copiar todos los ficheros
ib_logfileen un lugar seguro. -
Copiar el o los ficheros de configuración
my.cnfen un lugar seguro. -
Copiar todos los ficheros
.frmde las tablasInnoDBen 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.
Si hay corrupción de página de base de datos, es posible que se desee
hacer un volcado de tablas desde la base de datos con SELECT
INTO OUTFILE; usualmente, la mayoría de los datos obtenidos de
esta manera están intactos. Aún así, la corrupción puede hacer que
SELECT * FROM tbl_name o
las operaciones en segundo plano de InnoDB caigan o,
incluso activar la recuperación roll-forward de
InnoDB. Sin embargo, se puede forzar el motor de
almacenamiento de InnoDB para que se inicie mientras se
evitan las operaciones en segundo plano, de forma que se pueda realizar
un volcado de las tablas. Por ejemplo, puede agregarse la siguiente
linea a la sección [mysqld] del fichero de opciones
antes de reiniciar el servidor:
[mysqld] innodb_force_recovery = 4
Debajo se listan los valores mayores a cero permitidos para
innodb_force_recovery. Un número mayor incluye todas
las precauciones de los números por debajo. Si se logra hacer un volcado
de tablas con un valor de a lo sumo 4, se puede estar relativamente
seguro de que solamente se han perdido algunos datos en páginas
individuales corruptas. Un valor de 6 es más dramático, porque las
páginas de base de datos han quedado obsoletas, lo que a su vez puede
introducir más corrupción en B-trees y otras estructuras de bases de
datos.
-
1(SRV_FORCE_IGNORE_CORRUPT)Le permite al servidor ejecutarse aún si detecta una página corrupta; intenta hacer que
SELECT * FROMtbl_namesalte sobre los registros de índice y páginas corruptos, lo cual es de ayuda en el volcado de las tablas. -
2(SRV_FORCE_NO_BACKGROUND)Impide que se ejecute el subproceso (thread) principal. Si durante la operación de descarga (purge) ocurriese una caida, esto la previene.
-
3(SRV_FORCE_NO_TRX_UNDO)No revierte transacciones luego de la recuperación.
-
4(SRV_FORCE_NO_IBUF_MERGE)También evita las operaciones de combinación del buffer de inserciones. Si ello pudiese causar una caida, es mejor no hacerlo; no calcula estadísticas de tablas.
-
5(SRV_FORCE_NO_UNDO_LOG_SCAN)No tiene en cuenta el contenido de los registros para revertir cambios (undo logs) al iniciar la base de datos:
InnoDBconsidera como confirmadas inclusive a las transacciones incompletas. -
6(SRV_FORCE_NO_LOG_REDO)Omite la creación del registro (log) que permite la recuperación de tipo roll-forward.
En otro caso la base de datos no debe emplearse con ninguna de
estas opciones habilitadas. Como una medida de seguridad,
InnoDB impide que los usuarios lleven a cabo
operaciones INSERT, UPDATE, o
DELETE cuando
innodb_force_recovery está configurado en un valor
mayor a 0.
Se pueden ejecutar sentencias DROP y
CREATE para eliminar y crear tablas incluso cuando se
está empleando la recuperación forzada. Si se sabe que una determinada
tabla está provocando caídas al hacer una cancelación (rollback), se la
puede eliminar. También puede utilizarse para detener una cancelación
fuera de control causada por una importación o un ALTER
TABLE en masa. Se puede interrumpir el proceso
mysqld y establecer
innodb_force_recovery a un valor de
3 para poner a funcionar la base de datos sin que
ejecute cancelación (rollback), luego emplear DROP
para eliminar la tabla que está causando la cancelación fuera de
control.
InnoDB implementa un mecanismo de puntos de
verificación llamado fuzzy checkpoint (punto de
verificación difuso). InnoDB descarga las páginas
modificadas de la base de datos desde el pool de buffers en lotes
pequeños. No es necesario descargar al disco el pool de buffers en una
sola acción, lo cual en la práctica podría detener temporalmente el
procesamiento de sentencias SQL del usuario.
Durante la recuperación de caídas, InnoDB busca un
marcador de checkpoint escrito en los ficheros de registro (log). Ya
sabe que todas las modificaciones a la base de datos anteriores al
marcador están presentes en la imagen en disco de la misma.
Entonces InnoDB recorre los ficheros de registro
(log) desde el checkpoint hacia adelante, aplicando sobre la base de
datos las modificaciones registradas.
InnoDB escribe en los ficheros de registro en una
forma rotativa. Todas las modificaciones confirmadas que hagan a
las páginas de la base de datos en el pool de buffers diferentes de las
grabadas en disco deben estar disponibles en los ficheros de registro en
caso de que InnoDB tenga que hacer una recuperación.
Esto significa que cuando InnoDB comienza a
reutilizar un fichero de registro, tiene que asegurarse de que las
imágenes en disco de las páginas de base de datos contienen las
modificaciones asentadas en el fichero de registro que se va a
reutilizar. En otras palabras, InnoDB debe crear un
punto de verificación (checkpoint) y esto a menudo implica la descarga a
disco de las páginas de base de datos modificadas.
La descripción anterior explica porqué hacer los ficheros de registro muy grandes puede ahorrar operaciones de E/S en disco destinadas a la creación de puntos de verificación. A menudo se hace hincapié en establecer el tamaño total de los ficheros de registro en lo mismo que el pool de buffers o aún más grande. La desventaja que tienen los ficheros de registro grandes es que la recuperación ante una caída puede tomar más tiempo debido a que hay más información que debe aplicarse a la base de datos.