Skip navigation links
5.8.2 Ejemplo de estrategia de copias de seguridad y recuperación »
Section Navigation      [Toggle]

5.8.1. Copias de seguridad de bases de datos

Debido a que las tablas de MySQL se almacenan como archivos, es fácil hacer una copia de seguridad. Para hacer una copia consistente haga un LOCK TABLES en las tablas relevantes, seguido de un FLUSH TABLES para las tablas. Consulte Sección 13.4.5, “Sintaxis de LOCK TABLES y UNLOCK TABLES” y Sección 13.5.5.2, “Sintaxis de FLUSH”. Solo necesita obtener un bloqueo de lectura; esto permite a otros clientes continuar consultando la tabla mientras usted está haciendo una copia de los archivos del directorio de la base de datos. La sentencia FLUSH TABLES es necesaria para asegurarse de que todas las páginas de índice activas se escriben al disco antes de que comience la copia.

Si quiere hacer una copia de una tabla a un nivel SQL, puede utilizar SELECT INTO ... OUTFILE o BACKUP TABLE. Para SELECT INTO ... OUTFILE, el archivo de salida no debe existir previamente. Esto también es cierto para BACKUP TABLE, ya que permitir que archivos externos sean sobreescritos sería un riesgo de seguridad. Consulte Sección 13.2.7, “Sintaxis de SELECT” y Sección 13.5.2.2, “Sintaxis de BACKUP TABLE”.

Otra técnica para hacer copias de seguridad de una base de datos es utilizar el programa mysqldump o el script mysqlhotcopy script. Consulte See Sección 8.7, “El programa de copia de seguridad de base de datos mysqldump” y Sección 8.8, “El programa de copias de seguridad de base de datos mysqlhotcopy”.

  1. Hacer una copia completa de su base de datos: 

    shell> mysqldump --tab=/path/to/some/dir --opt db_name

    O: 

    shell> mysqlhotcopy db_name /path/to/some/dir

    También puede simplemente copiar todos los archivos de tablas (*.frm, *.MYD, y *.MYI) siempre que el servidor no esté actualizando nada. El script mysqlhotcopy utiliza este método. (Pero tenga en cuenta que estos métodos no funcionan si su base de datos contiene tablas InnoDB. InnoDB no almacena los contenidos de las tablas en directorios de base de datos, y mysqlhotcopy funciona solo para tablas MyISAM e ISAM.)

  2. Pare mysqld si se está ejecutando, y después reinicielo con la opción --log-bin[=file_name]. Consulte Sección 5.10.3, “El registro binario (Binary Log)”. Los archivos binarios de registro le dan la información que necesita para replicar los cambios que se han producido en la base de datos tras el punto en que usted ejecutó mysqldump.

Para las tablas InnoDB es posible realizar una copia de seguridad en línea que no requiere bloqueos en las tablas; consulte Sección 8.7, “El programa de copia de seguridad de base de datos mysqldump”

MySQL tiene soporte para copias de seguridad incrementales: Usted necesita iniciar el servidor con la opción --log-bin para activar el registro binario; consulte Sección 5.10.3, “El registro binario (Binary Log)”. En el momento en que usted quiera realizar una copia de seguridad incremental (que contenga todos los cambios que han ocurrido desde la última copia de seguridad, completa o incremental), usted debe rotar el registro binario utilizando FLUSH LOGS. Hecho esto, necesita copiar a la localización de seguridad todos los registros binarios que daten desde el momento de la última copia de seguridad hasta el último. Estos logs binarios son la copia de seguridad incremental; cuando necesite restaurar la copia, los puede aplicar tal como se explica más adelante. La próxima vez que haga una copia de seguridad compelta, también debe rotar el registro binario haciendo FLUSH LOGS, mysqldump --flush-logs, o mysqlhotcopy --flushlogs. Consulte Sección 8.7, “El programa de copia de seguridad de base de datos mysqldump” y Sección 8.8, “El programa de copias de seguridad de base de datos mysqlhotcopy”.

Si su servidor MySQL es un servidor esclavo de replicación, entonces independientemente del método de copia de seguridad que elija, también debe copiar los archivos master.info y relay-log.info cuando copie los datos de su esclavo. Estos archivos son siempre necesarios para continuar la replicación después de una restauración de los datos del esclavo. Si su esclavo está replicando comandos LOAD DATA INFILE, debería también copiar cualquier archivo SQL_LOAD-* que pueda existir en el directorio especificado por la opción --slave-load-tmpdir. (Esta localización es por defecto el valor de la variable tmpdir, si no se especifica.) El esclavo necesita estos archivos para reiniciar la replicación de cualquier operación LOAD DATA INFILE interrumpida.

Si tiene que restaurar tablas MyISAM, intente recuperarlas utilizando REPAIR TABLE o myisamchk -r primero. Esto debería funcionar en el 99.9% de los casos. Si myisamchk falla, intente el siguiente procedimiento. Tenga en cuenta que solo funciona si tiene activado el registro binario iniciando el servidor MySQL con la opción --log-bin; consulte Sección 5.10.3, “El registro binario (Binary Log)”.

  1. Restaure la copia de seguridad original de mysqldump, o la copia de seguridad binaria.

  2. Ejecute el siguiente comando para ejecutar de nuevo las actualizaciones de los registros binarios: 

    shell> mysqlbinlog hostname-bin.[0-9]* | mysql

    En algunos casos, quizá quiera reejecutar solo ciertos registros binarios, desde ciertas posiciones (lo usual es querer reejecutar todos los registros binarios desde el punto de restauración, excepto, posiblemente, algunas sentencias incorrectas). Consulte Sección 8.5, “La utilidad mysqlbinlog para registros binarios” para más información sobre la utilidad mysqlbinlog y como utilizarla.

También puede hacer copias de seguridad selectivas de archivos individuales:

  • Para volcar la tabla, utilice SELECT * INTO OUTFILE 'file_name' FROM tbl_name.

  • Para recargar la tabla, restaurela con LOAD DATA INFILE 'file_name' REPLACE ... Para evitar registros duplicados, la tabla tiene que tener un índice PRIMARY KEY o UNIQUE. La palabra clave REPLACE hace que los viejos registros sean reemplazados con los nuevos cuando un nuevo registro tiene la misma clave que uno antiguo.

Si tiene problema de rendimientos con su servidor mientras realiza copias de seguridad, una estrategia que puede ayudarle es crear replicación y hacer las copias de seguridad en el esclavo en vez de en el maestro. Consulte Sección 6.1, “Introducción a la replicación”.

Si está utilizando un sistema de ficheros Veritas, puede hacer una copia de seguridad así:

  1. Desde un programa cliente, ejecute FLUSH TABLES WITH READ LOCK.

  2. Desde otra línea de comandos, ejecute mount vxfs snapshot.

  3. Desde el primer cliente, ejecute UNLOCK TABLES.

  4. Copie los archivos de la captura (snapshot).

  5. Desmonte la captura.

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