5.8. Prevención de desastres y recuperaciones

MySQL 5.0

previous page next page

5.8. Prevención de desastres y recuperaciones

Esta sección explica como hacer copias de seguridad (completas e incrementales) y como realizar mantenimiento de tablas. La sintaxis de las sentencias SQL descritas aquí se detalla en Sección 13.5, “Sentencias de administración de base de datos”. La mayor parte de la información aquí contenida se aplica principalmente a tablas . Los procedimientos de copia de seguridad para se explican en Sección 15.8, “Hacer una copia de seguridad y recuperar una base de datos ”.

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 en las tablas relevantes, seguido de un para las tablas. Consulte Sección 13.4.5, “Sintaxis de y ” y Sección 13.5.5.2, “Sintaxis de ”. 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 es necesaria para asegurarse de que todas las páginas de índice activas se escriben al disco antes de qeu comience la copia.

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

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= --opt

    O: 

    shell> mysqlhotcopy

    También puede simplemente copiar todos los archivos de tablas (, , y ) 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 . no almacena los contenidos de las tablas en directorios de base de datos, y mysqlhotcopy funciona solo para tablas e .)

  2. Pare mysqld si se está ejecutando, y después reinicielo con la opción . 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 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 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 . 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 , , o . 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 y 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 , debería también copiar cualquier archivo que pueda existir en el directorio especificado por la opción . (Esta localización es por defecto el valor de la variable , si no se especifica.) El esclavo necesita estos archivos para reiniciar la replicación de cualquier operación interrumpida.

Si tiene que restaurar tablas , intente recuperarlas utilizando 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 ; 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 ' FROM .

  • Para recargar la tabla, restaurela con Para evitar registros duplicados, la tabla tiene que tener un índice o . La palabra clave 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 .

  2. Desde otra línea de comandos, ejecute .

  3. Desde el primer cliente, ejecute .

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

  5. Desmonte la captura.

5.8.2. Ejemplo de estrategia de copias de seguridad y recuperación

Esta sección explica un procedimiento para realizar copias de seguridad que le permiten recuperar datos tras diferentes tipos de problemas:

  • Fallo del sistema operativo

  • Fallo de energía

  • Fallo del sistema de ficheros

  • Problema de hardware (disco duro, placa madre, etc)

Los comandos de ejemplo no incluyen opciones como y para los programas mysqldump y mysql. Usted debería incluir las opciones que sean necesarias para que el servidor MySQL le permita conectarse.

Asumiremos que los datos están almacenados en el motor de MySQL, que tiene soporte para transacciones y recuperación automática de fallos. Siempre asumiremos que el servidor MySQL está bajo carga de trabajo en el momento del fallo. Si no fuera así, no se necesitaría ninguna recuperación.

Para casos de fallos de energía o de sistema operativo, podemos asumir que el disco de datos de MySQL está disponible tras el reinicio. Puede que entonces los archivos de datos de no contengan datos consistentes debido al fallo, pero lee sus registros y encuentra en ellos la lista de transacciones confirmadas y no confirmadas qeu todavía no han sido volcadas a sus archivos de datos, y los vuelca. La información sobre este proceso de recuperación de errores se le muestra al usuario a través del registro de errores de MySQL. Lo siguiente, es un extracto de ejemplo del registro: 

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

En casos de fallos del sistema de fichero o de hardware, podemos asumir que el disco de datos de MySQL no está disponible tras el reinicio. Esto significa que MySQL no puede arrancar normalmente porque algunos bloques de datos del disco no son legibles. En este caso, es necesario reformatear el disco, instalar uno nuevo, o en cualquier caso, corregir el problema subyacente. Después es necesario recuperar nuestros datos de MySQL desde copias de seguridad, lo que significa que tenemos que tener copias ya realizadas. Para asegurarse de que sea así, vayamos hacia atrás en el tiempo y diseñemos una política de copias de seguridad.

5.8.2.1. Política de copias de seguridad

Todos sabemos que las copias de seguridad deben programarse periodicamente. Las copias completos (una captura del estado de los datos en un momento del tiempo) puede hacerse con diferentes herramientas, en MySQL. Por ejemplo, nos provee con una copia de seguridad en línea sin bloqueos de los archivos de datos de , y con mysqldump obtenemos copias de seguridad lógicas online. En esta explicación utilizaremos mysqldump.

Supongamos que hacemos una copia de seguridad el domingo, a las 1 PM, cuando la carga es baja. El siguiente comando hace un hace una copia de seguridad completa de todas nuestras tablas de todas las bases de datos: 

shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql

Esto es una copia de seguridad en línea, sin bloqueos, que no molesta a las lecturas y escrituras de las tablas. Hemos supuesto antes que nuestras tablas son , así que hace una lectura consistente y garantiza que los datos vistos por mysqldump no cambian. (Los cambios hechos por otros clientes a las tablas no son vistas por el proceso mysqldump.) Si también tenemos otros tipos de tablas, debemos suponer que no han sido cambiadas durante la copia de seguridad. Por ejemplo, para las tablas en la base de datos , debemos suponer que no se estaban haciendo cambios administrativos a las cuentas MySQL durante la copia de seguridad.

El archivo resultante producido por el comando mysqldump contiene una serie de sentencias SQL que se pueden utilizar para recargar las tablas volcadas más tarde.

Las copias de seguridad completas son necesarias, pero no son siempre convenientes. Producen ficheros muy grandes y llevan tiempo generarse. No son óptimos en el sentido de que cada copia completa sucesiva incluye todos los datos, incluidas las partes que no han cambiado desde el último. Después de realizar una copia de seguridad completa inicial, es más eficiente hacer copias incrementales. Son más pequeñas, y llevan menos tiempo de realización. A cambio, en el momento de la recuperación, no podrá restaurarlo únicamente recargando la copia completa. También deberá procesar las copias incrementales para recuperar los cambios incrementales.

Para hacer copias de seguridad incrementales, necesitamos guardar los cambios incrementales. El servidor MySQL debería ser iniciado siempre con la opción para que almacene estos cambios en un archivo mientras actualiza los datos. Esta opción activa el registro binario, así que el servidor escribe cada sentencia SQL que actualiza datos en un archivo lllamado registro binario de MySQL. Miremos al directorio de datos de un servidor MySQL que fue iniciado con la opción y que se ha estado ejecutando durante algunos días. Encontramos estos archivos de registro binario: 

-rw-rw---- 1 guilhem  guilhem   1277324 Nov 10 23:59 gbichot2-bin.000001
-rw-rw---- 1 guilhem  guilhem         4 Nov 10 23:59 gbichot2-bin.000002
-rw-rw---- 1 guilhem  guilhem        79 Nov 11 11:06 gbichot2-bin.000003
-rw-rw---- 1 guilhem  guilhem       508 Nov 11 11:08 gbichot2-bin.000004
-rw-rw---- 1 guilhem  guilhem 220047446 Nov 12 16:47 gbichot2-bin.000005
-rw-rw---- 1 guilhem  guilhem    998412 Nov 14 10:08 gbichot2-bin.000006
-rw-rw---- 1 guilhem  guilhem       361 Nov 14 10:07 gbichot2-bin.index

