Я слышал слухи о плохих вещах, происходящих с базами данных и почтовыми серверами, если вы меняете системное время во время их работы. Однако мне трудно найти какую-либо конкретную информацию о реальных рисках.
У меня есть производственный сервер Postgres 9.3, работающий на хосте Debian Wheezy, и время отключается на 367 секунд. Могу я просто бежать ntpdate или запустите openntp во время работы Postgres, или это может вызвать проблему? Если да, то какой метод корректировки времени более безопасен?
Есть ли другие службы, более чувствительные к изменению системного времени? Может быть, почтовые серверы (exim, sendmail и т. Д.) Или очереди сообщений (activemq, rabbitmq, zeromq и т. Д.)?
Базы данных не любят обратных шагов во времени, поэтому вы не хотите начинать с поведения по умолчанию - скачка времени. Добавление -x опция командной строки изменит время, если смещение меньше 600 секунд (10 минут). При максимальной скорости нарастания потребуется около полутора дней, чтобы настроить часы на минуту. Это медленный, но безопасный способ настроить время.
Перед запуском ntp чтобы настроить время, вы можете начать ntp с опцией вроде -g 2 чтобы проверить, насколько велико обнаруженное смещение. Это установит смещение паники на 2 секунды, что должно быть относительно безопасным.
Альтернативный вариант, который я использовал до того, как этот вариант стал доступен, состоял в том, чтобы написать цикл, который сбрасывает часы назад на часть секунды каждую минуту или около того. Если вы убедитесь, что сброс не изменится во второй раз, это, вероятно, безопасно. Если вы часто используете временные метки, у вас могут быть записи вне последовательности.
Распространенный вариант - выключить сервер на достаточно долгое время, чтобы часы не двигались назад. ntp или ntpdate можно настроить на перевод часов на правильное время при запуске. Это нужно сделать до запуска базы данных.
Базы данных могут быть особенно уязвимы к изменениям системного времени, если они очень активны и имеют временные метки во внутренних записях. В общем, если вы отстаете во времени, у вас будет гораздо меньше проблем, если вы внезапно прыгнете вперед, чем если бы вы были впереди и внезапно прыгнули назад.
Как указывает Джоффри, проблемы с внезапными скачками времени возникают в приложении гораздо чаще, чем в самой базе данных. Самый безопасный способ исправить время - закрыть приложение на N + 1 минуту (где N - количество минут, на которое ваши системные часы опережают), а затем синхронизировать время, запустить NTP и перезапустить приложение. Если вы не можете выдержать такое большое время простоя в приложении, я могу только предложить вам сделать резервную копию базы данных перед синхронизацией времени, а затем предложить мертвую белку году компьютерного мира и просто нажать на курок. Хорошо, я немного шутил, но я не могу придумать другого «безопасного» способа, кроме отключения приложения.
Обычно при мгновенном скачке времени уязвим к ошибкам не сервер базы данных: это приложения, которые используют время.
Обычно существует два способа отслеживания времени: собственное отслеживание времени или сравнение системного времени. У обоих есть некоторые положительные и отрицательные компромиссы.
Я вижу, что это используется в некоторых встроенных программах и системах, где точное время не так важно. В основном цикле приложения заботится о способе отслеживания «галочки». Это может быть аварийный сигнал, выдаваемый ядром, режим сна или select, который указывает количество прошедшего времени. Когда вы знаете, сколько времени прошло, вы знаете, что можете прибавить или вычесть это время на счетчике. Этот счетчик - то, что заставляет ваше приложение хронометража работать. Например, если счетчик больше 10 секунд, вы можете что-то сбросить, или вам нужно что-то сделать.
Если приложение не отслеживает время, счетчик не изменится. Это может быть желательно в зависимости от дизайна вашего приложения. Например, отслеживать, сколько времени занимает длительный процесс, что-то обрабатывается, проще с помощью счетчика, чем списка временных меток запуска / остановки.
Pro:
Против:
Эта система используется чаще: сохраните метку времени и сравните ее с меткой времени, используя вызов системного времени. Огромные перекосы в системном времени могут поставить под угрозу целостность вашего приложения, задача в несколько секунд может занять несколько часов или закончиться немедленно, в зависимости от направления часов.
Pro:
Против:
Большинство приложений будут использовать метку времени по сравнению с запланированными задачами. Для систем баз данных, которые могут быть очищены кешем.
Все приложения, использующие базу данных и функции времени вызова на языке запросов, будут подвержены перекосам, если приложение не обнаружит и не обработает соответствующим образом. Приложения никогда не могли перестать работать или разрешить неопределенные периоды входа в систему в зависимости от его цели.
Почтовые системы будут использовать временные метки и / или тайм-ауты для обработки устаревших или недоставленных писем. На это может повлиять перекос часов, но с гораздо меньшим воздействием. Таймеры отсрочки при повторном подключении к серверам могут быть пропущены, что приведет к штрафам на подключающемся сервере.
Я не думаю (не исследовал), что при изменении системного времени будут срабатывать аварийные сигналы ядра. Системы, которые их используют, могут быть безопасными.
Аккуратно переместите время. Это можно найти в документации к вашему любимому временному решению.