Desfase de reloj / problema de NTP

Síntoma

Diferencias de reloj entre los nodos del clúster; inconsistencias de replicación/elección, 'certificate not yet valid', saltos de tiempo en los logs.

1. Reconozca el síntoma

El desfase de reloj es traicionero: elecciones inestables (flapping) en Mongo/Redis Sentinel, errores TLS 'not yet valid/expired', errores de Kerberos, marcas de tiempo que retroceden en los logs. En sistemas distribuidos es la raíz de la mayoría de las rarezas 'inexplicables'.

2. Mida la diferencia

En cada nodo, compare la fuente de tiempo y el offset: timedatectl, chronyc tracking (o ntpq -p) y date -u entre nodos. ¿Cuántos ms/s de diferencia hay?

3. Corrija NTP/chrony

¿Se está ejecutando chronyd/ntpd, alcanza sus fuentes de tiempo, está sincronizado? Inicie el servicio y corrija la fuente; ante offsets grandes, ajuste con cuidado (un salto brusco puede afectar a algunas BD).

4. Verifique el componente afectado

Tras corregir el reloj, compruebe: ¿la elección del replica set de MongoDB es estable, Redis Sentinel/Cluster está sano, los handshakes TLS se completan, se han recuperado las métricas de lag de replicación?

5. Permanente

Haga NTP obligatorio en todos los nodos y monitoree el offset (alerta: >100ms). En máquinas virtuales, defina claramente la sincronización de hora host-invitado; preferiblemente use una única jerarquía de fuentes de tiempo fiable.