Cada vez que se reinicia, el servidor MySQL crea un nuevo archivo de registro binario utilizando el siguiente número en la secuencia. Mientras el servidor se está ejecutando, podemos comunicarle manualmente que cierre el archivo de registro binario actual y comience otro nuevo, ejecutando la sentencia SQL o con el comando mysqladmin flush-logs. mysqldump también tiene una opción para volcar los logs. El archivo en el directorio de datos contiene la lista de todos los archivos de registro binario de MySQL en el directorio. Este archivo se utiliza para replicación.

El registro binario de MySQL es importante para la restauración, porque son copias incrementales de datos. Si se asegura de volcar los registros cuando hace su copia de seguridad completa, entonces cualquier registro binario creado tras esa copia contiene todos los cambios hechos desde entonces. Modifiquemos el comando mysqldump previo un poco para que vuelque los registros binarios de MySQL en el momento de la copia de seguridad completa, y para que el archivo de volcado contenga el nombre del registro binario actual: 

shell> mysqldump --single-transaction --flush-logs --master-data=2
           --all-databases > backup_sunday_1_PM.sql

Tras ejecutar este comando, el directorio de datos contiene un nuevo archivo de registro binario, . El archivo resultante contiene estas líneas: 

-- Position to start replication or point-in-time recovery from
-- CHANGE MASTER TO MASTER_LOG_FILE='gbichot2-bin.000007',MASTER_LOG_POS=4;

Como el comando mysqldump ha hecho una copia de seguridad completa, estas líneas significan dos cosas:

  • El archivo contiene todos los cambios hechos antes de cualquier cambio escrito al registro binario o posterior.

  • Todos los cambios registrados tras la copia de seguridad no están presentes en el archivo , pero lo están en el registro binario o posterior.

El lunes, a las 1 PM, podemos crear una copia de seguridad incremental volcando los registros para comenzar un nuevo registro binario. Por ejemplo, ejecutando un comando mysqladmin flush-logs creamos . Todos los cambios producidos entre el domingo a la 1 PM cuando se hizo la copia completa, y el lunes a la 1 PM están en el archivo . Esta copia incremental es importante, así que es una buena idea copiarla a un lugar seguro. (Por ejemplo, en cinta o DVD, o copiándolo a otra máquina.) El martes a la 1 PM, ejecute otro comando mysqladmin flush-logs. Todos los cambios desde el lunes a la 1 PM hasta el martes a la 1 PM están en el archivo (que también debería ser copiado a un lugar seguro).

Los registros binarios de MySQL ocupan espacio de disco. Para ligerar espacio, púrguelos de vez en cuando. Una manera de hacerlo es borrar los registros binarios que no se necesiten, como cuando hacemos una copia de seguridad completa: 

shell> mysqldump --single-transaction --flush-logs --master-data=2
           --all-databases --delete-master-logs > backup_sunday_1_PM.sql

Tenga en cuenta que: Borrar los registros binarios de MySQL con mysqldump --delete-master-logs puede ser peligroso si su servidor es un servidor maestro de replicación, porque los servidores esclavos pueden no haber procesado completamente los contenidos del registro binario.

La descripción de la sentencia explica lo que debe ser verificado antes de borrar los registros binarios de MySQL. Consulte Sección 13.6.1.1, “Sintaxis de ”.

5.8.2.2. Usar copias de seguridad para una recuperación

Ahora suponga que tenemos un fallo catastrófico el miércoles a las 8 AM que requiere restauración de las copias de seguridad. Para recuperarnos, primero restauramos la última copia de seguridad completa que tenemos (la del domingo a la 1 PM). El archivo de copia completo es tan solo una serie de sentencias SQL, así qeu restaurarlo es muy fácil: 

shell> mysql < backup_sunday_1_PM.sql

En este punto, el estado de los datos ha sido restaurado al del domingo a la 1 PM. Para restaurar los datos hechos desde entonces, debemos usar las copias incrementales, es decir los archivos de registro binario y . Extraigalos, si es necesario, de allá donde estuviesen guardados, y luego procese sus contenidos de la siguiente manera: 

shell> mysqlbinlog gbichot2-bin.000007 gbichot2-bin.000008 | mysql

Ahora hemos recuperado los datos hasta su estado del martes a la 1 PM, pero todavía hay cambios que faltan desde esa fecha hasta el momento del fallo. Para no perderlos, deberíamos haber hecho que el servidor MySQL almacenase sus registros MySQL en un lugar seguro (discos RAID, ...) diferente del lugar donde almacena sus archivos de datos, para que estos registros no estuvieran únicamente en el disco destruido. (Es decir, iniciar el servidor con la opción que especifique una localización en un dispositivo físico diferente del que contiene el directorio de datos. De esta manera, los registros no se pierden aún si el dispositivo que contiene el directorio sí.) Si hubiésemos hecho esto, podríamos tener el archivo a mano, y podríamos aplicarlo para restaurar hasta los cambios más recientes sin ninguna pérdida a como estaban en el momento del fallo.

5.8.2.3. Sumario de la estrategia de copias de seguridad

En caso de un fallo de sistema operativo o energía, hace todo el trabajo de restauración de datos por si mismo. Pero para asegurarse de que puede dormir bien, tenga en cuenta los siguientes puntos:

  • Ejecute siempre el servidor MySQL con la opción , o mejor aún , donde el archivo de registro está guardado en algún medio diferente al disco en donde está el directorio de datos. Si tiene un medio seguro tal, también puede ser bueno para hacer balanceo de carga de disco (que resulta en una mejora de rendimiento).

  • Haga copias de seguridad completas periodicas, utilizando el último comando mysqldump dado previamente, que hace una copia de seguridad en línea sin bloqueo.

  • Haga copias de seguridad incrementales periodicamente volcando los registros con o mysqladmin flush-logs.

5.8.3. Mantenimiento de tablas y recuperación de un fallo catastrófico (crash)

El siguiente texto explica como utilizar myisamchk para comprobar o reparar tablas (tablas con archivos and ).

Puede utilizar la utilidad myisamchk para obtener información sobre las tablas de su base de datos, o para comprobar, reparar u optimizarlas. Las siguientes secciones explican como invocar myisamchk (incluyendo una descripción de sus opciones), como establecer un calendario de mantenimiento de tablas, y como utilizar myisamchk para que realice sus diferentes funciones.

Aunque la reparación de tablas con myisamchk es bastante segura, siempre es una buena idea hacer una copia de seguridad antes de hacer una reparación (o cualquier operación de mantenimiento que pueda hacer muchos cambios a una tabla)

Las operaciones de myisamchk que afectan a índices pueden causar que los índices sean recreados con parámetros que son incompatibles con los valores utilizados por el servidor MySQL. Para evitar esto, lea las instrucciones en Sección 5.8.3.2, “Opciones generales demyisamchk”.

En muchos casos, podría encontrar más simple hacer el mantenimiento de las tablas utilizando las sentencias SQL que realizan las mismas operaciones que myisamchk:

  • Para comprobar o reparar tablas tables, use o .

  • Para optimizar tablas , use .

  • Para analizar tablas , use .

Estas sentencias pueden ser utilizadas directamente, o mediante el programa cliente mysqlcheck, que provee de una interfaz de línea de comandos.

Una de las ventajas de estas sentencias sobre myisamchk es que el servidor hace todo el trabajo. Con myisamchk, usted debe asegurare de que el servidor no utiliza las tablas al mismo tiempo. Si no es así, podría haber interacciones no deseadas entre myisamchk y el servidor.

