Solución Rápida de Fallos Comunes en la Replicación de MySQL

Los fallos en la replicación de MySQL son más fáciles de solucionar cuando separa dos preguntas: ¿puede la réplica obtener eventos de la fuente? y ¿puede aplicar los eventos que ya obtuvo? Son fallos diferentes. Un problema de red, un registro binario faltante, una contraseña incorrecta o un permiso de host equivocado generalmente detienen el hilo de E/S. Una clave duplicada, una fila faltante, una discrepancia en DDL o una deriva de datos generalmente detienen el hilo SQL.

Comience con la salida de estado. En MySQL moderno:

SHOW REPLICA STATUS\G

En sistemas antiguos:

SHOW SLAVE STATUS\G

Use el comando que su servidor soporte. La salida más nueva usa nombres como Replica_IO_Running, Replica_SQL_Running y Seconds_Behind_Source. La salida antigua usa Slave_IO_Running, Slave_SQL_Running y Seconds_Behind_Master.

La primera lectura útil es:

Replica_IO_Running: si la réplica está conectada y leyendo los registros binarios de la fuente.
Replica_SQL_Running: si la réplica está aplicando eventos del registro de retransmisión.
Last_IO_Errno y Last_IO_Error: por qué falló la obtención.
Last_SQL_Errno y Last_SQL_Error: por qué falló la aplicación.
Relay_Master_Log_File, Exec_Master_Log_Pos o campos de posición de fuente más nuevos: dónde está la réplica en el flujo.

No se salte directamente a una solución. Copie primero la salida completa del estado en sus notas del incidente. Una vez que ejecute RESET REPLICA, omita una transacción o redirija la réplica, desaparece la mejor evidencia.

Si el Hilo de E/S Está Detenido

Cuando Replica_IO_Running es No, la réplica no está leyendo correctamente de la fuente. El hilo SQL puede seguir aplicando eventos antiguos del registro de retransmisión por un tiempo, pero eventualmente se quedará sin ellos.

Las causas comunes son:

El host o puerto de la fuente es incorrecto.
Un firewall, grupo de seguridad o regla de enrutamiento bloquea la conexión.
La contraseña del usuario de replicación es incorrecta.
El usuario de replicación está permitido desde un host diferente al que realmente usa la réplica.
El registro binario está deshabilitado en la fuente.
La fuente ha purgado el archivo de registro binario que la réplica solicitó.
La configuración TLS cambió y la réplica ya no puede autenticarse.

Pruebe desde el host de la réplica:

mysql -h source-db.example.com -u repl_user -p

Si un inicio de sesión directo falla, la replicación también fallará. Verifique la cuenta en la fuente:

SHOW GRANTS FOR 'repl_user'@'replica_host_or_ip';

La cuenta necesita el privilegio REPLICATION SLAVE. El nombre del privilegio aún usa "SLAVE" en las concesiones de MySQL.

También verifique si el registro binario está habilitado:

SHOW VARIABLES LIKE 'log_bin';
SHOW MASTER STATUS;

En versiones más nuevas, SHOW BINARY LOG STATUS puede estar disponible. El punto es el mismo: la fuente debe tener registros binarios y el archivo solicitado debe existir.

Error 1236: Registro Binario Faltante o Ilegible

Last_IO_Errno: 1236 es uno de los errores que generalmente significa que la réplica está solicitando un archivo de registro binario o una posición que la fuente no puede proporcionar. El mensaje exacto varía. Puede decir que el primer archivo de registro no se puede encontrar, que no se pudo leer un evento de registro o que la fuente cerró la conexión mientras leía.

El caso operativo más común es simple: la réplica estuvo inactiva demasiado tiempo y la fuente purgó los registros binarios que necesitaba.

Verifique qué registros quedan en la fuente:

SHOW BINARY LOGS;

Luego compare esa lista con el archivo nombrado en el estado de la réplica. Si la réplica necesita mysql-bin.000120 y la fuente ahora comienza en mysql-bin.000140, la réplica no puede ponerse al día desde los registros binarios.

Tiene tres opciones realistas:

Restaurar o reconstruir la réplica desde una copia de seguridad fresca tomada de la fuente.
Usar otra réplica que aún tenga los datos necesarios como fuente de clonación, si su proceso lo soporta.
Si usa GTID y las transacciones faltantes existen en otro lugar, reconfigurar desde una fuente válida que pueda proporcionarlas.

No adivine una posición de registro más nueva solo para que la replicación se inicie. Eso crea una réplica con transacciones faltantes. Puede parecer saludable mientras devuelve datos incorrectos silenciosamente.

Después de la recuperación, aumente la retención de registros binarios si la capacidad del disco lo permite:

[mysqld]
binlog_expire_logs_seconds=604800

