Похоже, что MongoDB 3.6 не настраивается автоматически на перезапуск в случае сбоя. Глядя на службу systemd, которая связана с последним пакетом .deb для Ubuntu 16.04LTS, похоже, что перезагрузки не настроены:
$ sudo systemctl cat mongod
# /lib/systemd/system/mongod.service
[Unit]
Description=High-performance, schema-free document-oriented database
After=network.target
Documentation=https://docs.mongodb.org/manual
[Service]
User=mongodb
Group=mongodb
ExecStart=/usr/bin/mongod --config /etc/mongod.conf
PIDFile=/var/run/mongodb/mongod.pid
# file size
LimitFSIZE=infinity
# cpu time
LimitCPU=infinity
# virtual memory size
LimitAS=infinity
# open files
LimitNOFILE=64000
# processes/threads
LimitNPROC=64000
# locked memory
LimitMEMLOCK=infinity
# total threads (user+kernel)
TasksMax=infinity
TasksAccounting=false
# Recommended limits for for mongod as specified in
# http://docs.mongodb.org/manual/reference/ulimit/#recommended-settings
[Install]
WantedBy=multi-user.target
Отправка SIGKILL и SIGSEGV убивает процесс, и он не перезапускается. Я не уверен, что systemd «поймал» их, а не просто перезапустил.
Итак, несколько вопросов: действительно ли это важно для такой службы высокой доступности, как база данных? Кажется, это так. Есть ли причина, по которой MongoDB не настроил это из коробки?
Неожиданное завершение работы - это определенно тот случай, когда настоятельно рекомендуется вмешательство администратора, хотя вы всегда можете изменить службу по умолчанию для своих развертываний.
Если причина mongod завершение процесса - это инвариант, который нельзя исправить без ручного вмешательства (например, нехватка места на диске или повреждение файла данных), автоматический перезапуск не поможет и потенциально может ухудшить ситуацию. В основном, mongod не должен завершаться из-за исправимых ошибок. MongoDB Архитектура исключений сервера различает фатальные ошибки для каждой операции и ошибки, фатальные для всего процесса. Фатальные ошибки процесса - это ситуации, в которых продолжение может привести к ужасным последствиям, таким как потеря данных или повреждение данных на диске. Пользователь или операционная система инициировали сигнал о завершении процесса (например, Недостаток памяти, известный как OOM Killer в Linux) также вызовет mongod выключить.
В качестве примера ошибки, упомянутой в комментариях, было построение индекса, которое привело к сбою в некоторых вторичных серверах в более старой версии MongoDB. При автоматическом перезапуске службы этот сценарий потенциально может привести к бесконечному циклу, в котором вторичный сервер может аварийно завершить работу, перезапустить, возобновить построение индекса, встретить то же условие и перезапустить ... только для возобновления обреченного построения индекса. Пока этот цикл перезапуска продолжается, прерывистая доступность вторичного сервера может повлиять на клиентов, использующих вторичные предпочтения чтения или других членов набора реплик (например, многократный поиск в восходящем журнале операций для возобновления синхронизации).
Как системный администратор, я бы предпочел просмотреть журналы MongoDB и попытаться понять, почему процесс завершился, чтобы можно было устранить основную причину. В идеале для развертывания будет достаточно Отказоустойчивость чтобы иметь возможность справиться с отсутствием участников, чтобы было время исследовать и исправить ситуацию.
В зависимости от характера проблемы и развертывания (автономный режим, набор реплик или сегментированный кластер) я также могу сделать резервную копию файлов данных перед попыткой автоматического или ручного восстановления. Например, при перезапуске после нечистого отключения mongod имеет начальную стадию восстановления, которая применяет незавершенные записи журнала и запускает проверки механизма хранения, такие как целостность файла данных в dbPath. Для автономного сервера было бы разумно сделать копию файлов с неизмененными данными перед любыми попытками восстановления / исправления. При развертывании набора реплик данные уже дублируются на другом члене набора реплик, поэтому, если стандартное восстановление не будет успешным, я бы повторно синхронизировать этого участника вместо того, чтобы пытаться отремонтировать.
Если вы используете systemd, тогда Restart=always под [Service] Раздел должен разрешить перезапуск службы после сбоя.
Если вас действительно беспокоит высокая доступность, вы должны запустить набор реплик и справиться с отказом одного или более узлов.
Лично управляя большим сегментированным развертыванием mongodb в производственной среде в течение 5 лет, я бы предпочел, чтобы экземпляры НЕ выполнялись автоматически, так как я хотел бы исследовать любые проблемы, прежде чем он вернется в ротацию в наборе реплик.
https://docs.mongodb.com/manual/core/replica-set-high-availability/