Сервер MongoDB не закрывается при нажатии Ctrl+C после изменения системной даты на дату в прошлом

Question

В настоящее время я использую MongoDB 3.4.4.

Я запускаю MongoDB с помощью командного файла mongo_start . Обычно я закрываю оболочку, которая появляется с помощью ctrl+c, и она работает большую часть времени. Но когда я откатываю системную дату до предыдущей (например, меняю системную дату на вчерашнюю дату), когда сервер MongoDB работает, ctrl+c перестает работать (т.е. оболочка не закрывается).

Кажется, что это было вызвано параметром --journal потому что, когда я изменил его на отсутствие журнала, я смог закрыть оболочку с помощью ctrl+c даже после того, как я изменил системную дату на предыдущую. Но после проверки того же случая на более старом сервере MongoDB (который также имеет параметр --journal ), ctrl+c закрыл оболочку после того, как я изменил системную дату на предыдущую.

Я хотел бы знать, что именно заставило оболочку не закрываться с помощью Ctrl+C после того, как я изменил системную дату на более старую. Спасибо!

Answer 1

Учитывая версию вашего сервера MongoDB 3.4.4 и текущее описание проблемы (изменение системных часов назад), я ожидаю, что обновление до MongoDB 3.4.6 или более поздней решит эту проблему. Последний производственный выпуск в этой серии в настоящее время - 3.4.19 (28 января 2019 г.), и с момента выпуска 3.4.4 (21 апреля 2017 г.) было исправлено много ошибок и улучшена стабильность .

Было несколько проблем, связанных с прыжками назад системных часов, которые могли привести к зависанию или зависанию WiredTiger во время контрольных точек (например, см. WT-3331 и WT-3327 в системе отслеживания ошибок MongoDB). Они были рассмотрены в выпуске MongoDB 3.4.6.

Это также упоминается в разделе « Синхронизация часов» производственных заметок MongoDB:

Используйте NTP для синхронизации часов на всех компонентах вашего развертывания MongoDB. Наборы реплик и сегментированные кластеры, работающие под управлением MongoDB 3.4.5 или более ранней версии с механизмом хранения WiredTiger, могут испытывать зависания контрольных точек в системах с ненадежными часами.

It seems like this was caused by the --journal parameter

Последовательность выключения включает в себя контрольную точку, чтобы сделать записи в журналах длительными в файлах данных. Если вы отключили журналирование (что настоятельно не рекомендуется для производственных сред), вместо этого вы будете запускать контрольные точки при каждой записи. Я ожидаю, что отключение журнала уменьшит вероятность того, что ваш сервер будет иметь контрольную точку, включая данные, которые были записаны до того, как часы пошли назад, хотя, возможно, вы все еще можете столкнуться с проблемами в 3.4.4, если системные часы изменяются одновременно с записью ,