5.10. Los ficheros de registro (log) de MySQL

MySQL 5.0

5.10. Los ficheros de registro (log) de MySQL

MySQL tiene varios archivos de registro diferentes que pueden ayudarle a encontrar lo que está ocurriendo en mysqld:

Archivo de registro	Tipo de información registrado en el archivo
El registro de error	Registra problemas encontrados iniciando, ejecutando, o parando mysqld.
El registro de consultas	Registra las conexiones de clientes establecidas, y las sentencias ejecutadas.
El registro de actualizaciones The update log	Registra las sentencias que cambian datos. Este registro está ya en desuso.
El registro binario	Registra todas las sentencias que cambian datos. También utilizado para replicación.
El registro de lentitud	Registra todas las sentencias que tardarón más de `long_query_time` segundos en ejecutarse, o no utilizaron índices.

Por defecto, todos los registros son creados en el directorio de datos de mysqld. Puede forzar a mysqld a que cierre y reabra los archivos de registro (o en algunos casos, cambiar a un nuevo registro) mediante el volcado de registros. El volcado de registros ocurre cuando ejecuta la sentencia FLUSH LOGS o el comando mysqladmin flush-logs or mysqladmin refresh. Consulte Sección 13.5.5.2, “Sintaxis de FLUSH”.

Si está utilizando las capacidades de replicación de MySQL, los servidores esclavos de replicación mantienen unos registros adicionales llamados registros relay. Estos se explican en Capítulo 6, Replicación en MySQL.

5.10.1. El registro de errroes (Error Log)

El archivo de registro de errores contiene información que indica cuando se ha iniciado y parado mysqld y también si ha ocurrido algún error crítico mientras el servidor se estaba ejecutando.

Si mysqld termina inesperadamente y mysqld_safe necesita reiniciarlo, mysqld_safe escribe un mensaje restarted mysqld en el registro de errores. Si mysqld se da cuenta de que hay una tabla que necesita ser automáticamente comprobada o reparada, escribe un mensaje al registro de errores.

En algunos sistemas operativos, el registro de errores contiene un volcado de la pila si mysqld muere. El volcado puede ser utilizado para determinar cuando mysqld murió. Consulte Sección D.1.4, “Usar stack trace”.

En MySQL 5.0, puede especificar dónde quiere que mysqld almacene el registro de errores con la opción --log-error[=file_name]. Si no se proporciona ningún valor para file_name, mysqld utiliza el nombre host_name.err y escribe el archivo en el directorio de datos. Si ejecuta FLUSH LOGS, el registro de errores es renombrado con el sufijo -old y mysqld crea un nuevo archivo de registro.

Si no especifica --log-error, o (en Windows) no utiliza la opción --console, los errores se escriben en stderr, la salida estándar de erroes. Usualmente esto es su terminal.

En Windows, la salida de errores es siempre escrita al archivo .err si no se especifica la opción --console.

5.10.2. El registro general de consultas

Si quiere saber qué pasa en mysqld, debe iniciarlo con la opción --log[=file_name] o -l [file_name]. Si no se da un valor para file_name, el nombre por defecto es host_name.log. Esto registra todas las conexiones y sentencias a un archivo. Este registro puede ser muy útil cuando sospeche que hay un error en un cliente y quiera saber exactamente qué envió el cliente a mysqld.

mysqld escribe las sentencias al registro de consultas en el orden en que las recibe. Este orden puede ser diferente del de ejecución. Esto es aquí diferente que en el registro de actualizaciones o el registro binario, que son escritos tras la ejecución de la sentencia, pero antes de que se libere cualquier bloqueo. (El registro de consultas también contiene todas las sentencias, mientras que el registro binario no contiene sentencias que solo seleccionen datos.)

Los reinicios del servidor y volcado de registros no provocan que se genere un nuevo archivo de registro de consultas general (aunque el volcado lo cierra y lo reabre). En Unix, puede renombrar el archivo y crear uno nuevo utilizando los siguientes comandos:

shell> mv hostname.log hostname-old.log shell> mysqladmin flush-logs shell> cp hostname-old.log to-backup-directory shell> rm hostname-old.log

En Windows, no puede renombrar el archivo de registro mientras el servidor lo tiene abierto. Debe parar el servidor y renombrar el registro. Después, reinicie el servidor para crear el nuevo registro.

5.10.3. El registro binario (Binary Log)

