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.

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.

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.

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.

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

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.

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:

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