Похоже, что 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 не настроила бы это из коробки?
решение1
Неожиданное завершение работы — это, безусловно, случай, когда настоятельно рекомендуется вмешательство администратора, хотя вы всегда можете изменить службу по умолчанию для своих развертываний.
Если причиной mongodзавершения процесса является инвариант, который не может быть исправлен без ручного вмешательства (например, нехватка места на диске или повреждение файла данных), автоматический перезапуск не поможет и может потенциально ухудшить ситуацию. В общем случае mongodне следует завершать работу при исправимых ошибках. MongoDBАрхитектура исключений сервераразличает фатальные ошибки для каждой операции и те, которые фатальны для всего процесса. Фатальные ошибки процесса — это ситуации, когда продолжение может привести к ужасным последствиям, таким как потеря данных или повреждение данных на диске. Пользователь или ОС инициировали сигнал для завершения процесса (например,Недостаток памяти, он же OOM Killerв Linux) также приведет mongodк завершению работы.
Примером ошибки, упомянутой в комментариях, была сборка индекса, которая дала сбой сегментации на некоторых вторичных серверах со старой версией MongoDB. При автоматическом перезапуске службы этот сценарий потенциально может привести к бесконечному циклу, в котором вторичный сервер может выйти из строя, перезапуститься, возобновить сборку индекса, столкнуться с тем же условием и перезапуститься... только для возобновления обреченной сборки индекса. Пока этот цикл перезапуска выполняется, прерывистая доступность вторичного сервера может повлиять на клиентов, использующих вторичные настройки чтения или других членов набора реплик (например, многократно ищущих в восходящем oplog для возобновления синхронизации).
Как системный администратор я бы предпочел просмотреть журналы MongoDB и попытаться понять, почему процесс завершился, чтобы можно было устранить основную причину. В идеале развертывание будет иметь достаточноОтказоустойчивостьчтобы иметь возможность справляться с отсутствием участников, чтобы было время разобраться в ситуации и исправить ее.
В зависимости от характера проблемы и развертывания (автономный, набор реплик или сегментированный кластер) я также могу захотеть сделать резервную копию файлов данных перед попыткой любого автоматического или ручного восстановления. Например, при перезапуске после некорректного завершения работы mongodесть начальная стадия восстановления, которая применит невыполненные записи журнала и запустит проверки движка хранилища, такие как целостность файлов данных в dbPath. Для автономного сервера было бы разумно сделать копию неизмененных файлов данных перед любыми попытками восстановления/ремонта. При развертывании набора реплик данные уже дублируются на другом члене набора реплик, поэтому, если стандартное восстановление не удалось, я быповторно синхронизировать этого участникавместо того, чтобы пытаться что-либо исправить.
решение2
Если вы используете systemd, то Restart=alwaysв этом [Service]разделе следует разрешить перезапуск службы после сбоя.
решение3
Если вы действительно обеспокоены высокой доступностью, вы можете запустить набор реплик и справиться с отказом одного или нескольких узлов.
Лично управляя крупным сегментированным развертыванием MongoDB в производственной среде в течение 5 лет, я бы предпочел, чтобы экземпляры НЕ перезапускались автоматически, поскольку мне хотелось бы изучить все проблемы, прежде чем они снова будут включены в ротацию в наборе реплик.
https://docs.mongodb.com/manual/core/replica-set-high-availability/