Réplica rota / se necesita resincronización
La sincronización entre la réplica/standby y el primario está rota. Determine si la replicación se ha detenido, cuánto retraso lleva y si la cadena de posición/GTID está rota; luego tome el camino correcto entre omitir un error, esperar o reconstruir (reseed). Incluye una advertencia de split-brain.
¿Cuál es el estado general de la replicación?
Lea primero la salud de la replicación: ¿se están ejecutando los hilos de aplicación, cuánto retraso hay, hay algún error? Verifique también que los dos nodos no estén aceptando escrituras a la vez (split-brain).
SHOW REPLICA STATUS\G
-- Check: Replica_IO_Running, Replica_SQL_Running, Seconds_Behind_Source, Last_Error, Retrieved/Executed_Gtid_Set- La replicación se ha detenido / está fallando
- Funciona, pero con mucho retraso (lag grande)
- GTID/posición rotos, inconsistente: reconstruir
- Ambos nodos escriben como primario (sospecha de split-brain)
¿Se puede reparar el error o hace falta una reconstrucción?
Examine el error de aplicación. Algunos errores (clave duplicada, fila ausente) pueden resolverse omitiendo de forma segura un único evento; pero si hay inconsistencia/corrupción de datos, el único camino correcto es reconstruir la réplica.
SHOW REPLICA STATUS\G
-- Check: Last_SQL_Errno, Last_SQL_Error, Last_IO_Errno, Last_IO_Error- Uno o pocos errores de aplicación (omitibles)
- Inconsistencia / corrupción irreparable
¿El retraso es temporal o persistente?
Observe la tendencia del retraso a lo largo del tiempo. ¿Se cierra (se pone al día) tras un pico de carga temporal, o sigue creciendo de forma que la réplica nunca alcanza al primario?
SHOW REPLICA STATUS\G
-- Measure Seconds_Behind_Source several times: is it decreasing or increasing?- Pico de carga temporal; el retraso se está cerrando
- Sigue creciendo; no consigue ponerse al día
Solución: omitir con cuidado el error de aplicación
Si la replicación se detuvo por un único error de aplicación (p. ej. una clave duplicada) y está seguro de que los datos son realmente consistentes, puede omitir ese evento y continuar el flujo. Es un último recurso; omitir a ciegas crea una deriva silenciosa de los datos.
Solución: reconstruir la réplica (reseed / rebuild)
Si la cadena de posición/GTID está rota, los datos se han desviado o hay un error irreparable, el único camino fiable es reconstruir la réplica a partir de una copia nueva tomada del primario.
Causa raíz: pico de carga temporal (el retraso se está cerrando)
La replicación está sana; el retraso aumentó por una ráfaga temporal de escrituras en el primario o por fluctuaciones de red, pero la réplica se está poniendo al día.
Causa raíz: la réplica no puede seguir el ritmo del primario
El lado de aplicación (apply/redo) no puede seguir el ritmo de cambios que produce el primario; el retraso sigue creciendo. Normalmente se debe a una aplicación de un solo hilo, a un hardware lento en la réplica o a un cuello de botella de red.
ADVERTENCIA: split-brain (dos primarios): riesgo de pérdida de datos
Si ambos nodos aceptan escrituras con el rol de primario, se acumulan cambios en conflicto en ambos lados; es la situación más peligrosa y puede provocar pérdida de datos. Lo primero es reducir las escrituras a un solo nodo.