El registro binario contiene toda la información que está disponible en el registro de actualizaciones, en un formato más eficiente y de una manera que es segura para las transacciones.

El registro binario contiene todas las sentencias que han actualizado datos o podrían haberlo hecho (por ejemplo, un DELETE que no encontró filas concordantes). Las sentencias se almacenan en la forma de “eventos” que describen las modificaciones.

Atención: El registro binario ha reemplazado al antiguo registro de actualizaciones, que ya no está disponible a partir de MySQL 5.0.

El registro binario también contiene información sobre cuanto ha tardado cada sentencia que actualizó la base de datos. No contiene sentencias que no hayan modificado datos. Si quiere registrar todas las sentencias (por ejemplo, para identificar una sentencia problemática) debería utilizar el registro de consultas general. Consulte Sección 5.10.2, “El registro general de consultas”.

El propósito principal del registro binario es el de actualizar la base de datos durante una operación de recuperación tan completamente como sea posible, porque el registro binario contiene todas las actualizaciones hechas tras la copia de seguridad.

El registro binario también se utiliza en los servidores maestros de replicación como recordatorio de las sentencias que deben ser enviadas a los servidores esclavos. Consulte Capítulo 6, Replicación en MySQL.

Ejecutar el servidor con el registro binario activado hace que el rendimiento baje un 1%. Aún así, los beneficios del registro binario para las operaciones de restauración y el hecho de permitirnos poder establecer replicación generalmente son superiores a este decremento de rendimiento.

Cuando se ha iniciado con la opción --log-bin[=file_name] mysqld escribe un archivo de registro que contiene todos los comandos SQL que actualizan datos. Si no se da ningún valor para file_name, el valor por defecto es el nombre de la máuqina host seguido por -bin. Si se da el nombre del archivo, pero ninguna ruta, el archivo se escribe en el directorio de datos. Se recomienda especificar un nombre de archivo, consulte Sección A.8.4, “Cuestiones abiertas en MySQL” para ver el motivo.

Si usted proporciona una extensión en el nombre del registro (por ejemplo, --log-bin=file_name.extension), la extensión se ignora y elimina sin aviso.

mysqld agraga una extensión numérica a el nombre del registro binario. Este número se incrementa cada vez que se inicia el servidor o se vuelcan los registros. También se crea un nuevo registro binario cuando el actual llega al tamaño especificado en max_binlog_size. Un registro binario puede llegar a ser más grande de max_binlog_size si está utilizando transacciones grandes: Una transacción se escribe en el registro de una sola pieza, nunca se parte entre diferentes registros.

Para poder averiguar qué archivos de registro binario diferentes han sido utilizados, mysqld también crea un archivo de índice de los registros binarios que contiene los nombres de todos los archivos de registro binario utilizados. Por defecto éste tiene el mismo nombre que el archivo de registro binario, con la extensión '.index'. Puede cambiar el nombre del archivo de índice con la opción --log-bin-index[=file_name]. No debería editar este archivo manualmente mientras mysqld se está ejecutando; hacerlo podría confundir a mysqld.

Puede borrar todos los archivos de registro binario con la sentencia RESET MASTER, o sólo algunos de ellos con PURGE MASTER LOGS. Consulte Sección 13.5.5.5, “Sintaxis de RESET” y Sección 13.6.1, “Sentencias SQL para el control de servidores maestros”.

El formato del registro binario tiene algunas limitaciones conocidas que pueden afectar a la recuperación de copias de seguridad. Consulte Sección 6.7, “Características de la replicación y problemas conocidos”.

El registro binario de procedimientos almacenados y disparadores se hace tal como se explica en Sección 19.3, “Registro binario de procedimientos almacenados y disparadores”.

Puede utilizar las siguientes opciones de mysqld para determinar lo que se registra en el registro binario. Vea también la explicación que sigue a esta lista de opciones.

--binlog-do-db=db_name

Le dice al maestro que debería registrar los cambios en el registro binario si la base de datos actual (es decir, la que está seleccionada mediante USE) es db_name. Todos las otras bases de datos que no sean mencionadas explícitamente son ignoradas. Si utiliza esto, debería asegurarse de que sólo hace cambios en la base de datos actual.

Tenga en cuenta que hay una excepción a esto en lo que respecta a las sentencias CREATE DATABASE, ALTER DATABASE, y DROP DATABASE, que utilizan la base de datos manipulada en vez de la actual para decidir si deberían registrar la sentencia.

