Ich habe Gerüchte gehört, dass Datenbank- und Mailservern etwas Schlimmes zustoßen, wenn man die Systemzeit ändert, während sie laufen. Konkrete Informationen zu tatsächlichen Risiken finde ich allerdings nicht.
Ich habe einen Postgres 9.3-Produktionsserver auf einem Debian Wheezy-Host laufen und die Zeit ist um 367 Sekunden falsch. Kann ich ntpdateopenntp einfach ausführen oder starten, während Postgres läuft, oder verursacht das wahrscheinlich ein Problem? Wenn ja, was ist eine sicherere Methode, die Zeit zu korrigieren?
Gibt es andere Dienste, die empfindlicher auf eine Änderung der Systemzeit reagieren? Vielleicht Mailserver (Exim, Sendmail usw.) oder Nachrichtenwarteschlangen (ActiveMQ, RabbitMQ, ZeroMQ usw.)?
Antwort1
Datenbanken mögen keine Rückschritte in der Zeit, daher sollten Sie nicht mit dem Standardverhalten des Zeitsprungs beginnen. Wenn Sie die -xOption zur Befehlszeile hinzufügen, wird die Zeit verschoben, wenn der Versatz weniger als 600 Sekunden (10 Minuten) beträgt. Bei maximaler Verschiebungsrate dauert es etwa anderthalb Tage, um die Uhr um eine Minute anzupassen. Dies ist eine langsame, aber sichere Möglichkeit, die Zeit anzupassen.
Bevor Sie ntpdie Zeit anpassen, sollten Sie zunächst ntpeine Option wie -g 2„Überprüfen, wie groß der erkannte Offset ist“ verwenden. Dadurch wird der Panik-Offset auf 2 Sekunden eingestellt, was relativ sicher sein sollte.
Eine alternative Option, die ich verwendet habe, bevor diese Option verfügbar war, bestand darin, eine Schleife zu schreiben, die die Uhr etwa jede Minute um einen Teil der Sekunde zurücksetzt. Wenn Sie sicherstellen, dass das Zurücksetzen die Sekunde nicht ändert, ist dies wahrscheinlich sicher. Wenn Sie häufig Zeitstempel verwenden, können Ihre Datensätze nicht in der richtigen Reihenfolge sein.
Eine gängige Option besteht darin, den Server so lange herunterzufahren, dass die Uhr nicht zurückgeht. ntpOder ntpdateSie können ihn so konfigurieren, dass die Uhr beim Start auf die richtige Zeit zurückspringt. Dies sollte erfolgen, bevor die Datenbank gestartet wird.
Antwort2
Datenbanken können besonders anfällig für Systemzeitänderungen sein, wenn sie sehr aktiv sind und Zeitstempel auf internen Datensätzen haben. Wenn Ihre Zeit zurückliegt, haben Sie im Allgemeinen viel weniger Probleme, wenn Sie plötzlich vorwärts springen, als wenn Sie vorwärts sind und plötzlich zurückspringen.
Wie Joffrey betont, ist es viel häufiger die Anwendung, die Probleme mit plötzlichen Zeitsprüngen hat, als die Datenbank selbst. Der sicherste Weg, die Zeit zu korrigieren, besteht darin, die Anwendung für N+1 Minuten herunterzufahren (wobei N die Anzahl der Minuten ist, um die Ihre Systemuhr vorgeht), dann die Zeit zu synchronisieren, NTP zu starten und die Anwendung neu zu starten. Wenn Sie eine so lange Ausfallzeit der Anwendung nicht ertragen können, kann ich Ihnen nur empfehlen, vor der Zeitsynchronisierung eine Sicherungskopie der Datenbank zu erstellen, dann dem Gott der Computerwelt ein totes Eichhörnchen anzubieten und einfach den Auslöser zu drücken. Ok, ich bin ein bisschen scherzhaft, aber mir fällt kein anderer „sicherer“ Weg ein, als einen Anwendungsausfall hinzunehmen.
Antwort3
Normalerweise ist es nicht der Datenbankserver, der bei einem sofortigen Zeitsprung fehleranfällig ist: Es sind die Anwendungen, die die Zeit verwenden.
Es gibt grundsätzlich zwei Möglichkeiten der Zeiterfassung: eigene Zeiterfassung oder Vergleich der Systemzeit. Beide haben positive und negative Vor- und Nachteile.
Eigene Zeiterfassung
Ich sehe, dass dies in einigen eingebetteten Programmen und Systemen verwendet wird, bei denen genaues Timing nicht so kritisch ist. In einer Hauptanwendungsschleife wird für eine Möglichkeit gesorgt, einen „Tick“ zu verfolgen. Dies könnte ein Alarm sein, der vom Kernel, Sleep oder Select ausgegeben wird und einen Hinweis auf die vergangene Zeit gibt. Wenn Sie wissen, wie viel Zeit vergangen ist, können Sie diese Zeit zu einem Zähler addieren oder davon subtrahieren. Dieser Zähler ist das, was Ihre Timing-Anwendung ausführt. Wenn der Zähler beispielsweise höher als 10 Sekunden ist, können Sie etwas verwerfen oder müssen etwas tun.
Wenn die Anwendung die Zeit nicht im Auge behält, ändert sich der Zähler nicht. Dies kann je nach Design Ihrer Anwendung erwünscht sein. Beispielsweise ist es mit einem Zähler einfacher, den Überblick darüber zu behalten, wie lange ein lang laufender Prozess für die Bearbeitung eines Vorgangs benötigt, als mit einer Liste von Start-/Stopp-Zeitstempeln.
Profi:
- Nicht abhängig von der Systemuhr
- Bricht nicht bei großer Schräglage
- Kein kostspieliger Systemaufruf
- Kleine Zähler benötigen weniger Speicher als ein vollständiger Zeitstempel
Nachteil:
- Die Zeit ist nicht sehr genau
- Eine Änderung der Systemzeit könnte zu noch größerer Ungenauigkeit führen
- Das Timing ist relativ zum Ausführen der Anwendung und bleibt nicht bestehen
Vergleichen der Systemzeit
Dies ist das am häufigsten verwendete System: Speichern Sie einen Zeitstempel und vergleichen Sie ihn mit dem Zeitstempel mithilfe eines Systemzeitaufrufs. Große Abweichungen in der Systemzeit können die Integrität Ihrer Anwendung gefährden. Eine Aufgabe von wenigen Sekunden kann je nach Richtung der Uhr Stunden dauern oder sofort beendet werden.
Profi:
- Genauer Zeitvergleich
- Bleibt nach Neustarts und längeren Ausfällen bestehen
Nachteil:
- Führt einen Systemaufruf aus, um einen neuen Zeitstempel zum Vergleich mit anderen Zeitstempeln abzurufen
- Die Anwendung muss auf Schräglagen achten, da sie sonst abbrechen kann
Betroffene Systeme
Die meisten Anwendungen verwenden Zeitstempelvergleiche, um Aufgaben zu planen. Bei Datenbanksystemen können das Cache-Bereinigungen sein.
Alle Anwendungen, die eine Datenbank verwenden und Zeitfunktionen in der Abfragesprache aufrufen, sind von Verzerrungen betroffen, wenn die Anwendung diese nicht erkennt und entsprechend behandelt. Anwendungen könnten je nach Zweck nie aufhören zu laufen oder unbegrenzte Anmeldezeiträume zulassen.
Mailsysteme verwenden Zeitstempel und/oder Timeouts für die Verarbeitung veralteter oder nicht zugestellter Mails. Eine Zeitabweichung könnte dies beeinflussen, allerdings mit deutlich geringerer Auswirkung. Back-off-Timer für die erneute Verbindung zu Servern könnten verpasst werden, was zu Strafen auf dem Verbindungsserver führen könnte.
Ich glaube nicht (habe es nicht untersucht), dass beim Ändern der Systemzeit Kernel-Alarme ausgelöst werden. Systeme, die diese verwenden, könnten sicher sein.
Lösungen
Verschieben Sie die Zeit behutsam. Dies finden Sie in der Dokumentation Ihrer bevorzugten Zeitlösung.