Recuperar una única tabla InnoDB del backup

Una de las ventajas de usar MySQL con los parches de percona es la gran cantidad de utilidades que han desarrollado entorno a él para que sea mucho más fácil el trabajo diario. Una de estas utilidades es xtrabackup, una utilidad que sirve para realizar backup's de las información de forma incremental y sin parar el servidor de base de datos. xtrabackup obtiene los datos y los prepara para ser importados, pero no lo hace como mysqldump, sino que se basa más en copia de ficheros directamente. Sin embargo, InnoDB almacena información importante de las tablas en otros ficheros por lo que una copia del directorio que contenga la base de datos no sirve como copia de respaldo y por lo tanto, tampoco sirve para recuperar una tabla de una base de datos.

Para explicar cómo hacer estos, partimos de una instalación del mysql de percona, con una base de datos llamada zabbix, de la que ya hablamos en otros comentarios, por ejemplo.

Para que todo funciona, la configuración del servidor tiene que ser algo especial y cumplir los siguientes puntos:

• La variable innodb_file_per_table tiene que estar activada
• La variable innodb_fast_shutdown tiene que estar a 0
• Desde que se realice la copia no se puede realizar ningún cambio (drop, alter, truncate) en el schema de la tabla

Partiendo de estas premisas entonces, realizamos el backup o copia de los datos de nuestra base de datos. Para ello empleamos la utilidad innobackupex.

shell> innobackupex
       --defaults-file=/etc/my.cnf
       --export /var/backups/

Luego, aplicamos los log's, para tener una copia de seguridad coherente.

shell> innobackupex
       --defaults-file=/etc/my.cnf
       --apply-log
       --export /var/backups/2012-01-26_19-50-17/

Llegados a este punto, tenemos una copia de nuestras tablas InnoDB para poder restaurarlas en el punto de la copia, por lo tanto, vamos ahora a forzar el uso de dicha copia. Para ellos, comprobamos algunos valores de la tabla y los borramos, para tener algo que restaurar.

mysql> SELECT actionid,userid,sendto 
       FROM alerts 
       WHERE sendto='javier@example.com';
+----------+--------+--------------------+
| actionid | userid | sendto             |
+----------+--------+--------------------+
|        7 |     10 | javier@example.com |
|        7 |     10 | javier@example.com |
|        5 |     10 | javier@example.com |
+----------+--------+--------------------+
3 rows in set (0.01 sec)

mysql> DELETE FROM alerts WHERE sendto='javier@example.com';

Llegados aquí, la restauración de los datos ya es necesario, ya que los 'perdimos'. Como ahora interesa recuperarlos, tenemos que hacer lo siguiente.

1. Descartamos el tablespace de la tabla

   mysql> ALTER TABLE alerts DISCARD TABLESPACE;
   

2. Copiamos el fichero alerts.ibd desde el backup

   shell> cp /var/backups/2012-01-26_19-50-17/zabbix/alerts.ibd \
          /srv/mysql/zabbix/
   

3. Importamos el nuevo tablespace

   mysql> ALTER TABLE alerts IMPORT TABLESPACE;
   

4. Comprobamos su correcto funcionamiento

   mysql> SELECT actionid,userid,sendto
          FROM alerts
          WHERE sendto='javier@example.com';
   +----------+--------+--------------------+
   | actionid | userid | sendto             |
   +----------+--------+--------------------+
   |        7 |     10 | javier@example.com |
   |        7 |     10 | javier@example.com |
   |        5 |     10 | javier@example.com |
   +----------+--------+--------------------+
   3 rows in set (0.01 sec)
   

Con este pequeño truco, como se puede observar conseguimos de una forma muy simple tratar las tablas InnoDB como tablas MyISAM, aunque de forma un poco más compleja.

Más info en: MySQL Performance Blog

Leer más

MySQL: backup de schema

En una entrada anterior hablamos de cómo realizar un backup de los procedimientos de MySQL, en esta realizaremos el backup del schema de la base de datos, para aquellos casos en los que los datos no son lo más importante, pero sí el schema.
Para realizarlo, se usará el comando mysqldump, con la opción "--no-data".

shell> mysqldump -u root -p --no-data db_name > schema.db_name.sql

Leer más