5.8.3.1. Sintaxis para invocar myisamchk

Invoque myisamchk de la siguiente manera: 

shell> myisamchk []

Las especifican lo que quiere que myisamchk haga. Se describen en las secciones posteriores. También puede obtener una lista de las opciones invocando myisamchk --help.

Sin opciones, myisamchk simplemente comprueba la tabla, como operación por defecto. Para obtener más información, o decirle a myisamchk que tome medidas correctivas, especifique las opciones tal como se explica en la siguiente guía.

es el nombre de la tabla que quiere comprobar o reparar. Si ejecuta myisamchk desde otro lugar que no sea el directorio de la base de datos, debe especificar la ruta hasta este directorio, porque myisamchk no tiene la más mínima idea de en qué lugar se encuentra la base de datos. De hecho, myisamchk no se preocupa por si los archivos sobre los que trabaja se encuentran en un directorio de base de datos. Puede copiar los archivos que corresponden a la tabla en cualquier otro lugar, y hacer las operaciones de recuperación allí.

Puede invocar varios nombres de tablas en la línea de comandos de myisamchk, si lo desea. También puede especificar una tabla nombrando a su archivo de índices (el archivo con extensión ). Esto permite que especifique todas las tablas de un directorio utilizando el patrón . Por ejemplo, si se encuentra en un directorio de una base de datos, puede comprobar todas las tablas de ese directorio de la siguiente manera: 

shell> myisamchk *.MYI

Si no se encuentra en el directorio de la base de datos, puede comprobar todas las tablas especificando la ruta al directorio: 

shell> myisamchk /path/to/database_dir/*.MYI

Incluso se podría comprobar todas las tablas en todas las bases de datos especificando un comodín en la ruta a el archivo de datos MySQL: 

shell> myisamchk /path/to/datadir/*/*.MYI

La manera recomendada de comprobar rápidamente todas las tablas e es: 

shell> myisamchk --silent --fast /path/to/datadir/*/*.MYI
shell> isamchk --silent /path/to/datadir/*/*.ISM

Si usted quiere comprobar todas las tablas e y repararlas si alguna está corrompida, puede utilizar los siguientes comandos: 

shell> myisamchk --silent --force --fast --update-state \
          -O key_buffer=64M -O sort_buffer=64M \
          -O read_buffer=1M -O write_buffer=1M \
          /path/to/datadir/*/*.MYI
shell> isamchk --silent --force -O key_buffer=64M \
          -O sort_buffer=64M -O read_buffer=1M -O write_buffer=1M \
          /path/to/datadir/*/*.ISM

Estos comandos asumen que tiene más de 64MB libres. Para más información sobre reserva de memoria con myisamchk, consulte Sección 5.8.3.6, “Utilización de la memoria por parte de myisamchk”.

Debe asegurarse de que ningún otro programa está utilizando las tablas mientras ejecute myisamchk. Si no es así, cuando ejecute myisamchk, puede obtener el siguiente mensaje de error: 

warning: clients are using or haven't closed the table properly

Esto significa que está intentando comprobar una tabla que ha sido cambiada por otro programa (como podría ser el servidor mysqld) que no ha cerrado aún el archivo, o que ha muerto sin cerrar el archivo adecuadamente.

Si mysqld se está ejecutando, debe forzarlo a volcar cualquier modificación de tablas que todavía esté almacenada en memoria, utilizando . Debería entonces asegurarse de que nadie está utilizando las tablas sobre las que se ejecuta myisamchk. La manera más fácil de evitar este problema es utilizar en vez de myisamchk para comprobar las tablas.

5.8.3.2. Opciones generales demyisamchk

Las opciones descritas en esta sección pueden utilizarse para cualquier tipo de operación de mantenimiento de tabla realizada por myisamchk. Las secciones que siguen a la presente explican las opciones que pertenecen tan solo a operaciones específicas, como la comprobación o reparación de tablas.

  • Muestra un mensaje de ayuda y finaliza.

  • , -#

    Escribe un registro de depuración. La cadena suele ser frecuentemente '.

  • Modo silencioso. Escribe solo cuando ocurre algún tipo de error. Puede usar dos veces () para hacer que myisamchk sea muy silencioso.

  • Modo explícito. Imprime más información. Esto puede ser utilizado en conjunción con y . Utilice múltiples veces (, ) para producir aún más información.

  • Muestra información sobre la versión y finaliza.

  • En vez de terminar con un error si la tabla se encuentra bloqueada, espera a que la tabla se desbloquee antes de continuar. Tenga en cuenta que si está ejecutando mysqld con la opción , la tabla sólo puede haber sido bloqueada por otro comando myisamchk.

También puede establecer las variables utilizando = opciones:

Variable Valor por defecto
9
dependiente-de-versión
4
lista interna
523264
1024
262136
2097144
16
262136

Las posibles variables de myisamchk y sus valores por defecto pueden ser examinadas con myisamchk --help:

se utiliza cuando las claves son reparadas mediante ordenación, que es el caso normal cuando se utiliza .

se utiliza cuando se está comprobando una tabla con o cuando las claves se están reparando insertándolas registro a registro en la tabla (como cuando se hacen inserciones normales). La reparación a través del "key buffer" se utiliza en los siguientes casos:

  • Ha utilizado .

  • Los archivos temporales necesarios para ordenar las claves serían más del doble de grandes que cuando se crea el archivo de claves directmaente. Esto ocurre usualmente cuando hay valores grandes en la clave (tipos de columna como , , o ), porque la operación de ordenamiento necesita almacenar los valores de las claves por completo mientras procede. Si tiene mucho espacio temporal y puede forzar a que myisamchk repare mediante ordenación, puede utilizar la opción .

La reparación mediante el "key buffer" necesita mucho menos espacio de disco que utilizar ordenación, pero es también mucho más lenta.

Si quiere una reparación más rápida, establezca las variables y a un valor aproximadamente dle 25% de la memoria disponible. Puede subir ambas variables a un valor grande, porque solo se utiliza una de ellas a la vez.

es el tamaño utilizado para los bloques de índices.

y indican la longitud de palabra mínima y máxima para índices . indica un archivo de "palabra de parada". Esto necesita establecerse en las siguientes circunstancias.

Si utiliza myisamchk para realizar una operación que modifica los índices de las tablas (como una reparación o un análisis), los índices son reconstruidos utilizando el archivo de palabra de parada por defecto a menos que especifique lo contrario. Esto puede resultar en el fallo de sentencias.

El problema ocurre porque estos parámetros son sólo conocidos por el servidor. No están almacenados en los archivos de índices de . Para evitar el problema, si usted a modificado la longitud mínima o máxima de palabra, o el archivo de palabra de parada en el servidor, especifique los mismos valores de , , y para myisamchk que los que ha utilizado para mysqld. Por ejemplo, si ha establecido una longitud de palabra mínima de 3, puede reparar una tabla con myisamchk así: 

shell> myisamchk --recover --ft_min_word_len=3 .MYI

Para asegurarnos de que myisamchk y el servidor utilizan los mismos valores para los parámetros de full-text, podemos ponerlos en las secciones y de un archivo de opciones: 

[mysqld]
ft_min_word_len=3

[myisamchk]
ft_min_word_len=3

