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