Ryzyko uruchomienia NTP na serwerze bazy danych?

Słyszałem pogłoski o złych rzeczach, które zdarzają się serwerom bazy danych i poczty, jeśli zmienisz czas systemu podczas ich działania. Mam jednak trudności ze znalezieniem konkretnych informacji na temat rzeczywistego ryzyka.

Mam produkcyjny serwer Postgres 9.3 działający na hoście Debian Wheezy, a czas jest wyłączony o 367 sekund. Czy mogę po prostu uruchomić ntpdatelub uruchomić openntp, gdy działa Postgres, czy może to powodować problemy? Jeśli tak, jaka jest bezpieczniejsza metoda korygowania czasu?

Czy istnieją inne usługi, które są bardziej wrażliwe na zmianę czasu systemowego? Może serwery pocztowe (exim, sendmail itp.) Lub kolejki wiadomości (activemq, rabbitmq, zeromq itp.)?

Bazy danych nie lubią cofania się w czasie, więc nie chcesz zaczynać od domyślnego zachowania przeskakiwania czasu. Dodanie -xopcji do wiersza poleceń spowoduje zmniejszenie czasu, jeśli przesunięcie jest mniejsze niż 600 sekund (10 minut). Przy maksymalnym tempie zabijania regulacja zegara zajmuje minutę. Jest to wolny, ale bezpieczny sposób na dostosowanie czasu.

Przed uruchomieniem w ntpcelu dostosowania czasu możesz zacząć ntpod opcji, takiej jak -g 2sprawdzenie, jak duże jest wykrywane przesunięcie. Spowoduje to ustawienie przesunięcia paniki na 2 sekundy, co powinno być względnie bezpieczne.

Alternatywną opcją, której użyłem, zanim ta opcja była dostępna, było napisanie pętli, która co minutę resetuje zegar z powrotem o sekundę. Jeśli sprawdzisz, czy reset nie zmieni się od razu, jest to prawdopodobnie bezpieczne. Jeśli często używasz znaczników czasu, być może masz rekordy spoza sekwencji.

Częstą opcją jest zamykanie serwera na tyle długo, aby zegar nie był cofany. ntplub ntpdatemoże zostać skonfigurowany tak, aby przy starcie przeskakiwał zegar na właściwy czas. Należy to zrobić przed uruchomieniem bazy danych.

Bazy danych mogą być szczególnie podatne na zmiany czasu systemowego, jeśli są bardzo aktywne i mają znaczniki czasu na wewnętrznych rekordach. Ogólnie rzecz biorąc, jeśli opóźniasz się, będziesz mieć o wiele mniej problemów, jeśli nagle skoczysz do przodu, niż jeśli skoczysz do przodu i nagle skoczysz do tyłu.

Jak podkreśla Joffrey - znacznie częściej aplikacja ma problemy z nagłymi skokami czasu niż sama baza danych. Najbezpieczniejszym sposobem na skorygowanie czasu jest zamknięcie aplikacji na N + 1 minut (gdzie N jest liczbą minut, którą zegar systemowy wyprzedza), a następnie zsynchronizowanie czasu, uruchomienie NTP i ponowne uruchomienie aplikacji. Jeśli nie możesz poświęcić tak dużo przestojów w aplikacji, mogę tylko zasugerować wykonanie kopii zapasowej bazy danych przed zsynchronizowaniem czasu, a następnie zaoferować martwą wiewiórkę do komputera i po prostu pociągnąć za spust. Ok, jestem trochę żartobliwy, ale nie mogę wymyślić innego „bezpiecznego” sposobu niż wyłączenie aplikacji.

Zwykle nie jest to serwer bazy danych, który jest podatny na błędy, gdy nastąpi natychmiastowy upływ czasu: są to aplikacje, które wykorzystują ten czas.

Istnieją dwa sposoby śledzenia czasu: śledzenie własnego czasu lub porównywanie czasu systemowego. Oba mają pewne pozytywne i negatywne kompromisy.

Własne śledzenie czasu

Widzę to stosowane w niektórych programach wbudowanych i systemach, w których dokładne taktowanie nie jest tak ważne. W głównej pętli aplikacji obsługiwany jest sposób śledzenia „tyknięcia”. Może to być alarm wysyłany przez jądro, tryb uśpienia lub wybór, który wskazuje, ile czasu minęło. Kiedy wiesz, która godzina minęła, wiesz, że możesz dodać lub odjąć ten czas do licznika. Ten licznik sprawia, że ​​twoja aplikacja pomiaru czasu się wydarza. Na przykład, jeśli licznik jest dłuższy niż 10 sekund, możesz coś odrzucić lub musisz coś zrobić.

Jeśli aplikacja nie śledzi czasu, licznik się nie zmieni. Może to być pożądane w zależności od projektu aplikacji. Na przykład śledzenie, jak długo trwa proces długotrwały, jest łatwiejsze dzięki licznikowi niż liście znaczników czasowych start / stop.

Zawodowiec:

• Nie zależy od zegara systemowego
• Nie złamie się przy dużym przekrzywieniu
• Brak kosztownego połączenia z systemem
• Małe liczniki będą kosztować mniej pamięci niż pełny znacznik czasu

Kon:

• Czas nie jest bardzo dokładny
• Zmiana czasu systemowego może uczynić go jeszcze bardziej niedokładnym
• Czas zależy od uruchomienia aplikacji, nie utrzymuje się

Porównywanie czasu systemowego

Jest to system używany częściej: przechowuj znacznik czasu i porównuj go ze znacznikiem czasu za pomocą systemowego wywołania czasowego. Ogromne przekrzywienia w czasie systemowym mogą zagrozić integralności aplikacji, zadanie kilku sekund może zająć godziny lub zakończyć się natychmiast, w zależności od kierunku zegara.

Zawodowiec:

• Dokładne porównanie czasu
• Utrzymuje się w stosunku do restartów i długich przerw w pracy

Kon:

• Wykonuje wywołanie systemowe, aby uzyskać nowy znacznik czasu w celu porównania z innymi znacznikami czasu
• Aplikacja musi być świadoma wypaczeń lub może się zepsuć

Dotknięte systemy

Większość aplikacji korzysta ze znaczników czasu w porównaniu do planowania zadań. W przypadku systemów baz danych, które mogą być porządkami pamięci podręcznej.

Wszystkie aplikacje korzystające z bazy danych i funkcji czasu wywołania w języku zapytań będą miały wpływ na przesunięcia, jeśli aplikacja nie wykryje odpowiednio i nie obsługuje. Aplikacje nigdy nie mogą przestać działać ani dopuszczać nieokreślonych okresów logowania w zależności od celu.

Systemy pocztowe będą używać znaczników czasu i / lub limitów czasu do obsługi starych lub niedostarczonych wiadomości e-mail. Odchylenie zegara może na to wpłynąć, ale przy znacznie mniejszym wpływie. Liczniki czasu wycofania dotyczące ponownego połączenia z serwerami mogą zostać pominięte, co może skutkować karami na łączącym się serwerze.

Nie sądzę (nie badałem), że alarmy jądra będą się włączać przy zmianie czasu systemowego. Systemy, które z nich korzystają, mogą być bezpieczne.

Rozwiązania

Delikatnie przesuwaj czas. Można to znaleźć w dokumentacji swojego ulubionego rozwiązania czasowego.