Una alternativa a utilizar myisamchk es usar las sentencias , , , o . Estas sentencias son ejecutadas por el servidor, que conoce los parámetros de full-text apropiados que debe utilizar.

5.8.3.3. Opciones de myisamchk para comprobar tablas

myisamchk soporta las siguientes opciones para las operaciones de comprobación de tablas:

  • Comprueba si hay errores en la tabla. Esta es la operación por defecto si no se especifica ninguna opción que seleccione la operación a realizar.

  • Comprueba sólo las tablas que han cambiado desde la última comprobación.

  • Comprueba la tabla muy concienzudamente. Esto es muy lento si la tabla tiene muchos índices. Esta opción debería ser utilizada únicamente en casos extremos. Normalmente, myisamchk o myisamchk --medium-check deberían ser capaces de determinar si hay algún error en la tabla.

    Si está utilizando y tiene bastante memoria, establecer un valor grande para la variable ayuda a que la operación de reparación vaya más rápido.

  • Comprueba solo las tablas qeu no han sido cerrados apropiadamente.

  • Realiza una operación de reparación automaticamente si myisamchk encuentra cualquier error en la tabla. El tipo de reparación es el mismo que el que se espcifica con la opción o .

  • Imprime estadísticas informativas sobre la tabla que se comprueba.

  • Realiza una comprobación que es más rápida que . Esta comprobación encuentra solo el 99.99% de todos los errores, lo que debería ser suficiente en la mayor parte de los casos.

  • No señala la tabla como comprobada. Esto es útil si utiliza myisamchk para comprobar una tabla que está siendo utilizada por otra aplicación que no utiliza bloqueos, como mysqld cuando se ejecuta con la opción .

  • Almacena información en el archivo para indicar que la tabla ha sido comprobada, o si la tabla tiene fallos. Esto debería utilizarse par obtener el máximo beneficio de la opción , pero no debería utilizarse esta opción si se está ejecutando el servidor mysqld, con la opción , y éste está utilizando la tabla.

5.8.3.4. Opciones de myisamchk para reparar tablas

myisamchk tiene soporte para las siguientes opciones en las operaciones de reparación de tablas:

  • Realiza una copia de seguridad del archivo con el formato

  • El directorio donde los juegos de carácteres están instalados. Consulte Sección 5.9.1, “El conjunto de caracteres utilizado para datos y ordenación”.

  • Corrige la información de checksum de la tabla.

  • , -D

    Longitud máxima del archivo de datos. (cuando se está reconstruyendo el archivo de datos porque está ``lleno'').

  • Realiza una reparación que intenta recuperar todos los registros posibles del archivo de datos. Normalmente esto también encuentra un montón de registros basura. No utilice esta opción al menos que esté desesperado.

  • Sobreescribe los archivos temporales viejos (archivos con nombres como .TMD) en vez de interrumpir la reparación.

  • , -k

    Para myisamchk, el valor de esta opción indica qué índices tiene que actualizar. Cada bit binario de la opción, corresponde a un índice de la tabla, donde el primer índice es el bit 0. Para isamchk, esta opción indica que sólo los primeros índices de la tabla deben ser actualizados. En cualquier caso, un valor de 0 en la opción desahbilita las actualizaciones a todos los índices, lo que puede ser utilizado para obtener inserciones más rápidas. Los índices desactivados pueden ser reactivados utilizando myisamchk -r.

  • No sigue los enlaces simbólicos. Normalmente repara una tabla que esté apuntada por un enlace simbólico. Esta opción no existe en MySQL 4.0, porque las versiones a partir de la 4.0 no eliminan los enlaces simbólicos durante las operaciones de reparación.

  • Utiliza la misma técnica que y , pero crea todas las claves en paralelo, utilizando hilos de ejecución diferentes. Esto es código en estado alpha. Utilícelo bajo su propia responsabilidad.

  • Consigue una reparación más rápida al no modificar el archivo de datos. Puede especificar esta opción dos veces para forzar a myisamchk a modificar el archivo original de datos en el caso de claves duplicadas.

  • Realiza una reparación que puede resolver casi cualquier problema, excepto las claves únicas que no son únicas (que es un error extremadamente raro en tablas ). Si quiere recuperar una tabla, esta es la primera opción a intentar. Debería intentar con sólo si myisamchk comunica que la tabla no puede recuperarse con . (En el improbable caso de que falle, el archivo de datos permanece intacto.)

    Si tiene memoria suficiente, debería incrementar el valor de .

  • Hace una reparación utilizando un méto de recuperación antiguo que lee todos los registros en orden y actualiza todos los árboles de índices basándose en los registros encontrados. Esto es de un orden de magnitud más lento que , pero puede gestionar un puñado de casos muy improbables que no puede. Este método de recuperación también utiliza mucho menos espacio de disco que . Normalmente debería reparar primero con , y luego utilizar solo si falla.

    Si tiene mucha memoria, debería incrementar el valor de .

  • Cambia el juego de carácteres utilizado por los índices de tabla. Esta opción fue reemplazada por en MySQL 5.0.3.

  • Cambia la colación utilizada para ordenar los índices de las tablas. El nombre del código de carácteres viene implícito en la primera parte del nombre de la colación. Esta opción fue añadida en MySQL 5.0.3.

  • Fuerza a que myisamchk utilice ordenación para establecer las claves aunque los archivos temporales puedan ser muy grandes.

  • , -t

    La ruta a el directorio que debe utilizarse para almacenar archivos temporales. Si no está establecida, myisamchk utiliza el valor de la variable de entorno . puede ser establecido como una lista de rutas de directorios que son utilizadas sucesivamente de una manera a lo "round-robin" para crear archivos temporales. El carácter de separación entre los nombres de directorio es el de dos puntos en Unix ('') y el punto y coma en Windows, Netware, y OS/2 ('').

  • Descomprime una tabla que fue comprimida con myisampack.

5.8.3.5. Otras opciones de myisamchk

myisamchk tiene soporte para las siguientes opciones en cuanto a acciones que no son comprobaciones ni reparaciones de tablas:

  • Analiza la distribución de las claves. Esto mejora el rendimiento de las join habilitando al optimizador de join para escober mejor el orden en que unirá las tablas y qué claves debería utilizar. Para obtener información sobre la distribución, utilice el comando myisamchk --description --verbose o la sentencia .

  • Imprime información descriptiva sobre la tabla.

  • ], -A[]

    Fuerza que la numeración auto incremental para los nuevos registros comience en un valor dado (o superior, si existen registros con valores autoincrementales tan altos). Si no está especificado, el incremente automático comienza con al valor más grande que haya actualmetne en la tabla, más uno.

  • Ordena los bloques de árboles de índices de mayor a menor. Esto optimiza las búsquedas y hace que el escaneo por clave de las tablas sea más rápido.

  • , -R

    Ordena los registros de acuerdo a un índice particular. Esto hace que sus datos están mucho más localizables y puede agilizar operaciones y basados en rangos que utilicen este índice. (La primera vez que utilice esta opción para ordenar una tabla, puede ser muy lento.) Para determinar los números de índices de una tabla, utilice , que muestra los índices de una tabla en el mismo orden en que myisamchk los ve. Los ínidces están numerados comenzando por 1.

5.8.3.6. Utilización de la memoria por parte de myisamchk