Un ejemplo de algo que no funciona como podría esperarse: Si el servidor se inició con binlog-do-db=sales, y usted ejecuta USE prices; UPDATE sales.january SET amount=amount+1000;, esta sentencia no llega a escribirse en el registro binario.

--binlog-ignore-db=db_name

Le dice al maestro que las actualizaciones donde la base de datos actual (es decir, la que ha sido seleccionada mediante USE) es db_name no deberían ser almacenadas en el registro binario. Si utiliza esto, debería asegurarse de que solo hace actualizaciones en la base de datos actual.

Un ejemplo de algo que no funciona como podría esperarse: Si el servidor se inició con binlog-ignore-db=sales, y ejecuta USE prices; UPDATE sales.january SET amount=amount+1000;, esta sentencia no se escribe en el registro binario.

De la misma forma que en el caso de --binlog-do-db, hay una excepción para las sentencias CREATE DATABASE, ALTER DATABASE, y DROP DATABASE, que utilizan la base de datos manipulada para decidir si deben registrar la sentencia, en vez de la base de datos actual.

Para registrar o ignorar múltiples bases de datos, utilice múltiples opciones, especificando la opción apropiada una vez para cada base de datos.

Las reglas para registrar o ignorar actualizaciones en el registro binario son evaluadas de acuerdo a las siguientes normas. Tenga en cuenta que hay una excepción para las sentencias CREATE DATABASE, ALTER DATABASE, y DROP DATABASE. En esos casos, la base de datos que está siendo creada, alterada, o eliminada reemplaza a la base de datos actual en las reglas siguientes.

¿Hay alguna regla binlog-do-db o binlog-ignore-db?

No: Escribir la sentencia al registro binario y salir.

Sí: Proceder al siguiente paso.

Hay algunas reglas (binlog-do-db o binlog-ignore-db o ambas). ¿Hay una base de datos actual (¿ha sido seleccionada alguna base de datos mediante USE?)?

No: No escribir la sentencia, y salir.

Sí: Proceder al siguiente paso.

Hay una base de datos actual. ¿Hay alguna regla binlog-do-db?

Sí: ¿Concuerda la base de datos con alguna de las reglas binlog-do-db?

Sí: Escribir la sentencia y salir.

No: No escribir la sentencia, y salir.

No: Proceder al siguiente paso.

Hay alguna regla binlog-ignore-db. ¿Concuerda la base de datos con alguna de las reglas binlog-ignore-db?

Sí: No escribir la sentencia, y salir.

No: Escribir la sentencia y salir.

Por ejemplo, un esclavo ejecutándose con sólo binlog-do-db=sales no escribe en el registro binario ninguna sentencia en la que la base de datos actual sea diferente de sales (es decir, a veces binlog-do-db puede significar ``ignora otras bases de datos'').

Si está utilizando replicación, debería no borrar los archivos de registros binarios viejos hasta que esté seguro de que ningún esclavo los necesita. Una manera de averiguarlo es hacer mysqladmin flush-logs una vez al día y borrar cualquier registro que tenga más de tres días de antigüedad. Puede borrarlos manualmente, o mejor aún mediante PURGE MASTER LOGS (consulte Sección 13.6.1, “Sentencias SQL para el control de servidores maestros”), que además también actualiza de manera segura el archivo de índice de registros binarios (y que puede recibir parámetros de fecha).

Un cliente con el privilegio SUPER puede desactivar el registro binario de sus propias sentencias utilizando una sentencia SET SQL_LOG_BIN=0. Consulte Sección 13.5.3, “Sintaxis de SET”.

Puede examinar el archivo de registro binario con la utilidad mysqlbinlog. Esto podría ser útil cuando usted quiera reprocesar sentencias almacenadas en el registro. Por ejemplo, puede actualizar un servidor MySQL desde el registro binario de la siguiente manera:

shell> mysqlbinlog log-file | mysql -h server_name

Consulte Sección 8.5, “La utilidad mysqlbinlog para registros binarios” para obtener más información sobre la utilidad mysqlbinlog y su utilización.

Si usted está utilizando transacciones, debería utilizar el registro binario de MySQL para hacer las copias de seguridad, en vez del antiguo registro de actualizaciones.

El registro binario se hace inmediatamente después de que se completa una consulta, pero antes de que se libere cualquier bloqueo o se haga ningún commit. Esto asegura que el registro está almacenado en el orden de ejecución.

