Ризик запуску NTP на сервері баз даних?

Я чув чутки про погані речі, що трапляються на серверах баз даних та поштових серверах, якщо ви змінюєте системний час, поки вони працюють. Однак мені важко знайти будь-яку конкретну інформацію про фактичні ризики.

У мене є виробничий сервер 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 та перезапустити програму. Якщо ви не можете зайняти стільки простоїв у програмі, я можу лише запропонувати вам зробити резервну копію бази даних перед тим, як синхронізувати час, а потім запропонувати мертву білку на годину комп'ютерного дому та просто натиснути на курок. Гаразд, я трохи прискіпливий, але я не можу придумати жодного іншого "безпечного" способу, ніж відключення програми.

Зазвичай це не сервер бази даних, який вразливий до помилок, коли відбувається миттєвий стрибок часу: це програми, які використовують час, який є.

Зазвичай існує два способи відстеження часу: власне відстеження часу або порівняння системного часу. Обидва мають позитивні та негативні компроміси.

Відстеження власного часу

Я бачу, що це використовується у деяких вбудованих програмуваннях та системах, де точні терміни не так важливі. У головному циклі додатків береться спосіб відстеження "галочки". Це може бути сигнал тривоги, заданий ядром, режимом сну або вибору, який вказує на кількість пройденого часу. Коли ви знаєте, який час минув, ви знаєте, що можете додавати або віднімати цей час до лічильника. Цей лічильник - це те, що спричиняє вашу програму для встановлення часу. Наприклад, якщо лічильник перевищує 10 секунд, ви можете щось відкинути або потрібно щось зробити.

Якщо додаток не відстежує час, лічильник не зміниться. Це може бути бажаним залежно від дизайну вашої програми. Наприклад, відстежувати, як довго триває процес, який займається чимось, обробляється легше за допомогою лічильника, ніж список часових позначок старту / зупинки.

Про:

• Не залежить від годинника системи
• Не зламається на великому перекосі часу
• Немає дорогих системних дзвінків
• Невеликі лічильники обійдуться менше пам'яті, ніж повна часова мітка

Con:

• Час не дуже точний
• Зміна системного часу може зробити його ще більш неточним
• Час відносно запуску програми, не зберігається

Порівняння системного часу

Ця система використовується частіше: зберігайте часову марку та порівнюйте її з часовою міткою за допомогою системного дзвінка в часі. Величезні перекоси в системний час можуть загрожувати цілісності вашої програми, завдання на кілька секунд може зайняти години або закінчитися негайно залежно від напрямку годинника.

Про:

• Точне порівняння часу
• Наполягає через перезавантаження та тривалі відключення

Con:

• Здійснює системний дзвінок, щоб отримати свіжу позначку часу для порівняння з іншими часовими марками
• Додаток повинен знати про перекоси або може зламатися

Постраждалі системи

Більшість додатків використовуватимуть часові позначки порівняно із завданням розкладу. Для систем баз даних, які могли б очистити кеш.

На всі програми, які використовують базу даних та функції часу виклику на мові запитів, будуть впливати перекоси, якщо програма не виявить та не обробляє їх відповідно. Програми ніколи не можуть припиняти роботу або допускати невизначені періоди входу в залежності від їх призначення.

Поштові системи використовуватимуть часові позначки та / або тайм-аути для обробки застарілих або недоставлених листів. Нахил годинника може вплинути на це, але з набагато меншим впливом. Таймери зворотного відключення відновлення підключення до серверів можуть бути пропущені, що призведе до штрафних санкцій на підключувальному сервері.

Я не думаю (не досліджував), що тривоги ядра вимкнуться при зміні системного часу. Системи, які використовують їх, можуть бути безпечними.

Рішення

Акуратно переміщуйте час. Це можна знайти в документації улюбленого рішення часу.