La reserva de memoria es importante cuando ejecute myisamchk. myisamchk no utiliza más memoria de la que se especifique con las opciones . Si usted va a utilizar myisamchk en tablas muy grandes, debería primero decidir cuanta memoria quiere utilizar. Por defecto, se utilizarán más o menos 3MB para realizar reparaciones. Utilizando valores más grandes, puede conseguir que myisamchk funcione más rápido. Por ejemplo, si tiene más de 32MB de RAM, podría utilizar estas otras opciones (además de las otras que pueda especificar): 

shell> myisamchk -O sort=16M -O key=16M -O read=1M -O write=1M ...

Utilizar probablemente sea suficiente para la mayoría de los casos.

Tenga en cuenta que myisamchk utiliza archivos temporales en . Si apunta a un sistema de ficheros en memoria, podría quedarse fácilmente sin memoria y obtener errores. Si esto ocurre, haga que apunte a algún directorio de un sistema de ficheros con más espacio y ejecute el comando myisamchk de nuevo.

Mientras está reparando, myisamchk también necesita mucho espacio de disco:

  • Doble el espacio del archivo de datos (el original y una copia). Este espacio no se necesitará si hace una reparación con la opción ; en este caso solo se reconstruye el archivo de índices (la copia se crea en el mismo directorio que el original.)

  • El espacio para el archivo de índices que reemplaza al viejo. El archivo de índices viejo se trunca en el inicio de la operación de reparación, así que usualmente este espacio se ignora. Este espacio debe estar en el mismo sistema de ficheros que el archivo de índices original.

  • Cuando utilice o (pero no al utilizar ), necesitará espacio para un buffer de ordenación. El espacio requerido es: 

    ( + ) *  * 2

    Puede comprobar la longitud de las claves y la longitud_de_puntero_a_registro con myisamchk -dv . Este espacio se reserva en el directorio temporal (especificado por o ).

Si tiene algún problema con el espacio de disco durante una reparación, puede intentar utilizar en vez de .

5.8.3.7. Usar myisamchk para recuperación de desastres

Si ejecuta mysqld con (lo que es la opción por defecto en algunos sistemas, como Linux), no puede utilizar myisamchk de manera segura para comprobar una tabla si mysqld está utilizando esta misma tabla. Si puede asegurarse de que nadie está accediendo a las tablas a través de mysqld mientras ejecuta myisamchk, entonces solo tendrá que hacer mysqladmin flush-tables antes de comenzar la comprobación de las tablas. Si no puede garantizar esto, entonces debe parar mysqld mientras comprueba las tablas. Si ejecuta myisamchk mientras mysqld está actualizando las tablas, puede obtener un aviso de que una tabla está corrupta aún cuando no sea así.

Si no está utilizando , puede utilizar myisamchk para comprobar tablas en cualquier momento. Mientras hace esto, todos los clientes que intenten actualizar la tabla esperarán hasta que myisamchk esté listo para continuar.

Si utiliza myisamchk para reparar u optimizar tablas, debe siempre asegurarse de que el servidor mysqld no está utilizando la tabla (esto es también aplicable cuando el usted esté utilizando ). Si no apaga mysqld, al menos debe hacer un mysqladmin flush-tables antes de ejecutar myisamchk. Sus tables podrían corromperse si el servidor y myisamchk acceden a las tablas simultáneamente.

Esta sección describe como comprobar y actuar si existe corrupción en bases de datos MySQL. Si sus tablas se corrompen frecuentemente, usted debería intentar encontrar la razón. Consulte Sección A.4.2, “Qué hacer si MySQL sigue fallando (crashing)”.

Para una explicación de como las tablas pueden corromperse, consulte Sección 14.1.4, “Problemas en tablas ”.

Cuando realice recuperación de fallos, es importante entender que cada tabla con nombre en una base de datos corresponde a tres archivos en el directorio de la base de datos:

Archivo Propósito
.frm Archivo de definición (formato)
.MYD Archivo de datos
.MYI Archivo de índices

Cada uno de estos tres tipos de archivos tiene un tipo de peligro de corrupción diferente, pero la mayoría de problemas ocurren más frecuentemente en los archivos de datos e índices.

myisamchk trabaja creando una copia de el archivo de datos registro a registro. Finaliza el estadio de reparación borrando el viejo archivo y renombrando el nuevo archivo a el nombre original. Si utiliza , myisamchk no crea un archivo temporal, sino que asume que el archivo está correcto y solo genera un nuevo archivo de índices sin tocar el archivo . Esto es seguro porque myisamchk automáticamente detecta sí el archivo está corrompido, y para la reparación si lo está. También puede especificar la opción dos veces. En este caso, myisamchk no aborta al encontrar algunos errores (como erroes de clave duplicada), sino que intenta resolverlo modificando el archivo . Normalmente, la utilización de dos opciones es útil sólo si tiene muy poco espacio libre para realizar una reparación normal. En este caso, al menos debería hacer una copia de seguridad antes de ejecutar myisamchk.

5.8.3.8. Cómo comprobar tablas en busca de errores

Para comprobar una tabla , utilice los siguientes comandos:

  • Esto encuentra el 99.99% de todos los errores. Lo que no puede encontrar es corrupción que involucre sólo al archivo de datos (lo que es muy inusual). Si quiere comprobar una tabla, normalmente debería ejecutar myisamchk sin opciones, o al menos con la opción o .

  • Esto encuentra el 99.999% de todos los errores. Primero comprueba todos los índices, y después lee todos los registros. Calcula en checksum para todas las claves en los registros, y verifica que coincida con el de las claves en el árbol de índices.

  • Esto hace una comprobación completa y exhaustiva de todos los datos ( significa ``comprobación extendida''). Hace una comprobación-lectura de la clave de cada registro para verificar que de hecho apuntan al registro correcto. Esto normalmente puede llevar mucho tiempo para una tabla grande que tenga muchos índices. Normalmente myisamchk se para tras el primer error que encuentra. Si quiere obtener más información, puede añadir la opción (). Esto causa que myisamchk durante un máximo de 20 errores.

  • Igual que el comando previo, pero la opción le dice a myisamchk que imprima también algunas estadísticas informativas.

En la mayoría de casos, un comando myisamchk sin más argumentos que el nombre de la tabla original es suficiente para comprobar la tabla.

5.8.3.9. Cómo reparar tablas

La discusión en esta sección describe cómo usar myisamchk en tablas (extensiones y ).

También puede ( y debe, si es posible) usar los comandos y para chequear y reparar tablas . Consulte Sección 13.5.2.3, “Sintaxis de ” y Sección 13.5.2.6, “Sintaxis de ”.

Los síntomas de tablas corruptas incluyen consultas que abortan inesperadamente y errores observables como los siguientes:

  • .frm is locked against change

  • Can't find file .MYI (Errcode: )

  • Unexpected end of file

  • Record file is crashed

  • Got error from table handler

Para obtener ejecución acerca de los errores puede ejectuar perror , donde es el número de error. El siguiente ejemplo muestra cómo usar perror para encontrar el significado de la mayoría de errores comunes que indican un problema con la tabla: 

shell> perror 126 127 132 134 135 136 141 144 145
126 = Index file is crashed / Wrong file format
127 = Record-file is crashed
132 = Old database file
134 = Record was already deleted (or record file crashed)
135 = No more room in record file
136 = No more room in index file
141 = Duplicate unique key or constraint on write or update
144 = Table is crashed and last repair failed
145 = Table was marked as crashed and should be repaired

