Ce n'est généralement pas le serveur de base de données qui est vulnérable aux erreurs lorsqu'un saut de temps instantané se produit: ce sont les applications qui utilisent le temps qui le sont.
Il existe généralement deux façons de suivre le temps: le suivi de son propre temps ou la comparaison de l'heure système. Les deux ont des compromis positifs et négatifs.
Suivi de son propre temps
Je vois cela utilisé dans certains programmes et systèmes intégrés où le timing exact n'est pas si critique. Dans une boucle d'application principale, un moyen de suivre un «tick» est pris en charge. Il peut s'agir d'une alarme donnée par le noyau, sleep ou select qui donne une indication du temps écoulé. Lorsque vous savez quelle heure est passée, vous savez que vous pouvez ajouter ou soustraire cette heure à un compteur. Ce compteur est ce qui rend votre application de chronométrage possible. Par exemple, si le compteur est supérieur à 10 secondes, vous pouvez jeter quelque chose ou vous devez faire quelque chose.
Si l'application ne garde pas l'heure, le compteur ne changera pas. Cela peut être souhaité en fonction de la conception de votre application. Par exemple, il est plus facile de suivre la durée pendant laquelle un processus de longue durée prend quelque chose est géré avec un compteur qu'une liste d'horodatages de démarrage / arrêt.
Pro:
- Ne dépend pas de l'horloge système
- Ne se brisera pas sur un grand décalage de temps
- Aucun appel système coûteux
- Les petits compteurs coûteront moins de mémoire qu'un horodatage complet
Con:
- Le temps n'est pas très précis
- Un changement d'heure système pourrait le rendre encore plus inexact
- Le timing est relatif à l'exécution de l'application, ne persiste pas
Comparaison de l'heure système
Il s'agit du système utilisé le plus souvent: stocker un horodatage et le comparer avec l'horodatage à l'aide d'un appel d'heure système. D'énormes asymétries dans l'heure du système peuvent menacer l'intégrité de votre application, une tâche de quelques secondes peut prendre des heures ou se terminer immédiatement selon le sens de l'horloge.
Pro:
- Comparaison précise du temps
- Persiste sur les redémarrages et les longues pannes
Con:
- Prend un appel système pour obtenir un nouvel horodatage à comparer avec d'autres horodatages
- L'application doit être consciente des biais ou peut se casser
Systèmes concernés
La plupart des applications utiliseront l'horodatage pour comparer les tâches planifiées. Pour les systèmes de base de données qui pourraient être des nettoyages de cache.
Toutes les applications qui utilisent une base de données et des fonctions de temps d'appel dans le langage de requête seront affectées par des biais si l'application ne détecte pas et ne gère pas en conséquence. Les applications ne pouvaient jamais s'arrêter de fonctionner ou autoriser des périodes de connexion indéfinies en fonction de leur objectif.
Les systèmes de messagerie utiliseront des horodatages et / ou des délais pour gérer les courriers périmés ou non livrés. Un décalage d'horloge pourrait affecter cela, mais avec un impact beaucoup moins. Les temporisations de recul concernant la reconnexion aux serveurs pourraient être manquées, ce qui entraînerait des pénalités sur le serveur de connexion.
Je ne pense pas (n'ai pas fait de recherche) que les alarmes du noyau se déclenchent lors du changement de l'heure du système. Les systèmes qui les utilisent pourraient être sûrs.
Solutions
Déplacez doucement le temps. Cela peut être trouvé dans la documentation de votre solution de temps préférée.
now()
. Pouvez-vous ajouter une méthode sûre pour changer l'heure à votre réponse?