# Réconcilier deux horloges serveur qui dérivent avant un import planifié

> Une tâche planifiée déclenchée à la mauvaise minute sur deux serveurs mal synchronisés peut dupliquer un traitement au lieu de l'enchaîner. Diagnostic et correctif.

- Auteur : WordPress Développement
- Publié le : 2021-06-18
- Mis à jour le : 2021-06-18
- Catégorie : Outils & workflow
- URL : https://www.wpmoderne.fr/outils/reconcilier-horloges-serveur-avant-import/

## L’essentiel

- Deux horloges qui dérivent cassent l'ordre attendu d'un traitement en deux étapes
- Les journaux datés deviennent incohérents et compliquent le diagnostic
- La synchronisation NTP corrige la cause, pas seulement le symptôme

`Traitement lancé à 02:58, alors que l'export attendu n'était disponible qu'à partir de 03:02` : cette ligne, retrouvée dans le journal d'un serveur de traitement, a mis sur la piste d'un incident qui semblait pourtant relever d'un bug applicatif. Un import planifié dupliquait certaines lignes de données une nuit sur trois, sans schéma évident au premier regard.

## Symptôme : une duplication intermittente, difficile à reproduire à la demande

L'incident se manifestait par des doublons dans une table de synchronisation entre deux systèmes, mais uniquement certaines nuits, sans lien apparent avec le volume de données traité ni avec une modification récente du code. Relancer manuellement le traitement en journée ne reproduisait jamais le problème, ce qui a longtemps orienté les recherches vers une fausse piste applicative.

## Diagnostic : deux tâches planifiées sur deux serveurs distincts

> L'essentiel à retenir : Deux horloges qui dérivent cassent l'ordre attendu d'un traitement en deux étapes ; Les journaux datés deviennent incohérents et compliquent le diagnostic ; La synchronisation NTP corrige la cause, pas seulement le symptôme

Le traitement reposait sur deux serveurs distincts : un premier générait un fichier d'export à 03:00 précises selon sa propre horloge système, un second, à 03:00 selon la sienne, allait chercher ce fichier pour l'importer. En croisant les journaux horodatés des deux machines avec une source de temps externe fiable, l'écart est apparu clairement : l'horloge du second serveur avançait de près de quatre minutes sur celle du premier, un écart qui s'accumulait progressivement depuis plusieurs semaines sans synchronisation corrective.

Certaines nuits, cet écart suffisait pour que le second serveur déclenche son import avant que le premier n'ait terminé d'écrire le fichier d'export complet. Le second serveur lisait alors un fichier partiel, puis une tâche planifiée de rattrapage relançait l'import une fois le fichier complété, sans vérifier si un premier import partiel avait déjà inséré une partie des lignes.

- Les journaux horodatés de deux serveurs différents ne sont comparables que si leurs horloges sont synchronisées sur une même référence.
- Une dérive de quelques minutes suffit à inverser l'ordre attendu entre deux tâches planifiées dépendantes l'une de l'autre.
- Un traitement de rattrapage mal conçu peut aggraver le problème plutôt que le corriger, en insérant les données une deuxième fois.

## Correctif : synchroniser les deux horloges sur une référence commune

La correction immédiate a consisté à installer et activer un client de synchronisation d'horloge basé sur le protocole NTP sur les deux serveurs, en les pointant vers les mêmes serveurs de temps de référence. Une fois cette synchronisation active, l'écart mesuré entre les deux machines est redescendu à quelques dizaines de millisecondes, largement suffisant pour garantir l'ordre attendu entre les deux tâches planifiées.

```
timedatectl set-ntp true
timedatectl timesync-status
```

Cette commande, exécutée sur chacun des deux serveurs, a permis de vérifier que le service de synchronisation était actif et correctement connecté à une source de temps de référence.

## Prévention : ne plus dépendre uniquement de deux horloges alignées

Corriger la synchronisation d'horloge traite la cause immédiate, mais une dépendance aussi stricte entre deux tâches planifiées reste fragile par nature. Le traitement d'import a ensuite été modifié pour vérifier explicitement la présence d'un indicateur de fin d'écriture avant de démarrer, plutôt que de se fier uniquement à un horaire fixe supposé postérieur à la fin de l'export.

1. Surveiller régulièrement l'écart d'horloge entre les serveurs qui exécutent des tâches planifiées dépendantes.
2. Ajouter une marge de sécurité entre deux tâches planifiées liées, plutôt que de les espacer au plus juste.
3. Faire dépendre le démarrage d'un traitement d'un indicateur explicite de disponibilité, pas seulement d'un horaire.
4. Rendre le traitement d'import idempotent, capable de détecter et d'ignorer une ligne déjà insérée.

> Deux horloges qui dérivent racontent deux histoires différentes du même incident ; sans les aligner d'abord, le diagnostic tourne en rond.

## En résumé

Une duplication de données apparemment aléatoire cachait une dérive d'horloge silencieuse entre deux serveurs dépendants l'un de l'autre. La synchronisation NTP a corrigé la cause immédiate, mais la vraie prévention est venue de la suppression de la dépendance stricte à un horaire fixe, remplacée par une vérification explicite de disponibilité avant chaque traitement enchaîné.