Tenga en cuenta que el error 135 (no more room in record file) y el error 136 (no more room in index file) no son errores que puedan arreglarse con una simple reparación. En este caso, debe usar para incrementar los valores de las opciones de tabla y : 

ALTER TABLE  MAX_ROWS= AVG_ROW_LENGTH=;

Si no conoce los valores actuales de las opciones de tabla, use o .

Para los otros errores, debe reparar las tablas. myisamchk normalmente detecta y arregla la mayoría de problemas que ocurren.

El proceso de reparación incluye hasta cuatro etapas, descritas aquí. Antes de empezar, debe cambiar la localización al directorio de la base de datos y comprobar los permisos de los ficheros de las tablas. En Unix, asegúrese que puede leerlos el usuario con el que corre mysqld (y con su usuario, ya que necesita acceder a los ficheros que está comprobando). En caso que necesite modificar ficheros, debe tener también permiso de escritura.

Las opciones que puede usar para el mantenimiento de tablas con myisamchk y isamchk se describen en varias de las primeras subsecciones de Sección 5.8.3, “Mantenimiento de tablas y recuperación de un fallo catastrófico (crash)”.

La siguiente sección es para los casos en los que los comandos anteriores fallen o si quiere usar las características extendidas que myisamchk y isamchk proporcionan.

Si va a reparar una tabla desde la línea de comandos, debe parar el servidor mysqld en primer lugar. Tenga en cuenta que cuando ejectua mysqladmin shutdown en un servidor remoto, el servidor mysqld todavía está activo durante un periodo de tiempo una vez que mysqladmin devuelve el control, hasta que todas las consultas están paradas y todas las claves se han volcado a disco.

Etapa 1: Comprobación de tablas

Ejecute myisamchk *.MYI o myisamchk -e *.MYI si tiene más tiempo. Use la opción (silencio) para suprimir información innecesaria.

Si el servidor mysqld está parado, debe usar la opción para decirle a myisamchk que marque la tabla como 'comprobada'.

Debe reparar sólo las tablas en que myisamchk anuncia un error. Para estas tables, pase a la Etapa 2.

Si obtiene errores extraños al hacer la comprobación (tales como errores ), o si myisamchk cae, pase a la Etapa 3.

Etapa 2: Reparación sencilla

Nota: Si quiere que una operación de reparación sea mucho más rápida, debe cambiar los valores de las variables y al 25% aproximado de la cantidad de memoria disponible al ejecutar myisamchk o isamchk.

En primer lugar, intente myisamchk -r -q ( significa ``modod de recuperación rápido''). Intenta reparar el fichero de indexación sin tocar el fichero de datos. Si el fichero de datos contiene todo lo que debería y los vínculos de borrado apuntan a la localización correcta dentro del fichero de datos, esto debería funcionar, y la tabla estaría reparada. Empiece a reparar la siguiente tabla. Si no es así, use el siguiente procedimiento:

  1. Haga una copia de seguridad del fichero de datos antes de continuar.

  2. Use myisamchk -r ( significa ``modo de recuperación''). Esto elimina registros incorrectos y registros borrados del fichero de datos y recunstruye el fichero de indexación.

  3. Si el paso precedente falla, use myisamchk --safe-recover . El modo de recuperación seguro usa un método de reucperación antiguo que soporta algunos casos que los metodos normales de recuperación no soportan (pero es más lento).

Si obtiene errores extraños al reparar (tales como errores ), o si myisamchk cae, pase a la Etapa 3.

Etapa 3: Reparaciones complicadas

Debe llegar a esta etapa sólo si el primer bloque de 16KB en el fichero de indexación está destruido o contiene información incorrecta, o si el fichero de indexación no se encuentra. En este caso, es necesario crear un nuevo fichero de indexación. Hágalo así:

  1. Mueva el fichero de datos a una ubicación segura.

  2. Use el fichero descriptor de la tabla para crear unos ficheros de datos e indexación nuevos (vacíos): 

    shell> mysql 
mysql> SET AUTOCOMMIT=1;
mysql> TRUNCATE TABLE ;
mysql> quit

    Si su versión de MySQL no soporta , use en su lugar.

  3. Copie el antiguo fichero de datos otra vez sobre el nuevo fichero de datos (recién creado). (No se limite a mover el fichero antiguo sobre el nuevo; debe guardar una copia por si algo falla.)

Vuelva a la Etapa 2. myisamchk -r -q debería funcionar. (Este no debería ser un bucle sin fin.)

Puede usar USE_FRM, que realiza el proceso completo automáticamente.

Etapa 4: Reparaciones muy complicadas

Debe llegar a esta etapa sólo si el fichero de descripción ha tenido problemas. Esto no debería ocurrir nunca, ya que el fichero de descripción nunca cambia una vez que la tabla se crea:

  1. Restaure el fichero de descripción desde una copia de seguridad y vuelva a la Etapa 3. También puede restaurar el fichero índice y volver a la Etapa 2. En este último caso, puede comenzar con myisamchk -r.

  2. Si no tiene una copia de seguridad pero sabe exactamente cómo se creó la tabla, cree una copia de la tabla en otra base de datos. Borre el nuevo fichero de datos, luego mueva los ficheros de descripción y de indexación desde la otra base de datos a la base de datos que tiene problemas. Esto le da unos nuevos ficheros de descripción e indexación, pero deja el fichero de datos solo. Vuelva a la Etapa 2 y trate de reconstruir el fichero de indexación.

5.8.3.10. Optimización de tablas

Para eliminar registros fragmentados y eliminar espacio desperdiciado resultante del borrado o actualización de registros, ejecute myisamchk en modo recuperación: 

shell> myisamchk -r

Puede optimizar una tabla de la misma forma usando el comando SQL . realiza una reparación de la tabla y un análisis de las claves, y también ordena el árbol de índices para obtener un mejor rendimiento en la búsqueda de claves. No hay posibilidad de interacción no deseada entre una utilidad y el servidor, ya que el servidor hace todo el trabajo cuando usa . Consulte Sección 13.5.2.5, “Sintaxis de ”.

myisamchk tiene una serie de opciones que puede usar para mejorar el rendimiento de una tabla:

  • ,

  • ,

  • ,

Para una descripción completa de estas opciones, consulte Sección 5.8.3.1, “Sintaxis para invocar myisamchk”.

5.8.4. Organizar un programa de mantenimiento de tablas

Es una buena práctica realizar chequeos de las tablas regularmente en lugar de esperar a que ocurran los problemas. Una forma de chequear y reparar tablas es con los comandos y . Consulte Sección 13.5.2.3, “Sintaxis de ” y Sección 13.5.2.6, “Sintaxis de ”.

Otro modo de chequear tablas es usar myisamchk. Para mantenimiento, puede usar myisamchk -s. La opción (forma corta de ) hace que myisamchk se ejecute en modo silencioso, mostrando mensajes sólo cuando hay algún error.

Es una buena idea chequear las tablas al arrancar el servidor. Por ejemplo, cada vez que la máquina se reinicia durante una actualización, normalmente necesita chequear todas las tablas que hayan podido ser afectadas. (Éstas son las ``tablas que creemos que han fallado.'') Para chequear automáticamente tablas , arranque el servidor con la opción .

