Frage Risiko des Startens von NTP auf dem Datenbankserver?


Ich habe Gerüchte gehört, dass bei Datenbank- und Mailservern schlimme Dinge passieren, wenn Sie die Systemzeit ändern, während sie ausgeführt werden. Es fällt mir jedoch schwer, konkrete Informationen über tatsächliche Risiken zu finden.

Ich habe einen produktiven Postgres 9.3 Server, der auf einem Debian Wheezy Host läuft und die Zeit ist um 367 Sekunden abgelaufen. Kann ich einfach laufen? ntpdate oder starten Sie openntp, während Postgres läuft, oder ist das wahrscheinlich ein Problem? Wenn ja, was ist eine sicherere Methode, um die Zeit zu korrigieren?

Gibt es andere Dienste, die empfindlicher auf eine Änderung der Systemzeit reagieren? Vielleicht Mail-Server (Exim, Sendmail, etc) oder Nachrichtenwarteschlangen (activemq, rabbitmq, zeromq, etc)?


27
2018-02-25 20:06


Ursprung




Antworten:


Datenbanken mögen keine Rückwärtsschritte, deshalb möchten Sie nicht mit dem Standardverhalten des Zeitsprungs beginnen. Hinzufügen der -x Option auf die Befehlszeile wird die Zeit schwenken, wenn der Offset weniger als 600 Sekunden (10 Minuten) ist. Bei maximaler Anstiegsgeschwindigkeit dauert es etwa anderthalb Tage, um die Uhr um eine Minute einzustellen. Dies ist eine langsame, aber sichere Möglichkeit, die Zeit anzupassen.

Vor dem Ausführen ntp um die Zeit anzupassen, möchten Sie vielleicht beginnen ntp mit einer Option wie -g 2 um zu überprüfen, wie groß ein Offset ist, den er erkennt. Dies setzt den Panik-Offset auf 2 Sekunden, was relativ sicher sein sollte.

Eine alternative Option, die ich vor dieser Option verwendet hatte, war eine Schleife zu schreiben, die jede Sekunde den Takt zurücksetzt. Wenn Sie überprüfen, ob sich der Reset in der Sekunde ändert, ist dies wahrscheinlich sicher. Wenn Sie Zeitstempel stark verwenden, haben Sie möglicherweise Datensätze außerhalb der Reihenfolge.

Eine gängige Option ist, den Server so lange herunterzufahren, dass keine Rückwärtsbewegung der Uhr stattfindet. ntp oder ntpdate kann so konfiguriert werden, dass die Uhr beim Start auf die korrekte Uhrzeit springt. Dies sollte vor dem Start der Datenbank geschehen.


23
2018-02-26 03:21





Datenbanken können besonders anfällig für Systemzeitänderungen sein, wenn sie sehr aktiv sind und Zeitstempel für interne Datensätze haben. Im Allgemeinen, wenn Sie die Zeit hinter sich haben, werden Sie viel weniger Probleme haben, wenn Sie plötzlich vorwärts springen, als wenn Sie voraus sind und plötzlich rückwärts springen.

Wie Joffrey betont - es ist viel häufiger die Anwendung, die Probleme mit plötzlichen Zeitsprüngen als die Datenbank selbst hat. Der sicherste Weg, um die Zeit zu korrigieren, ist, die Anwendung für N + 1 Minuten herunterzufahren (wobei N die Anzahl der Minuten ist, die Ihre Systemuhr voraus ist) und dann die Zeit zu synchronisieren, NTP zu starten und die Anwendung neu zu starten. Wenn Sie nicht so viele Ausfallzeiten in der Anwendung haben, kann ich nur vorschlagen, dass Sie vor dem Synchronisieren eine Sicherung der Datenbank machen, dann ein totes Eichhörnchen dem Computerdomizieren anbieten und einfach den Auslöser drücken. Ok, ich bin ein bisschen witzig, aber ich kann mir keinen anderen "sicheren" Weg vorstellen, als einen Anwendungsausfall zu machen.


8
2018-02-25 20:21



Ich bin vorne und muss ca. 6 Minuten rückwärts springen. Ich habe viele, viele interne Datensätze, die mit festgelegt wurden now(). Können Sie eine sichere Methode hinzufügen, um die Zeit für Ihre Antwort zu ändern? - vastlysuperiorman
Wenn ntpd korrekt installiert und konfiguriert ist, sollte es in der Lage sein, die Systemzeit nach und nach zu korrigieren, indem die Uhr verlangsamt wird. Sobald die korrekte Zeit erreicht ist, wird die Drift angepasst, um die Zeit zu erhalten. Möglicherweise müssen Sie eine maximale Korrektur angeben, die Ihren Fehler übersteigt. Zumindest verstehe ich das so, aber ich bin kein NTP-Experte. - Jonathan J
@ JonathanJ - NTP hat Schwierigkeiten beim Korrigieren von Zeitverschiebungen von mehr als 5 Minuten, und wenn es pro "Standard" -Dokumentation eingerichtet wird (von denen es mehrere Sätze gibt) synchronisiert zuerst die Zeit in einem Sprung und hält dann die Synchronisation durch Anpassung der Drift aufrecht. - John
@John Ich bin vor Jahren von Eichhörnchen ausgegangen;) - Joffrey


