Перезапуск/Авторемонт Mongodb в производстве

То, что я хочу достичь, это иметь /etc/init.d script, который более надежно запускает Mongodb, даже если он сильно опустился - он должен попытаться авторемонтировать, если система находится в заблокированном состояние.

Да, я мог бы script сам, но я думаю, что кто-то там, должно быть, уже сделал это.

Я заметил, что после того, как сервер опустился, Mongodb находится в состоянии, когда он не перезапускается через /etc/init.d/mongod script. Очевидно, файл блокировки должен быть удален, и его необходимо запустить с параметром -repair и сначала исправить -dbpath, прежде чем он сможет быть успешно перезапущен. В некоторых случаях также необходимо изменить права собственности на db файлы на пользователя, который запускает mongodb. Еще одна проблема заключается в том, что стандарт /etc/init.d/mongod script не сообщает об ошибке в этой ситуации, но довольно радостно и неправильно возвращается с статусом "ОК", сообщая, что Mongod был запущен, хотя он не был.

$ sudo /etc/init.d/mongod start
Starting mongod: forked process: 9220
all output going to: /data/mongo/log/mongod.log
                                                           [  OK  ]
$ sudo /etc/init.d/mongod status
mongod dead but subsys locked

ОС - это CentOS или Fedora.

Кто-нибудь изменил скрипты /etc/init.d или указатель на такие скрипты, которые автоматически пытаются восстановить в этой ситуации? Или есть еще один инструмент, который функционирует как сторожевая собака для Mongod

Любые мнения о том, почему может быть плохой идеей попытаться автоматически восстановить mongodb?

$ sudo /etc/init.d/mongod status
mongod dead but subsys locked

$ sudo ls -l /var/lib/mongo/mongod.lock 
-rw-r--r--. 1 mongod mongod 5 Nov 19 11:52 /var/lib/mongo/mongod.lock


$ sudo tail -50 /data/mongo/log/mongod.log
************** 
old lock file: /data/mongo/db/mongod.lock.  probably means unclean shutdown
recommend removing file and running --repair
see: http://dochub.mongodb.org/core/repair for more information
*************
Sat Nov 19 11:55:44 exception in initAndListen std::exception: old lock file, terminating
Sat Nov 19 11:55:44 dbexit: 

Sat Nov 19 11:55:44 shutdown: going to close listening sockets...
Sat Nov 19 11:55:44 shutdown: going to flush oplog...
Sat Nov 19 11:55:44 shutdown: going to close sockets...
Sat Nov 19 11:55:44 shutdown: waiting for fs preallocator...
Sat Nov 19 11:55:44 shutdown: closing all files...
Sat Nov 19 11:55:44     closeAllFiles() finished

Sat Nov 19 11:55:44 dbexit: really exiting now

Ответы

Ответ 1

Итак, первый бит, который стоит упомянуть, - это журналирование. Журналирование фактически объявляется как "быстрый ремонт". Журналирование включено по умолчанию в версии 2.0+, и он выполнит этот "ремонт" по умолчанию.

Поэтому, если ваши диски могут обрабатывать дополнительную запись в журнале, это может решить вашу проблему.

Любые мнения о том, почему может быть плохой идеей попытаться автоматически восстановить mongodb?

Проблема №1 с ремонтом MongoDB автоматически - это просто одно из времени.

Если у вас есть база данных 200 ГБ, при ремонте системе необходимо будет выполнить следующее:

  • Выделить ~ 200 ГБ файлов (у вас есть место на диске?)
  • Прочитайте все данные из существующих файлов в памяти (200GB read)
  • Проверяйте каждый документ на достоверность и записывайте его в новые файлы (200GB write)
  • Восстановить все индексы (200GB reads + large number of writes)
  • Сбросить все на диск

Если вы посмотрите на мои заметки о том, что серьезный шум, необходимый для ремонта, выполняется.

Но большинство производственных установок работают с наборами реплик. В этом случае вместо восстановления вы можете просто восстановить из резервной копии. Восстановление из резервной копии только однократно записывает данные и это процесс, который вы уже должны иметь.

Несмотря на возврат init.d script OK, ваш системный мониторинг должен сказать вам, что БД не работает.

Ответ 2

Просто хочу указать, что ведение журнала работает в 32-разрядной версии. Однако он не включен по умолчанию в 32-разрядный.