Replicación y consistencia entre réplicas

En un esquema con proveedor y consumidores, los cambios se escriben en un servidor y se copian a los demás. La copia no es instantánea: entre el cambio y su llegada hay un retraso. A eso se le llama consistencia eventual: si no hay más cambios, todas las réplicas acaban iguales, pero mientras tanto pueden diferir. Para identidad, la pregunta es cuánto retraso tolera cada decisión: no es lo mismo una foto de perfil que la desactivación de una cuenta.

Abre la topología y el estado de las réplicas.

ls replicas
cat replicas/topologia.txt
cat replicas/estado-de-replicas.csv

La política de la universidad fija un máximo: una réplica que atrasa más de 120 segundos al proveedor no debe atender autenticaciones. El retraso se calcula restando el último cambio aplicado por la réplica a la hora del informe, que está en la topología. No te fíes de que dos servidores «digan lo mismo»: mira las horas.

El retraso en tiempo tiene un equivalente en datos: cuántas entradas no han llegado. Comparar el número de entradas del proveedor con el de cada réplica es la comprobación más barata para saber si una réplica está completa, aunque no detecta cambios en entradas que ya existen.

Comparar cuenta por cuenta es lo que descubre el efecto real del atraso. Lee la comparación del estado de cinco cuentas en los tres servidores y la hora en la que el proveedor registró cada cambio. Una cuenta que ya está inactiva en el proveedor y sigue activa en una réplica es una baja que no llegó.

cat replicas/comparacion-de-cuentas.csv

Un atraso casi siempre tiene una causa visible en el registro de replicación. Léelo de arriba abajo: el último cambio aplicado, el primer error, los reintentos. No basta con saber que la réplica falla; hay que decir por qué, para que se corrija la causa y no solo el síntoma.

cat replicas/registro-de-replicacion.log