Risque de démarrer NTP sur le serveur de base de données?

J'ai entendu des rumeurs de mauvaises choses se produisant sur les serveurs de base de données et de messagerie si vous modifiez l'heure du système pendant leur fonctionnement. Cependant, j'ai du mal à trouver des informations concrètes sur les risques réels.

J'ai un serveur de production Postgres 9.3 fonctionnant sur un hôte Debian Wheezy et le temps est désactivé de 367 secondes. Puis-je simplement exécuter ntpdateou démarrer openntp pendant l'exécution de Postgres, ou est-ce susceptible de provoquer un problème? Si oui, quelle est une méthode plus sûre pour corriger l'heure?

Existe-t-il d'autres services plus sensibles à un changement d'heure système? Peut-être des serveurs de messagerie (exim, sendmail, etc.) ou des files d'attente de messages (activemq, rabbitmq, zeromq, etc.)?

Les bases de données n'aiment pas les pas en arrière dans le temps, donc vous ne voulez pas commencer avec le comportement par défaut de sauter l'heure. L'ajout de l' -xoption à la ligne de commande fera grimper le temps si le décalage est inférieur à 600 secondes (10 minutes). À la vitesse de balayage maximale, il faudra environ un jour et demi pour régler l'horloge d'une minute. Il s'agit d'un moyen lent mais sûr de régler l'heure.

Avant d'exécuter ntppour régler l'heure, vous souhaiterez peut-être commencer ntppar une option telle que -g 2vérifier la taille d'un décalage qu'il détecte. Cela définira le décalage de panique à 2 secondes, ce qui devrait être relativement sûr.

Une autre option que j'ai utilisée avant que cette option ne soit disponible était d'écrire une boucle qui réinitialisait l'horloge en partie de seconde toutes les minutes environ. Si vous vérifiez que la réinitialisation ne changera pas la seconde, cela est probablement sûr. Si vous utilisez fortement les horodatages, vous pouvez avoir des enregistrements hors séquence.

Une option courante consiste à arrêter le serveur suffisamment longtemps pour qu'il n'y ait pas de retour en arrière de l'horloge. ntpou ntpdatepeut être configuré pour faire passer l'horloge à l'heure correcte au démarrage. Cela doit être fait avant le démarrage de la base de données.

Les bases de données peuvent être particulièrement vulnérables aux changements d'heure système si elles sont très actives et ont des horodatages sur les enregistrements internes. En général, si vous avez du temps, vous aurez beaucoup moins de problèmes si vous sautez soudainement en avant que si vous êtes devant et sautez soudainement en arrière.

Comme le souligne Joffrey - c'est beaucoup plus souvent l'application qui a des problèmes avec des sauts de temps soudains que la base de données elle-même. La façon la plus sûre de corriger l'heure est d'arrêter l'application pendant N + 1 minutes (où N est le nombre de minutes de votre horloge système), puis de synchroniser l'heure, de démarrer NTP et de redémarrer l'application. Si vous ne pouvez pas prendre autant de temps d'arrêt dans l'application, je ne peux que vous suggérer de faire une sauvegarde de la base de données avant de synchroniser l'heure, puis d'offrir un écureuil mort au goda de l'informatique et d'appuyer simplement sur la gâchette. Ok, je suis un peu facétieux, mais je ne peux penser à aucun autre moyen "sûr" que de prendre une application en panne.

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.