Un test todavía mejor sería chequear cualquier tabla cuya fecha de última modificación es más reciente que la del fichero .

Debe chequear las tablas regularmente durante operaciones normales del sistema. En MySQL AB, utilizamos un trabajo cron para chequear todas nuestras tablas importantes una vez a la semana, usando una línea como esta en un fichero : 

35 0 * * 0 /path/to/myisamchk --fast --silent /path/to/datadir/*/*.MYI

Esto muestra información acerca de tablas que han fallado de forma que podemos examinarlas y repararlas cuando es necesario.

Como no hemos tenido tablas que hayan fallado inesperadamente (tablas que se corrompen por razones distintas a fallos de hardware) durante un par de años (esto es cierto), una vez a la semana es más que suficiente para nosotros.

Recomendamos que para empezar, ejecute myisamchk -s cada noche en todas la tablas que se hayan actualizado durante las últimas 24 horas, hasta que confíe en MySQL tanto como nosotros.

Normalmente, las tablas MySQL necesitan poco mantenimiento. Si cambia las tablas con registros de tamaño dinámico (tablas con columnas , , o ) o tiene tablas con muchos registros borrados puede que quiera defragmentar/reaprovechar espacio de las tablas de vez en cuendo (una vez al mes?).

Puede hacerlo con en las tablas en cuestión. O, si puede parar el servidor mysqld por un rato, cambiando la localización al directorio de datos y usando este comando mientras el servidor está parado: 

shell> myisamchk -r -s --sort-index -O sort_buffer_size=16M */*.MYI

5.8.5. Obtener información acerca de una tabla

Para obtener una descripción de tabla o estadísticas acerca de ella, use el comando mostrado a continuación:

  • myisamchk -d

    Ejecute myisamchk en ``modo descripción'' para producir una descripción de la tabla. Si inicia el servidor MySQL usando la opción , myisamchk puede reportar un error para una tabla que se actualice mientras está en ejecución. Sin embargo, ya que myisamchk no cambia la tabla en modo descripción, no hay riesgo de destruir los datos.

  • myisamchk -d -v

    Añadiendo myisamchk se ejecuta en modo información (verbose) así que produce más información acerca de lo que está haciendo.

  • myisamchk -eis

    Muestra sólo la información más importante de una tabla. Esta operación es lenta ya que debe leer la tabla entera.

  • myisamchk -eiv

    Es como , pero dice lo que está haciendo.

A continuación hay unos ejemplos de la salida de estos comandos. Están basados en una tabla con estos tamañanos de fichero de datos e índices: 

-rw-rw-r--   1 monty    tcx     317235748 Jan 12 17:30 company.MYD
-rw-rw-r--   1 davida   tcx      96482304 Jan 12 18:35 company.MYM

Ejemplos de salida de myisamchk -d: 

MyISAM file:     company.MYI
Record format:   Fixed length
Data records:    1403698  Deleted blocks:         0
Recordlength:    226

table description:
Key Start Len Index   Type
1   2     8   unique  double
2   15    10  multip. text packed stripped
3   219   8   multip. double
4   63    10  multip. text packed stripped
5   167   2   multip. unsigned short
6   177   4   multip. unsigned long
7   155   4   multip. text
8   138   4   multip. unsigned long
9   177   4   multip. unsigned long
    193   1           text

Ejemplo de salida de myisamchk -d -v: 

MyISAM file:         company
Record format:       Fixed length
File-version:        1
Creation time:       1999-10-30 12:12:51
Recover time:        1999-10-31 19:13:01
Status:              checked
Data records:            1403698  Deleted blocks:              0
Datafile parts:          1403698  Deleted data:                0
Datafile pointer (bytes):      3  Keyfile pointer (bytes):     3
Max datafile length:  3791650815  Max keyfile length: 4294967294
Recordlength:                226

table description:
Key Start Len Index   Type                  Rec/key     Root Blocksize
1   2     8   unique  double                      1 15845376      1024
2   15    10  multip. text packed stripped        2 25062400      1024
3   219   8   multip. double                     73 40907776      1024
4   63    10  multip. text packed stripped        5 48097280      1024
5   167   2   multip. unsigned short           4840 55200768      1024
6   177   4   multip. unsigned long            1346 65145856      1024
7   155   4   multip. text                     4995 75090944      1024
8   138   4   multip. unsigned long              87 85036032      1024
9   177   4   multip. unsigned long             178 96481280      1024
    193   1           text

Ejemplo de salida de myisamchk -eis: 

Checking MyISAM file: company
Key:  1:  Keyblocks used:  97%  Packed:    0%  Max levels:  4
Key:  2:  Keyblocks used:  98%  Packed:   50%  Max levels:  4
Key:  3:  Keyblocks used:  97%  Packed:    0%  Max levels:  4
Key:  4:  Keyblocks used:  99%  Packed:   60%  Max levels:  3
Key:  5:  Keyblocks used:  99%  Packed:    0%  Max levels:  3
Key:  6:  Keyblocks used:  99%  Packed:    0%  Max levels:  3
Key:  7:  Keyblocks used:  99%  Packed:    0%  Max levels:  3
Key:  8:  Keyblocks used:  99%  Packed:    0%  Max levels:  3
Key:  9:  Keyblocks used:  98%  Packed:    0%  Max levels:  4
Total:    Keyblocks used:  98%  Packed:   17%

Records:          1403698    M.recordlength:     226
Packed:             0%
Recordspace used:     100%   Empty space:          0%
Blocks/Record:   1.00
Record blocks:    1403698    Delete blocks:        0
Recorddata:     317235748    Deleted data:         0
Lost space:             0    Linkdata:             0

User time 1626.51, System time 232.36
Maximum resident set size 0, Integral resident set size 0
Non physical pagefaults 0, Physical pagefaults 627, Swaps 0
Blocks in 0 out 0, Messages in 0 out 0, Signals 0
Voluntary context switches 639, Involuntary context switches 28966

Ejemplo de salida de myisamchk -eiv: 

Checking MyISAM file: company
Data records: 1403698   Deleted blocks:       0
- check file-size
- check delete-chain
block_size 1024:
index  1:
index  2:
index  3:
index  4:
index  5:
index  6:
index  7:
index  8:
index  9:
No recordlinks
- check index reference
- check data record references index: 1
Key:  1:  Keyblocks used:  97%  Packed:    0%  Max levels:  4
- check data record references index: 2
Key:  2:  Keyblocks used:  98%  Packed:   50%  Max levels:  4
- check data record references index: 3
Key:  3:  Keyblocks used:  97%  Packed:    0%  Max levels:  4
- check data record references index: 4
Key:  4:  Keyblocks used:  99%  Packed:   60%  Max levels:  3
- check data record references index: 5
Key:  5:  Keyblocks used:  99%  Packed:    0%  Max levels:  3
- check data record references index: 6
Key:  6:  Keyblocks used:  99%  Packed:    0%  Max levels:  3
- check data record references index: 7
Key:  7:  Keyblocks used:  99%  Packed:    0%  Max levels:  3
- check data record references index: 8
Key:  8:  Keyblocks used:  99%  Packed:    0%  Max levels:  3
- check data record references index: 9
Key:  9:  Keyblocks used:  98%  Packed:    0%  Max levels:  4
Total:    Keyblocks used:   9%  Packed:   17%