Ese ejemplo es aproximadamente 7 días. Elija un valor basado en cuánto tiempo las réplicas pueden estar fuera de línea durante el mantenimiento o incidentes.

Si el Hilo SQL Está Detenido

Cuando Replica_SQL_Running es No, la réplica obtuvo eventos pero no pudo aplicar uno. Esto suele ser un problema de consistencia de datos, no un problema de conexión.

Lea el Last_SQL_Error completo. Generalmente le indica la tabla, clave, operación fallida y, a veces, la posición del registro de la fuente. Luego inspeccione la fila relevante tanto en la fuente como en la réplica antes de cambiar algo.

Para un evento fallido alrededor de una posición conocida del registro binario, mysqlbinlog puede mostrar el evento:

mysqlbinlog --start-position=123456 --stop-position=124500 /var/lib/mysql/mysql-bin.000321

Si los registros binarios de la fuente no están en el host local, use opciones remotas o inspeccione un archivo de registro copiado. Tenga cuidado con los eventos basados en filas: pueden necesitar opciones de decodificación y metadatos de tabla para ser legibles.

Error 1062: Entrada Duplicada

Last_SQL_Errno: 1062 significa que la réplica intentó insertar o actualizar una fila y encontró una clave única que ya existe.

Las causas típicas incluyen:

Alguien escribió directamente en la réplica.
La réplica se inicializó desde la instantánea incorrecta.
Se omitió un error de replicación anterior.
La configuración de auto-incremento es incorrecta en un diseño de múltiples fuentes o activo-activo.
Las escrituras de la aplicación fueron a dos servidores escribibles por error.

La solución tentadora es:

STOP REPLICA;
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
START REPLICA;

La sintaxis antigua usa STOP SLAVE y START SLAVE. Esto puede ser aceptable para una réplica de informes desechable después de confirmar que la fila no importa. Es peligroso para una réplica que puede ser promovida más tarde. Omitir significa que la réplica ya no tiene el mismo historial de transacciones que la fuente.

Un proceso más seguro es:

Identificar la tabla y clave en conflicto.
Comparar la fila en la fuente y la réplica.
Decidir si la fila de la réplica debe eliminarse, actualizarse o si la réplica debe reconstruirse.
Registrar la decisión, porque ahora es un evento de consistencia de datos.

Si la réplica está destinada a la conmutación por error, reconstruir suele ser más limpio que parchear varias diferencias desconocidas a mano.

Error 1032: No se Puede Encontrar el Registro

Last_SQL_Errno: 1032 generalmente significa que la réplica intentó actualizar o eliminar una fila que no existe localmente. Esta es la imagen espejo de muchos problemas de clave duplicada. La fuente tenía una fila; la réplica no.

Las causas comunes son:

Una fila fue eliminada manualmente en la réplica.
Se omitió una transacción anterior.
El volcado inicial perdió datos.
Los filtros de replicación excluyeron escrituras anteriores.

No asuma que la fila faltante es inofensiva. Si una UPDATE no puede encontrar una fila, la réplica ya es diferente de la fuente. Compare recuentos y datos de muestra alrededor de la clave afectada. Si la tabla es pequeña, una recarga de tabla puede ser razonable. Si es grande o crítica, use una herramienta de consistencia o reconstruya la réplica.

Problemas de Autenticación y Concesiones de Host

Un fallo muy común después de la rotación de contraseñas o cambios de red es un error de E/S que parece acceso denegado:

Access denied for user 'repl_user'@'10.0.2.15'

El host en el error es el que MySQL ve. Puede no coincidir con el nombre de host que esperaba, especialmente con NAT, proxies o redes de contenedores.

En la fuente, inspeccione los usuarios:

SELECT user, host, plugin FROM mysql.user WHERE user = 'repl_user';

Si la réplica se conecta desde 10.0.2.15, una concesión para 'repl_user'@'replica.internal' puede no coincidir a menos que la resolución de nombres y las concesiones estén alineadas. Prefiera patrones de host explícitos que coincidan con su diseño de red.

Si el plugin difiere, los clientes antiguos pueden fallar contra cuentas que usan plugins de autenticación más nuevos. Actualizar el cliente suele ser mejor que debilitar la autenticación, pero en entornos de versiones mixtas puede necesitar un cambio de compatibilidad planificado.

Problemas con el Registro de Retransmisión

A veces la conexión de la fuente está bien, pero la réplica tiene corrupción del registro de retransmisión o problemas de disco local. El error puede mencionar un fallo de lectura del registro de retransmisión, un evento truncado o una posición del registro de retransmisión.

Primero verifique la salud del disco y el espacio libre. Un disco lleno puede crear varios síntomas extraños de replicación:

df -h
iostat -xz 1

