Flujo de trabajo para la implementación

Para establecer un entorno de replicación robusto en MySQL, es necesario seguir una secuencia lógica de configuración tanto en la instancia de origen (Maestro) como en la de destino (Esclavo):

1. Habilitar el registro binario (binlog) y asignar un identificador único en el servidor maestro.
2. Definir un ID único en cada esclavo y crear credenciales específicas para el proceso de lectura de logs.
3. Capturar las coordenadas actaules del archivo binario (archivo y posición) en el maestro antes de iniciar la sincronización.
4. Realizar un volcado de datos inicial (snapshot) mediante mysqldump si la base de datos ya contiene información.
5. Vincular el esclavo al maestro utilizando los parámetros de red, credanciales y coordenadas del log obtenidas previamente.

Configuración del Servidor Maestro (my.cnf)

En el archivo de configuración del maestro, generalmente ubicado en /etc/my.cnf o /etc/mysql/my.cnf, debemos definir el comportamiento del log binario:

[mysqld]
# Identificador único del servidor
server-id = 101
# Activación y ruta del log binario
log-bin = /var/lib/mysql/mysql-bin.log
# Formato de replicación recomendado para integridad de datos
binlog_format = ROW
# Base de datos específica a replicar
binlog-do-db = db_produccion
# Límite de tamaño del log antes de rotar
max_binlog_size = 1G
# Tiempo de retención de los logs (7 días)
binlog_expire_logs_seconds = 604800
# Sincronización estricta para evitar pérdida de datos en crashes
sync_binlog = 1
innodb_flush_log_at_trx_commit = 1
# Recuperación automática de logs de relevo
relay_log_recovery = 1

Configuración del Servidor Esclavo (my.cnf)

El esclavo requiere un server-id distinto al del maestro para evitar conflictos en el clúster:

[mysqld]
server-id = 102
# Aunque sea esclavo, se recomienda habilitar logs para encadenar replicaciones
log-bin = mysql-bin
relay-log = /var/lib/mysql/mysql-relay-bin
# Base de datos que se desea procesar localmente
replicate-do-db = db_produccion
read_only = 1

Tras modificar los archivos, es indispensable reiniciar el servicio mediante systemctl restart mysqld.

Preparación de Datos y Sincronización Inicial

Para garantizar que el esclavo comience desde un estado idéntico al maestro, se debe realizar una exportación controlada:

-- En el Maestro: Bloquear tablas para obtener consistencia
FLUSH TABLES WITH READ LOCK;

-- Obtener las coordenadas del log
SHOW MASTER STATUS;
-- Resultado esperado: File: mysql-bin.000001, Position: 450

Desde la terminal del sistema, exportamos la base de datos:

mysqldump -u root -p --all-databases --master-data=2 > backup_inicial.sql

Una vez completado el volcado, liberamos el bloqueo en el maestro:

UNLOCK TABLES;

En el esclavo, importamos el archivo generado:

mysql -u root -p < backup_inicial.sql

Activación de la Replicación

Con el esclavo actualizado, ejecutamos la sentencia para establecer el enlace:

CHANGE MASTER TO 
    MASTER_HOST='192.168.1.100', 
    MASTER_USER='repl_user',
    MASTER_PASSWORD='password_seguro', 
    MASTER_LOG_FILE='mysql-bin.000001',
    MASTER_LOG_POS=450;

-- Iniciar el proceso
START SLAVE;

-- Verificar el estado
SHOW SLAVE STATUS\G;

Gestión de Formatos de Binlog

Existen tres modalidades principales para el registro de operaciones:

• STATEMENT: Registra las sentencias SQL literales. Es eficiente en espacio pero puede causar inconsistencias con funciones no deterministas como NOW() o UUID().
• ROW: Registra los cambios reales en cada fila. Es el método más seguro para garantizar la paridad de datos entre nodos, aunque ganera archivos de log más voluminosos.
• MIXED: Combina ambos; usa STATEMENT por defecto y cambia a ROW cuando detecta operaciones que podrían comprometer la consistencia.

Resolución de Problemas Comunes

1. Error de Autenticación (Plugin caching_sha2_password)

Si el esclavo no puede conectar por restricciones de cifrado en MySQL 8.0+, ajuste el usuario de replicación:

ALTER USER 'repl_user'@'%' IDENTIFIED WITH mysql_native_password BY 'password_seguro';
FLUSH PRIVILEGES;

2. Error 1236: Archivo de log no encontrado

Este error ocurre cuando el maestro ha purgado los logs que el esclavo aún necesita. Si el desajuste es crítico, se debe reiniciar la replicación:

-- En el Maestro
RESET MASTER;
SHOW MASTER STATUS;

-- En el Esclavo
STOP SLAVE;
RESET SLAVE ALL;
-- Reconfigurar con las nuevas coordenadas obtenidas

3. Conflicto de Datos en el Applier

Si el esclavo intenta insertar un registro que ya existe o borrar uno inexistente, el hilo SQL se detendrá. Para investigar:

SELECT * FROM performance_schema.replication_applier_status_by_worker\G;

Se recomienda corregir el dato manualmente en el esclavo para que coincida con el maestro y luego ejecutar START SLAVE.