Las actualizaciones a las tablas no-transaccionales se almacenan en el registro binario inmediatamente después de su ejecución. Para las tablas transaccionales como las tablas BDB o InnoDB, todas las actualizaciones (UPDATE, DELETE, o INSERT) que cambian alguna tabla son almacenadas en cache hasta que se recibe una sentencia COMMIT en el servidor. En ese momento mysqld escribe la transacción completa al registro binario antes de que se ejecute el COMMIT. Cuando el flujo de ejecución que gestiona la transacción comienza, reserva un buffer de tamaño binlog_cache_size para almacenar consultas. Si una sentencia es más grande de esto, el flujo abre un archivo temporal para almacenar la transacción. El archivo temporal se borra cuando acaba el flujo.

La variable de estado Binlog_cache_use muestra el número de transacciones que han utilizado este buffer (y posiblemente un archivo temporal) para almacenar sentencias. La variable de estado Binlog_cache_disk_use muestra cuantas de esas transacciones llegaron realmente a utilizar un archivo temporal. Estas dos variables pueden utilizarse para establecer el valor de binlog_cache_size y evitar el uso de archivos temporales.

El tamaño max_binlog_cache_size (por defecto 4GB) se puede utilizar para restringir el tamaño total utilizado para almacenar una transacción con múltiples sentencias. Si una transacción es más grande que esto, falla y se hace un rollback.

Si usted está utilizando el registro de actualizaciones o el binario, las inserciones concurrentes se convierten a inserciones normales cuando se utiliza CREATE ... SELECT o INSERT ... SELECT. Esto se hace así para asegurarse de que se puede reconstruir una copia exacta de sus tablas aplicando los registros a una copia de seguridad.

Tenga en cuenta que el formato del registro binario es diferente en MySQL 5.0 al de versiones anteriores de MySQL, debido a mejoras en la replicación. Consulte Sección 6.5, “Compatibilidad entre versiones de MySQL con respecto a la replicación”.

Por defecto, el registro binario no se sincroniza con el disco en cada escritura. Así que si el sistema operativo o la máquina (no únicamente el servidor MySQL) falla, existe la posibilidad de que las últimas sentencias del registro binario se pierdan. Para prevenir esto, puede hacer que el registro binario se sincronice con el disco tras cada N escrituras, con la variable global sync_binlog (siendo 1 el valor más seguro, pero también el más lento). Consulte Sección 5.3.3, “Variables de sistema del servidor”. Aún con el valor de sync_binlog establecido en 1, existe una posibilidad de que haya una inconsistencia entre las tablas y el registro binario en el caso de fallo. Por ejemplo, si está utilizando tablas InnoDB, y el servidor MySQL procesa una sentencia COMMIT, escribe la transacción completa al registro binario, y después la envía a InnoDB. Si el fallo se produce entre estas dos operaciones, al reiniciar la transacción es rechazada por InnoDB, pero todavía existe en el registro binario. Este problema puede resolverse con la opción --innodb-safe-binlog, que añade consistencia entre el contenido de las tablas InnoDB y el registro binario.

Para que esta opción proporcione un grado mayor de seguridad, el servidor MySQL debe estar también configurado para sincronizar a disco, en cada transacción, el registro binario (sync_binlog=1) y (lo que es cierto por defecto) los registros InnoDB. El efecto de esta opción es que al reiniciar tras un fallo, o tras hacer un rollback de transacciones, el servidor MySQL elimina las transacciones InnoDB que han sufrido una cancelación del registro binario. Esto asegura que el registro binario refleje los datos exactos que hay en las tablas InnoDB y, así, el esclavo permanece sincronizado con el maestro (no recibe una sentencia que ha sido cancelada).

Tenga en cuenta que --innodb-safe-binlog se puede utilizar aún cuando el servidor MySQL actualice otros motores de almacenamiento que no sean InnoDB. Sólo las sentencia/transacciones que afecten a tablas InnoDB son candidatas a ser eliminadas del registro binario durante la recuperación de un fallo de InnoDB. Si durante la recuperación el servidor MySQL descubre que el registro binario es más corto de lo que debería ser (es decir, le falta al menos una transacción InnoDB realizada con éxito), lo que no debería ocurrir con sync_binlog=1 y el disco/sistema de archivos hace una sincronización real cuando se le pide (algunos no lo hacen), muestra un mensaje de error ("The binary log <name> is shorter than its expected size"). En este caso el registro binario no es correcto, y la replicación debería reiniciarse desde una nueva imagen de los datos del maestro.