Si el registro de retransmisión está corrupto pero la fuente aún tiene los registros binarios necesarios, a menudo puede restablecer los registros de retransmisión y dejar que la réplica los obtenga de nuevo. El comando exacto depende de la versión y la topología. No ejecute comandos de restablecimiento a la ligera; confirme que conoce el archivo de registro de la fuente y la posición que ya se ha ejecutado.

En muchos casos, este tipo de problema es una señal de que el host de la réplica tuvo un problema de almacenamiento subyacente. Solucione eso antes de confiar nuevamente en la réplica.

El Retraso en la Replicación No Siempre es un Fallo

Seconds_Behind_Source puede ser alto mientras ambos hilos están en ejecución. Eso significa que la replicación está viva pero retrasada. Trate el retraso de manera diferente a un hilo detenido.

Verifique:

¿Está el disco de la réplica saturado?
¿Está la fuente generando una ráfaga de escrituras?
¿Están las lecturas largas en la réplica compitiendo con el hilo SQL?
¿Es la réplica más pequeña o más lenta que la fuente?
¿Comenzó un trabajo de copia de seguridad o instantánea al mismo tiempo?

Si el retraso está disminuyendo, la réplica se está poniendo al día. Si el retraso está creciendo, elimine carga o agregue capacidad. Reiniciar una réplica retrasada rara vez soluciona un cuello de botella de recursos sostenido.

Filtros y Replicación de Múltiples Fuentes

Los filtros de replicación pueden hacer que los fallos sean más difíciles de leer. Una réplica puede ignorar intencionalmente algunas bases de datos o tablas, pero la aplicación aún puede esperar que existan datos relacionados. Si usa filtros, inspecciónelos antes de asumir que la réplica está corrupta:

SHOW REPLICA STATUS\G

Busque campos que mencionen Replicate_Do_DB, Replicate_Ignore_DB, Replicate_Do_Table o reglas de reescritura. La salida antigua usa los mismos nombres generales bajo SHOW SLAVE STATUS.

El filtrado es especialmente riesgoso con escrituras entre bases de datos. Si una transacción actualiza app.orders y audit.order_events, pero la réplica filtra audit, la copia resultante puede ser técnicamente consistente con el filtro y aún así inútil para un flujo de trabajo que espera filas de auditoría. El registro basado en declaraciones puede hacer que los filtros de base de datos sean aún más sorprendentes porque la base de datos predeterminada seleccionada puede influir en si un evento se replica.

La replicación de múltiples fuentes agrega otra capa. Un canal puede estar saludable mientras otro está detenido. En ese caso, verifique el estado de todos los canales en lugar de leer solo el primer bloque de salida:

SHOW REPLICA STATUS\G

En configuraciones basadas en canales, la salida de estado incluye un nombre de canal. Solucione el canal fallido sin restablecer canales saludables. Si dos fuentes pueden escribir claves superpuestas en la misma tabla, los errores de clave duplicada suelen ser un problema de diseño en lugar de un fallo de replicación aislado.

Evite la Deriva Oculta de Datos

El peor fallo de replicación es el que dice Yes y aún contiene datos incorrectos. La deriva puede ocurrir después de transacciones omitidas, escrituras directas en réplicas, importaciones fallidas, filtros incorrectos o reparaciones manuales.

Para réplicas importantes, programe verificaciones de consistencia. El pt-table-checksum de Percona Toolkit se usa comúnmente para esto, y pt-table-sync puede ayudar a reparar diferencias en situaciones controladas. Estas herramientas pueden crear carga, así que pruébelas primero y ejecútelas con límites que coincidan con su entorno de producción.

También proteja las réplicas de escrituras accidentales:

[mysqld]
read_only=ON
super_read_only=ON

Use credenciales separadas para las lecturas de la aplicación. No permita que los usuarios de la aplicación tengan amplios privilegios de escritura en las réplicas "por si acaso".

Una Lista de Verificación Rápida para Incidentes

Use este orden cuando la replicación se rompa:

Guarde la salida de SHOW REPLICA STATUS\G.
Verifique si el hilo de E/S o el hilo SQL se detuvieron.
Lea Last_IO_Error o Last_SQL_Error; no confíe solo en el número de error.
Verifique el registro de errores de MySQL para marcas de tiempo coincidentes.
Para fallos de E/S, pruebe la red, credenciales, concesiones, TLS y disponibilidad del registro binario.
Para fallos SQL, inspeccione la fila o tabla afectada tanto en la fuente como en la réplica.
Decida si reparar, omitir con riesgo documentado, recargar una tabla o reconstruir la réplica.
Después de la recuperación, ejecute una prueba de escritura real y monitoree el retraso.

La mayoría de los fallos de replicación de MySQL no se resuelven con un comando mágico. Se resuelven preservando la evidencia, identificando qué hilo falló y eligiendo una solución que no deje una réplica que funcione pero no sea confiable.