Replicación de MySQL tras una caída de VPN: lea primero las dos etapas

El monitoreo de la replicación se pone en rojo cuando cae la VPN, y el instinto es restablecer una posición. Ese instinto es la forma en que una interrupción de red se convierte en un problema de datos. Una ruta caída no dice nada sobre lo que la réplica ha recibido o aplicado, y esas son dos etapas con dos estados. Léalas por separado antes de cambiar nada.

Dos etapas, dos respuestas separadas

Una réplica asíncrona convencional hace dos trabajos. El receptor se conecta al origen, extrae eventos y los escribe localmente en el registro de retransmisión. El aplicador lee ese registro y ejecuta los eventos contra la réplica. Cuando la ruta se rompe, el receptor se detiene de inmediato mientras el aplicador sigue trabajando el atraso que ya está en disco. Por tanto, una interrupción produce dos preguntas distintas: ¿ha vuelto la conexión y se ha aplicado el trabajo acumulado? Tratarlas como una sola pregunta promedia dos estados en una respuesta engañosa.

Que el receptor se recupere le dice que la ruta está activa. No dice nada sobre cuánto va retrasado el aplicador ni sobre si encontró un error mientras estaba desconectado.

Lea el canal con la sentencia correcta

En MySQL 8.4, SHOW REPLICA STATUS devuelve una fila por canal configurado, así que lea la fila del canal que le interesa y no la primera de la lista. Replica_IO_Running separa un receptor conectado de uno que está conectando o detenido, y Replica_SQL_Running describe al aplicador. Lea las columnas de error junto a ellas, porque un receptor que se reconecta y falla de inmediato deja un mensaje que ninguna bandera de estado mostrará. Las versiones antiguas usan nombres de columna distintos, así que no traduzca una receta antigua limitándose a renombrar los comandos.

Compruebe también la identidad del origen y los filtros configurados. Una réplica apuntada al origen equivocado, o filtrada más estrechamente de lo que cree, informa de salud mientras replica algo distinto de lo que espera.

Por qué un cero de retraso puede mentir

El valor de retraso compara la marca de tiempo del último evento aplicado con la hora actual. Cuando el receptor ha estado detenido una hora, el aplicador puede trabajar el atraso y llegar al final de lo que recibió, y entonces el número cae a cero aunque la réplica vaya una hora por detrás del origen. La métrica mide la cola del aplicador, no la actualidad de la réplica.

Compare en cambio las transacciones ejecutadas con lo que el origen tiene disponible. Esa comparación sobrevive a un receptor atascado.

La retención fija la ventana real de recuperación

Ponerse al día exige que el origen siga conservando las transacciones que la réplica necesita. Una vez purgadas, la réplica no puede obtenerlas, y ninguna cantidad de reconexiones lo cambia.

Con el autoposicionamiento GTID el fallo es explícito: la réplica pide un historial que el origen ya no conserva y se niega a continuar. Las opciones entonces son obtener los eventos que faltan de un origen que aún los tiene, o reconstruir desde una copia de seguridad y dejar que se ponga al día. Saltarse el hueco no es ponerse al día, y deja una réplica cuyos datos están silenciosamente incompletos. Planifique la ventana comparando la duración esperada de la interrupción con la retención del registro binario en el origen y el ritmo de cambio, porque esos tres números deciden si una interrupción es recuperable siquiera.

Verifique la puesta al día, no el color de un indicador

Restaure la ruta, incluida la resolución de nombres y la seguridad del transporte, y luego observe si el canal existente se reconecta según su propia política. Dé un intervalo definido antes de intervenir y registre el progreso de recepción y aplicación en ambos extremos de ese intervalo. Un canal que se reinicia y un canal que está al día son hallazgos distintos.

Confirme que el aplicador ha alcanzado la posición actual del origen, no solo el final del atraso antiguo. Compruebe que no espera ningún error en el aplicador, porque un evento fallido detiene el progreso mientras el receptor sigue informando de que está conectado. Después registre la evidencia: nombre del canal, ambos estados de etapa, la posición ejecutada y la hora. Un indicador verde es una afirmación; la posición es un hecho.