Es ist normalerweise nicht der Datenbankserver, der anfällig für Fehler ist, wenn ein sofortiger Zeitsprung auftritt: es sind die Anwendungen, die die Zeit verwenden, die sie sind.

Es gibt im Allgemeinen zwei Möglichkeiten, die Zeit zu verfolgen: eigene Zeiterfassung oder Vergleich der Systemzeit. Beide haben einige positive und negative Kompromisse.

Eigene Zeiterfassung

Ich sehe das in einigen Embedded-Programmen und -Systemen, wo genaues Timing nicht so kritisch ist. In einer Hauptanwendungsschleife wird auf eine Art und Weise der Verfolgung eines "Zeckens" geachtet. Dies könnte ein Alarm sein, der vom Kernel, sleep oder select gegeben wird und einen Hinweis auf die verstrichene Zeit gibt. Wenn Sie wissen, welche Zeit verstrichen ist, wissen Sie, dass Sie diese Zeit zu einem Zähler hinzufügen oder davon abziehen können. Dieser Zähler ist es, was Ihre Timing-Anwendung ermöglicht. Wenn der Zähler beispielsweise länger als 10 Sekunden ist, können Sie etwas verwerfen, oder Sie müssen etwas tun.

Wenn die Anwendung die Zeit nicht verfolgt, ändert sich der Zähler nicht. Dies könnte je nach Design Ihrer Anwendung gewünscht sein. Zum Beispiel ist es einfacher, mit einem Zähler zu verfolgen, wie lange ein lang andauernder Prozess dauert, als mit einer Liste von Start / Stopp-Zeitstempeln.

Profi:

  • Nicht abhängig von der Systemuhr
  • Wird nicht bei einer großen Zeitverschiebung brechen
  • Kein teurer Systemaufruf
  • Kleine Zähler benötigen weniger Speicherplatz als ein vollständiger Zeitstempel

Con:

  • Die Zeit ist nicht sehr genau
  • Änderung der Systemzeit könnte es noch ungenauer machen
  • Timing ist relativ zum Ausführen der Anwendung, wird nicht beibehalten

Systemzeit vergleichen

Dies ist das System, das häufiger verwendet wird: Speichern Sie einen Zeitstempel und vergleichen Sie ihn mit dem Zeitstempel, indem Sie einen Systemzeitaufruf verwenden. Große Schieflagen in der Systemzeit könnten die Integrität Ihrer Anwendung gefährden, eine Aufgabe von wenigen Sekunden könnte Stunden dauern oder je nach Richtung der Uhr sofort enden.

Profi:

  • Genauer Zeitvergleich
  • Bleibt bei Neustarts und langen Ausfällen bestehen

Con:

  • Ruft einen Systemaufruf auf, um einen neuen Zeitstempel zum Vergleichen mit anderen Zeitstempeln zu erhalten
  • Die Anwendung muss auf Verdrehungen achten oder kann brechen

Betroffene Systeme

Die meisten Anwendungen verwenden Zeitstempel im Vergleich zu Zeitplan-Aufgaben. Für Datenbanksysteme, die Cache-Bereinigungen sein könnten.

Alle Anwendungen, die eine Datenbank verwenden und Zeitfunktionen in der Abfragesprache aufrufen, sind von Fehlern betroffen, wenn die Anwendung dies nicht erkennt und entsprechend behandelt. Anwendungen können je nach Zweck nie aufhören zu laufen oder unbestimmte Anmeldezeiträume zulassen.

Mail-Systeme verwenden Zeitstempel und / oder Timeouts für die Behandlung von veralteten oder nicht zugestellten E-Mails. Eine Taktverschiebung könnte das beeinflussen, aber mit einer viel geringeren Auswirkung. Back-Off-Timer bezüglich der Wiederverbindung mit Servern könnten verpasst werden, was zu Strafen auf dem verbindenden Server führen würde.

Ich glaube nicht (habe nicht geforscht), dass Kernel-Alarme ausgelöst werden, wenn die Systemzeit geändert wird. Systeme, die diese verwenden, könnten sicher sein.

Lösungen

Bewegen Sie die Zeit sanft. Dies finden Sie in der Dokumentation Ihrer bevorzugten Zeitlösung.


4
2018-02-26 15:47



Dies ist eine großartige Antwort, und ich weiß es zu schätzen, mehr über Zeitmessung zu erfahren. Ich habe es nicht ausgewählt, weil es keine klare Lösung für mein gegenwärtiges Problem der Anpassung der Zeit auf meinem Produktionsdatenbankserver war. +1, um mir Dinge beizubringen. - vastlysuperiorman