El registro binario (binlog) es un componente crítico en arquitecturas de MySQL que requieren alta disponibilidad, recuperación ante desastres y replicación confiable. A diferencia de los registros de transacciones intrenos como el redo log de InnoDB, el binlog opera a nivel lógico y registra eventos que modifican los datos — incluso aquellos que no afectan filas (por ejemplo, un DELETE sin coincidencias). Esta característica lo convierte en la base para la replicación maestro-esclavo y en una herramienta indispensable para restauraciones incrementales.

Configuración fundamental del binlog

Para habilitar el binlog, se debe configurar log_bin en el archivo my.cnf. Su ubicación y nombre se definen explícitamente:

[mysqld]
log_bin = /var/lib/mysql/binlogs/mysql-bin
log_bin_index = /var/lib/mysql/binlogs/mysql-bin.index

Opcionalmente, se pueden restringir los registros mediante filtros:

• binlog_do_db = ventas: solo registra cambios en la base ventas.
• binlog_ignore_db = auditoria: excluye la base auditoria del binlog.

Estos filtros actúan según la base de datos predeterminada activa durante la ejecución de cada sentencia, no por el origen real de los datos modificados — un detalle crucial para evitar inconsistencias en entornos con múltiples esquemas.

Formatos de registro: Statement, Row y Mixed

MySQL soporta tres formatos de binlog, cada uno con ventajas y limitaciones específicas:

1. Statement-Based Replication (SBR)

Cada sentencia DML/DDL se registra tal cual. Es eficiente en términos de tamaño de registro, pero presenta riesgos de no determinismo:

• No replica correctamente funciones no seguras como NOW(), UUID(), LAST_INSERT_ID() o UDFs.
• Puede generar bloqueos más amplios en operaciones como INSERT ... SELECT.

2. Row-Based Replication (RBR)

Registra las filas afectadas antes y después de la modificación. Ofrece máxima fiabilidad y evita problemas de replicación relacionados con funciones o procedimientos almacenados. Sin embargo, incrementa significativamente el volumen de registro — especialmente en operaciones masivas como ALTER TABLE o actualizaciones sobre miles de filas.

3. Mixed Mode

Combina ambos enfoques: usa SBR por defecto, pero cambia automáticamente a RBR cuando detecta sentencias potencialmente no replicables (por ejemplo, uso de SLEEP() o funciones no deterministas). Es la opción recomendada para la mayoría de los entornos productivos.

Se configura así:

binlog_format = MIXED

Parámetros clave para rendimiento e integridad

La configuración del binlog impacta directamente tanto en la latencia como en la consistencia de los datos. Los parámetros más relevantes son:

Un punto crítico: al usar sync_binlog = 1 con InnoDB, existe un pequeño riesgo de inconsistenica si ocurre un fallo tras escribir el binlog pero antes del COMMIT. Para mitigarlo, se recomienda activar innodb_support_xa = ON, asegurando coordinación entre el binlog y el redo log.

Gestión del ciclo de vida del binlog

Los archivos binlog crecen continuamante y deben gestionarse proactivamente para evitar agotamiento de espacio en disco.

Limpieza automática

Configurar retención basada en tiempo:

-- En my.cnf
expire_logs_days = 7

-- O dinámicamente (sin reinicio)
SET GLOBAL expire_logs_days = 7;

Limpieza manual

Operaciones seguras incluso con réplicas activas:

-- Eliminar todos los binlogs anteriores a una fecha
PURGE BINARY LOGS BEFORE '2024-06-01 00:00:00';

-- Eliminar hasta un archivo específico
PURGE BINARY LOGS TO 'mysql-bin.000025';

-- Listar archivos actuales
SHOW BINARY LOGS;

Advertencia: RESET MASTER elimina todos los binlogs y reinicia la numeración — solo debe usarse en escenarios de reinicio completo o pruebas aisladas.

Análisis y diagnóstico del binlog

La utilidad mysqlbinlog permite inspeccionar el contenido de forma legible:

# Visualizar un binlog específico
mysqlbinlog /var/lib/mysql/binlogs/mysql-bin.000012 | less

# Filtrar por rango de posición y servidor
mysqlbinlog --start-position=12345 --stop-position=67890 \
            --server-id=1 /var/lib/mysql/binlogs/mysql-bin.000012

Fragmento típico de salida:

# at 12345
#240515 14:22:08 server id 1  end_log_pos 12456 CRC32 0xabc12345 Query thread_id=123 exec_time=0 error_code=0
SET TIMESTAMP=1715782928/*!*/;
UPDATE pedidos SET estado = 'procesado' WHERE id = 45678/*!*/;
# at 12456
#240515 14:22:08 server id 1  end_log_pos 12483 CRC32 0xdef98765 Xid = 98765
COMMIT/*!*/;

Claves de interpretación:

• at N: posición inicial del evento (byte).
• end_log_pos M: posición final del evento.
• server id: identificador único del nodo maestro.
• Xid: identificador de transacción para commits atómicos.

Estrategias de optimización avanzada

Para reducir la sobrecarga de red y procesamiento en entornos replicados, se pueden aplicar filtros de replicación en el nodo maestro o esclavo:

• En el maestro: binlog_do_db, binlog_ignore_db reducen el volumen generado y transmitido.
• En el esclavo: replicate_do_db, replicate_ignore_table, replicate_wild_do_table permiten filtrar en destino, ofreciendo mayor flexibilidad y evitando errores por contexto de base de datos predeterminada.

Además, para cargas de trabajo intensivas en escritura, se recomienda:

• Usar binlog_row_image = MINIMAL (disponible desde MySQL 5.6+) para reducir el tamaño de eventos RBR, registrando solo columnas modificadas.
• Habilitar binlog_order_commits = ON (predeterminado) para mejorar la coherencia de orden en entornos con alta concurrencia.
• Monitorear métricas como Binlog_cache_disk_use para ajustar binlog_cache_size y evitar escrituras temporales en disco.