La escrituras al archivo del registro binario y al de índice de registros son gestionados de la misma manera que las escrituras a las tablas MyISAM. Consulte Sección A.4.3, “Cómo se comporta MySQL ante un disco lleno”.

5.10.4. El registro de consultas lentas (Slow Query Log)

Cuando se inicia con la opción --log-slow-queries[=file_name], mysqld escribe un archivo de registro que contiene todos las sentencias SQL que llevaron más de long_query_time segundos para ejecutarse completamente. El tiempo para adquirir los bloqueos de tabla iniciales no se cuenta como tiempo de ejecución.

Si no se da ningún valor a file_name, el nombre por defecto es el nombre de la máquina host con el sufijo -slow.log. Si se da un nombre de archivo, pero no como ruta absoluta, el archivo se escribe en el directorio de datos.

Una sentencia se registra en el registro de consultas lentas después de que haya sido ejecutada y todos los bloqueos liberados. El orden de registro puede diferir del de ejecución.

El registro de consultas lentas se puede utilizar para encontrar consultas que tomen excesivo tiempo y sean por tanto candidatos a optimización. De cualquier modo, examinar un registro de consultas lentas puede convertirse en una tarea difícil. Para hacerlo más simple, puede procesar el registro de consultas lentas utilizando el comando mysqldumpslow que le ofrecerá un resumen de las sentencias que aparecen en el registro.

En el registro de consultas lentas de MySQL 5.0, las consultas lentas que no utilizan índices se registran igual que las que sí utilizan. Para prevenir que las consultas que no utilizan índices sean registradas en el registro de consultas lentas, utilice la opción --log-short-format. Consulte Sección 5.3.1, “Opciones del comando mysqld”.

En MySQL 5.0, la opción --log-slow-admin-statements del servidor le permite demandar el registro de sentencias administrativas lentas como OPTIMIZE TABLE, ANALYZE TABLE, y ALTER TABLE sean escritas en el registro de consultas lentas.

Las consultas gestionadas por la cache de consultas no son añadidas al registro de consultas lentas, ni tampoco las consultas que no se beneficien de la presencia de un índice porque la tabla tenga cero o una filas.

5.10.5. Mantenimiento de ficheros de registro (log)

El servidor MySQL puede crear un número de archivos de registro diferente que faciliten el ver que está pasando. Consulte Sección 5.10, “Los ficheros de registro (log) de MySQL”. De cualquier modo, debe limpiar estos archivos regularmente para asegurarse de que no ocupan demasiado espacio.

Cuando se utiliza MySQL con el registro activado, debería hacer copias de seguridad y eliminar los registros viejos de vez en cuando, y decirle a MySQL que comience a registrar en archivos nuevos. Consulte Sección 5.8.1, “Copias de seguridad de bases de datos”.

En una instalación Linux (Red Hat), puede utilizar el script mysql-log-rotate para esto. Si instaló MySQL desde una distribución RPM, el script debería haber sido instalado automáticamente. Debería tener cuidado con este script si está utilizando el registro binario para replicación; no elimine los registros binarios hasta que tenga la certeza de que sus contenidos han sido procesados por todos los esclavos.

En otros sistemas, debe instalar un script corto usted mismo desde cron o algo equivalente para gestionar los archivos de registros.

Puede forzar a MySQL para que comience a utilizar archivos de registro nuevos usando mysqladmin flush-logs o con la sentencia SQL FLUSH LOGS.

Una operación de volcado de registros hace lo siguiente:

Si se está utilizando registro estándard (--log) o registro de consultas lentas (--log-slow-queries), cierra y reabre el archivo de registro (mysql.log y `hostname`-slow.log por defecto).

Si se está utilizando registro de actualizaciones (--log-update) o registro binario (--log-bin) cierra el registro, y abre un nuevo archivo de registro con un número de secuencia superior.

Si está utilizando tan solo el registro de actualizaciones, tan solo tiene que renombrar el archivo de registro y posteriormente volcar los registros antes de hacer una copia de seguridad. Por ejemplo, puede hacer algo como esto:

shell> cd mysql-data-directory shell> mv mysql.log mysql.old shell> mysqladmin flush-logs

Luego, haga una copia de seguridad y elimine mysql.old.

previous page start next page