$ /opt/mongo/bin/mongod —version db version v2.6.5 2016-04-29T19:24:36.181+0300 git version: e99d4fcb4279c0279796f237aa92fe3b64560bf6

2016-04-29T18:57:20.697+0300 I STORAGE [initandlisten] exception in initAndListen: 72 Requested option conflicts with current storage engine option for directoryForIndexes; you requested true but the current server storage is already set to false and cannot be changed, terminating 2016-04-29T18:57:20.697+0300 I CONTROL [initandlisten] dbexit: rc: 100

потому что ты должен всё грохнуть, включить опцию и потом уже запускать

да я так и сделал

CentOS release 6.7 (Final)

Хотя, надо признать, что база посыпалась из-за проблем с дисковой подсистемой на текущем мастере (гребаный адаптек :E ) . В этом случае, конечно, особых претензий предъявлять не корректно

centos же

в ubuntu 16.04 и сейчас по дефолту 2.6

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

И вообще, пинять на то, что все проблемы из-за старой версии - не корректно. Это релизная для своего времени стабильная версия, она должна работать.

Или, например, расскажите тогда нам, как переносят базы, когда индексы с данными тянут в сумме под 800гб, данные постоянно меняются и базой почти постоянно работают под пару сотен коннектов. Да, она у нас на 2. Если задача плавного переезда 2 -> 3 в такой ситуации для вас лёгкий орешек - я завидую :)

Что это?

Господа, вижу в mongostat чnо база ~200 операций в секунду занимается удалением

как бы понять коллекцию в которой происходит это ?

через вебку

ну или mongotop может поможет

Вебку?

Я как то даже не включал ее

да. а какая версия? оказывается после 3.2 её зарубили...

ищите HTTP Status Interface. В нем была таблица, где по коллекция подробно всё расписывалось. Но по идее должна быть альтернатива, надо поискать

3.2

М, тогда не подойдет

А, ну вот, вроде через команду можно всё видеть. Правда, табличка была удобнее

db.adminCommand("top")

Спасибо

то что нужно

дальше обработка напильником :)

Я случайно узнал что сегодня нерабочий день.

боль, ужас, страдание. как же так ?

Коллеги подскажите по этой байде "stateStr" : "ROLLBACK",

есть хайлоад проэкт с базой монги в 750гб

этот стейт уже больше недели. перед запуском всё было скопировано через rsync

мастер 3.0.10 слейв 3.0.1

реплика, да?

да

а покажите весь rs.status() ?

сек

mongo-master ~ # mongo MongoDB shell version: 3.0.10 connecting to: test actr:PRIMARY> rs.status() { "set" : "actr", "date" : ISODate("2016-05-04T13:45:03.798Z"), "myState" : 1, "members" : [ { "_id" : 0, "name" : "1.2.3.4:27017", "health" : 1, "state" : 1, "stateStr" : "PRIMARY", "uptime" : 1124613, "optime" : Timestamp(1462369502, 3), "optimeDate" : ISODate("2016-05-04T13:45:02Z"), "electionTime" : Timestamp(1461245375, 1), "electionDate" : ISODate("2016-04-21T13:29:35Z"), "configVersion" : 47573, "self" : true }, { "_id" : 1, "name" : "1.2.3.5:27017", "health" : 1, "state" : 9, "stateStr" : "ROLLBACK", "uptime" : 143156, "optime" : Timestamp(1461243514, 7), "optimeDate" : ISODate("2016-04-21T12:58:34Z"), "lastHeartbeat" : ISODate("2016-05-04T13:45:02.126Z"), "lastHeartbeatRecv" : ISODate("2016-05-04T13:45:03.306Z"), "pingMs" : 0, "syncingTo" : "1.2.3.4:27017", "configVersion" : 47573 }, { "_id" : 2, "name" : "1.2.3.6:27017", "health" : 1, "state" : 7, "stateStr" : "ARBITER", "uptime" : 1123842, "lastHeartbeat" : ISODate("2016-05-04T13:45:02.809Z"), "lastHeartbeatRecv" : ISODate("2016-05-04T13:45:03.146Z"), "pingMs" : 0, "configVersion" : 47573 } ], "ok" : 1 }

actr:PRIMARY> db.printReplicationInfo() configured oplog size: 51200.00352478027MB log length start to end: 2425597secs (673.78hrs) oplog first event time: Wed Apr 06 2016 15:28:25 GMT+0300 (MSK) oplog last event time: Wed May 04 2016 17:15:02 GMT+0300 (MSK) now: Wed May 04 2016 17:15:02 GMT+0300 (MSK)

этот стейт уже больше недели. перед запуском всё было скопировано через rsync

вот это вы зря. Больше недели это однозначно не нормальное время, по доке, данных для ролбека не может быть больше 300ьи

mb

https://docs.mongodb.org/manual/core/replica-set-rollbacks/

какие советы будут

я подумываю о разрыве реплики и поторном копировании базы

и ещё момент

мастер останавливать не вкоме случае нельзя

тоесть при копировании я скопирую лок файл

не может ли эта байда быть из за него?

Попробуйте убрать файлы rollback'a, они там где-то рядом с файлами бд. Только не удаляйте, а просто переместите куда нить. Но это на свой страх и риск. Но раз вы неделю потерю данных не обнаружили, вряд ли там что-то ценное, даже если оно там есть

When a rollback does occur, MongoDB writes the rollback data to BSON files in the rollback/ folder under the database’s dbPath directory.

в принципе, данные не потеряны, вы можете почитать их bsondump'ом

это про слейв речь так?

про тот, который сейчас ROLLBACK

слей

он был MASTER

ну, праймари

почему

у меня слейв в роллбэке

смысл процесса rollback почитайте по ссылке

спасибо за инфу

вот есть там папочка роллбек

и там есть файлы bson

их тупо перенести с папки?

все?

если кратко: вот работает primary, и внезапно падает. Секондари становится праймари. Бывший праймари поднимается и видит, что он упал, но какая-то часть данных не успела уйти на секондари перед его падением. И он пытается сделать роллбек, т.е досинкать те данные, которые не успели уйти с него на секондари

ну собсно это понятно

да. попробуйте =) Возможно, надо будет перезапустить роллбека

монгу?

да

ок

Поэтому я и говорю, что тот, который сейчас ROLLBACK - это бывший праймари.

Как получится - отпишитесь пожалуйста

переместил файлы и рестартонул

и как оно

,

?

рестартонулась

уже не плохо =)

жрет опаративу 96%

локально не могу подкл пишет коннектинг и все

на мастере "stateStr" : "(not reachable/healthy)",