- check records and index references
[LOTS OF ROW NUMBERS DELETED]

Records:         1403698   M.recordlength:   226   Packed:           0%
Recordspace used:    100%  Empty space:        0%  Blocks/Record: 1.00
Record blocks:   1403698   Delete blocks:      0
Recorddata:    317235748   Deleted data:       0
Lost space:            0   Linkdata:           0

User time 1639.63, System time 251.61
Maximum resident set size 0, Integral resident set size 0
Non physical pagefaults 0, Physical pagefaults 10580, Swaps 0
Blocks in 4 out 0, Messages in 0 out 0, Signals 0
Voluntary context switches 10604, Involuntary context switches 122798

Explicación de los tipos de información que produce myisamchk se dan a continación. ``Keyfile'' se refiere al fichero índice. ``Record'' y ``row'' son sinónimos.

  • (Fichero MyISAM)

    Nombre del fichero índice .

  • (Versión del fichero)

    Versión del formato . Actualmente siempre es 2.

  • (Fecha de creación)

    Cuando se creó el fichero de datos.

  • (Fecha de recuperación)

    Cuando el fichero de índices/datos se reconstruyó por última vez.

  • (Fecha de recuperación)

    Cuántos registros hay en la tabla.

  • (Bloques borrados)

    Cuántos bloques borrados todavía tienen espacio reservado. Puede optimizar la tabla para minimizar este espacio. Consulte Sección 5.8.3.10, “Optimización de tablas”.

  • (Partes de ficheros de datos)

    Para el formato de registros dinámicos, indica cuántos bloques de datos hay. Para una tabla optimizada sin registros fragmentados, es lo mismo que .

  • (Datos borrados)

    Cuántos bytes hay de datos borrados sin reclamar. Puede optimizar la tabla para minimizar este espacio. Consulte Sección 5.8.3.10, “Optimización de tablas”.

  • (Puntero fichero de datos)

    El tamaño del puntero del fichero de datos, en bytes. Normalmente es de 2, 3, 4, o 5 bytes. La mayoría de tablas se administran con 2 bytes, pero MySQL no puede controlar esto todavía. Para tablas arregladas, esta es la dirección de un registro. Para tablas dinámicas, es la dirección de un byte.

  • (Puntero fichero de claves)

    El tamaño del puntero del fichero índice, en bytes. Normalmente es de 1, 2, o 3 bytes. La mayoría de tablas se administran con 2 bytes, pero esto se calcula automáticamente por MySQL. Siempre es la dirección de un bloque.

  • (Máximo tamaño fichero de datos)

    Cuánto puede crecer el fichero de datos, en bytes.

  • (Máximo tamaño fichero de claves)

    Cuánto puede creceer el fichero índice, en bytes.

  • (Tamaño registro)

    El tamaño de cada registro, en bytes.

  • (Formato de registro)

    El formato usado para almacenar registro de tablas. Los ejemplos precedentes usan . Otros valores posibles son y .

  • (Descripción de tabla)

    Una lista de todas las claves en la tabla. Para cada clave, myisamchk muestra alguna información a bajo nivel:

    • (Clave)

      El número de esta clave.

    • (Inicio)

      Dónde en el registro comienza esta parte del índice.

    • (Longitud)

      El tamaño de esta parte del índice. Para números empaquetados, este debería ser siempre la longitud completa de la columna. Para cadenas de carácteres, podría ser menor que la longitud total de la columna indexada, ya que puede indexar un prefijo de una columna de cadenas de carácteres.

    • (Índice)

      Si un valor clave puede existir múltiples veces en el índice. Los valores son o (múltiples).

    • (Tipo)

      Qué tipo de datos tiene esta parte del índice. Este es un tipo de datos con las opciones , , o .

    • (Raíz)

      Dirección del bloque índice raíz.

    • (Tamaño de bloque)

      El tamaño de cada bloque de índices. Por defecto es de 1024, pero el valor puede cambiar en tiempo de compilación cuando MySQL se construye desde el código fuente.

    • (Registros/clave)

      Este es un valor estadístico usado por el optimizador. Dice cuántos registros hay por valor para esta clave. Una clave única siempre tiene un valor de 1. Puede actualizarse tras la carga de una tabla (o muy cambiada) con myisamchk -a. Si no se actualiza en absoluto, el valor por defecto es 30.

    Para la tabla mostrada en los ejemplos, hay dos líneas para (descripción de tabla) para el noveno índice. Esto indica que es un índice de múltiples partes, en este caso con dos.

  • (Bloques de claves usados)

    Porcentaje de los bloques de clave usados. Cuando una tabla se ha reorganizad con myisamchk, como en los ejemplos, los valores son muy altos (muy cerca del máximo teórico).

  • (Empaquetado)

    MySQL intenta empaquetar las claves con un sufijo común. Sólo puede usarse para índices en columnas , . Para cadenas de carácteres largas que tienen partes izquierdas de la cadena similares, esto puede reducir significativamente el espacio usado. En el tercer ejemplo dado anteriomente, la cuarta clave tiene una longitud de 10 carácteres y se consigue una reducción del 60% del espacio.

  • (Número máximo de niveles)

    La profunidad del árbol-B para esta clave. Tablas grandes con valores de clave grandes obtienen valores altos.

  • Registros

    Número de registros en la tabla.

  • Longitud de registro media

    La media de la longitud de los registros. Este valor es la longitud de registro para tablas con registros de longitud fija, ya que todos los registros tienen la misma longitud.

  • Empaquetado

    Espacios vacíos al final de las cadenas de carácteres en MySQL. El valor indica el porcentaje de ahorro conseguido haciendo un empaquetado.

  • Espacio de registro usado

    Porcentaje del fichero de datos usado.

  • Espacio vacío

    Porcentaje del fichero de datos sin usar.

  • Bloques/Registro

    Número medio de bloques por registro (de cuántos enlaces se compone un registro fragmentado). Siempre es 1.0 para una tabla con formato fijo. Este valor debe estar tan cercano a 1.0 como sea posible. Si crece mucho, puede reorganizar la tabla. Consulte Sección 5.8.3.10, “Optimización de tablas”.

  • Bloques de registro

    Cuántos bloques (enlaces) se usan. Para formato fijo, esto es lo mismo que el número de registros.

  • Bloques borrados

    Cuántos bloques (enlaces) están borrados.

  • Datos de registro

    Cuántos bytes en el fichero de datos se usan.

  • Datos borrados

    Cuántos bytes en el fichero de datos están borrados (no usados).

  • Espacio perdido

    Si un registro se actualiza a una longitudo más pequeña, se pierde algo de espacio. Este valor es la suma de todas estas pérdidas, en bytes.

  • Datos enlazados

    Cuando se usa el formato de tabla dinámico, los fragmentos de registros se enlazan con punteros (de 4 a 7 bytes cada uno). es la suma de la cantidad de almacenamiento usada por estos punteros.

Si una tabla se ha comprimido con myisampack, myisamchk -d muestra información adicional acerca de cada columna de la tabla. Consulte Sección 8.2, “myisampack, el generador de tablas comprimidas de sólo lectura de MySQL”, para un ejemplo de esta información y una descripción de lo que significa.

previous page start next page