Risiko, NTP auf dem Datenbankserver zu starten?

Ich habe Gerüchte gehört, dass auf 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 zu den tatsächlichen Risiken zu finden.

Ich habe einen Postgres 9.3-Produktionsserver, der auf einem Debian Wheezy-Host ausgeführt wird, und die Zeit ist um 367 Sekunden verschoben. Kann ich ntpdateopenntp einfach ausführen oder starten, während Postgres ausgeführt wird, oder ist dies wahrscheinlich problematisch? Wenn ja, was ist eine sicherere Methode zur Zeitkorrektur?

Gibt es andere Dienste, die empfindlicher auf eine Änderung der Systemzeit reagieren? Möglicherweise Mailserver (exim, sendmail usw.) oder Nachrichtenwarteschlangen (activemq, rabbitmq, zeromq usw.)?

Datenbanken mögen keine Rückschritte in der Zeit, daher möchten Sie nicht mit dem Standardverhalten des Zeitspringens beginnen. Durch Hinzufügen der -xOption zur Befehlszeile wird die Zeit verkürzt, wenn der Versatz weniger als 600 Sekunden (10 Minuten) beträgt. Bei maximaler Anstiegsgeschwindigkeit dauert es ungefähr anderthalb Tage, um die Uhr um eine Minute einzustellen. Dies ist eine langsame, aber sichere Methode, um die Zeit anzupassen.

Bevor ntpSie die Zeit einstellen, können Sie ntpmit einer Option beginnen -g 2, um zu überprüfen, wie groß der erkannte Versatz ist. Dadurch wird der Panikversatz auf 2 Sekunden eingestellt, was relativ sicher sein sollte.

Eine alternative Option, die ich verwendet habe, bevor diese Option verfügbar war, war das Schreiben einer Schleife, die die Uhr etwa jede Minute um einen Teil der Sekunde zurücksetzt. Wenn Sie überprüfen, ob sich der Reset in der Sekunde nicht ändert, ist dies wahrscheinlich sicher. Wenn Sie Zeitstempel häufig verwenden, haben Sie möglicherweise Datensätze, die nicht in der richtigen Reihenfolge vorliegen.

In der Regel wird der Server so lange heruntergefahren, dass die Uhr nicht rückwärts bewegt wird. ntpoder ntpdatekann so konfiguriert werden, dass die Uhr beim Start auf die richtige Zeit springt. Dies sollte erfolgen, bevor die Datenbank gestartet wird.

Datenbanken können besonders anfällig für Systemzeitänderungen sein, wenn sie sehr aktiv sind und Zeitstempel in internen Datensätzen enthalten. Wenn Sie mit der Zeit im Rückstand sind, haben Sie im Allgemeinen viel weniger Probleme, wenn Sie plötzlich vorwärts springen als wenn Sie vorwärts und plötzlich rückwärts springen.

Wie Joffrey betont, gibt es in der Anwendung viel häufiger Probleme mit plötzlichen Zeitsprüngen als in der Datenbank. Am sichersten korrigieren Sie die Uhrzeit, indem Sie die Anwendung für N + 1 Minuten herunterfahren (wobei N die Anzahl der Minuten ist, um die die Systemuhr nach vorne zeigt) und anschließend die Uhrzeit synchronisieren, NTP starten und die Anwendung neu starten. Wenn Sie nicht so viel Ausfallzeit in der Anwendung haben, kann ich Ihnen nur empfehlen, vor dem Synchronisieren der Zeit eine Sicherungskopie der Datenbank zu erstellen, dann dem Computer ein totes Eichhörnchen anzubieten und einfach den Auslöser zu betätigen. Ok, ich bin ein bisschen scherzhaft, aber ich kann mir keinen anderen "sicheren" Weg vorstellen, als den Ausfall einer Anwendung.

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

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

Eigene Zeiterfassung

Ich sehe dies in einigen eingebetteten Programmen und Systemen, in denen das genaue Timing nicht so wichtig ist. In einer Hauptanwendungsschleife wird eine Möglichkeit zum Verfolgen eines "Häkchens" besorgt. Dies kann ein Alarm sein, der vom Kernel, Sleep oder Select ausgegeben wird und einen Hinweis auf die verstrichene Zeit gibt. Wenn Sie wissen, welche Zeit vergangen ist, können Sie diese Zeit zu einem Zähler addieren oder von diesem abziehen. Dieser Zähler ist es, der Ihre Zeitsteuerungsanwendung 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 kann abhängig vom Design Ihrer Anwendung gewünscht sein. Zum Beispiel ist es mit einem Zähler einfacher zu verfolgen, wie lange ein Prozess dauert, der etwas erledigt, als mit einer Liste von Start- / Stopp-Zeitstempeln.

Profi:

• Unabhängig von der Systemuhr
• Bricht nicht auf einem großen Zeitversatz
• Kein teurer Systemaufruf
• Kleine Zähler kosten weniger Speicher als ein vollständiger Zeitstempel

Con:

• Die Zeit ist nicht sehr genau
• Eine Änderung der Systemzeit kann die Genauigkeit noch erhöhen
• Das Timing ist relativ zum Ausführen der Anwendung, bleibt aber nicht erhalten

Systemzeit vergleichen

Dies ist das am häufigsten verwendete System: Speichern Sie einen Zeitstempel und vergleichen Sie ihn mit dem Zeitstempel mithilfe eines Systemzeitaufrufs. Große Zeitverschiebungen in der Systemzeit können die Integrität Ihrer Anwendung gefährden. Je nach Richtung der Uhr kann eine Aufgabe von wenigen Sekunden Stunden dauern oder sofort enden.

Profi:

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

Con:

• Nimmt einen Systemaufruf entgegen, um einen neuen Zeitstempel zum Vergleich mit anderen Zeitstempeln abzurufen
• Die Anwendung muss auf Schräglauf achten oder kann abbrechen

Betroffene Systeme

Die meisten Anwendungen verwenden einen Zeitstempel im Vergleich zu geplanten Aufgaben. Für Datenbanksysteme, bei denen es sich um Cache-Bereinigungen handeln könnte.

Alle Anwendungen, die eine Datenbank verwenden und Zeitfunktionen in der Abfragesprache verwenden, sind von Zeitversatz betroffen, wenn sie von der Anwendung nicht erkannt und entsprechend behandelt werden. Anwendungen könnten je nach Zweck niemals aufhören zu laufen oder unbestimmte Anmeldezeiträume zulassen.

Mail-Systeme verwenden Zeitstempel und / oder Zeitüberschreitungen, um veraltete oder nicht zugestellte Mails zu verarbeiten. Ein Zeitversatz könnte das beeinflussen, aber mit einer viel geringeren Auswirkung. Back-Off-Timer für das erneute Herstellen einer Verbindung zu Servern können versäumt werden, was zu Strafen für den Server führt, der die Verbindung herstellt.

Ich glaube nicht (habe nicht recherchiert), dass Kernel-Alarme beim Ändern der Systemzeit ausgelöst werden. Systeme, die diese verwenden, könnten sicher sein.

Lösungen

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