Upsert
+1
+1
Гришу слушай
)
ок, тогда задам несколько более сложный вопрос по монге(а точнее про хранение данных в ней)
вообщем, есть у меня задача, где по timestamp надо находить некий набор данных.
проблема в том, что этих таймстемпов у меня дохера.
если быть точнее, то 200*86400*20
сейчас у меня в одном документе собрано 60 таймстемпов(да, это минута)
а документ выглядит как-то так:

https://dpaste.de/TMSf
Сертификат
А вообще, это называется бакетинг и ему нужен какой то группирующий ключ
а монге с wiredtiger нельзя сказать что бы где нить в другом месте хранила индексы ?
или это совсем глупость ?
а зачем?
какая цель?
индекс, если он не в памяти в принципе не особо полезен
логично да
ну, например, всё равно приятнее читать индекс с SSD, чем с механики
и писать
кстати тоже
ну вот читать уже поздно, если он не в памяти, а для писать ssd cache перед hdd
ну и писать индекс обычно дешевле, чем сам документ
ну вот у меня ка краз тайкой кейс.
и вот думаю куда еще присобачить ssd
а индекс без документа - это как улыбка без кота
Почему поздно? Замедление - да, но вполне работоспособно
ну он читается все равно страницами, все равно медленно один раз
Кэш перед HDD - это прекрасно, только вот когда индексы вперемешку с данными, то кэшиться будет всё
а не только индексы
а если у тебя случайный доступ к индексу, то ты все равно будешь сильно медленнее памяти и проблемы с io
Кэш перед HDD - это прекрасно, только вот когда индексы вперемешку с данными, то кэшиться будет всё
надо его только для записи использовать, а чтение - это так, повезло
у тебя монга все равно держит горячую часть индекса в памяти
иначе он не нужен, опять же
Не горячую часть, монга вообще читает только из замапленного фрагмента
уууу....
мапит она всё, так-то
Да
а вот что в памяти - это решает ось
вы щас точно про wiredtiger
Если происходит чтение замапленного участка - он подтягивается в память
полюбому
и если индекс часто догружается в физическую память, т.е. нет всегда горячей части, то всё плохо внезависимости от ssd
всё плохо - это не технический термин =)
с SSD оно менее плохо
вы щас точно про wiredtiger
а у него как-то хитрее всё? ну не mmap он использует, какая разница? чудес не бывает;)
с SSD оно менее плохо
сравнимо с HDD, а не с памятью
чудес не бывает. но алгоритмика бывает решает ни хуже чуда
Почему поздно? Замедление - да, но вполне работоспособно
Bcache :)
эх.
опять это слово. :)
сравнимо с HDD, а не с памятью
С чего бы вдруг? У тебя ssd дает 60-90k iops, а диск - в лучшем случае пару сотен
Обычно - соточку
я праивльно опнимаю что они предлагаю заменить монгу своим лджвидком ?
Коллеги - ищу докладчиков по Mongo на DevConf 2016 http://devconf.ru/ru/offers/ - может кого посоветуете?
я праивльно опнимаю что они предлагаю заменить монгу своим лджвидком ?
Типа того
Коллеги - ищу докладчиков по Mongo на DevConf 2016 http://devconf.ru/ru/offers/ - может кого посоветуете?
Мне третий доклад подать? Я могу:)
Спасибо Сергей..
Типа того
ну тоесть это уже не совсем монга да ?
ага
а монге с wiredtiger нельзя сказать что бы где нить в другом месте хранила индексы ?
спасибо.
и если каталог с индексами снести, то монга упадёт.
правда, если запустить с —repair - оно индексы восстановит :)
да процедура миграции так себе получилась
зато время старта очень радует
а какие у вас размеры данных и почему так важно время старта (сколько ж было, что оно заметно??) ?
если не секрет =)
вообще плевые.
648 метров индекс
А. Ну это копейки, да.
ну вообще mongo не хотела стартовать с добавленными
  wiredTiger:
engineConfig:
directoryForIndexes: true
ну и время старта так-то должно быть редко нужно
пришлось через dump/restore
согласен
тем неменее это первое что бросилось в глаза
ожидаемо, что dump/restore нужен
ну может —repair бы помог
типа "ой, я потерял индексы, которые там лежали";)
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
это при старте
У нас давеча монга сама про... потеряла индексы. Причем, она потеряла в том числе и сами описания индексов. А эти описания были даже ценнее, чем сами данные, т.к состояли из несколко десятков полей с различными направлениями сортировки... в общем, сцука. =)
как спасли ?
А никак. Восстанавливали по коду, руками. Ну несколько команд создания индексов нашли в history консоли. Теперь настроили бэкап метаданных... Сама БД не бекапится, т.к все данные горячие. Важна была только "схема", как бы смешно это не звучало для schemeless db :)
Да, кстати, это всё было в реплике. Нифига не помогло.
какая версия/бэкенд?
$ /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 ) . В этом случае, конечно, особых претензий предъявлять не корректно
$ /opt/mongo/bin/mongod —version db version v2.6.5 2016-04-29T19:24:36.181+0300 git version: e99d4fcb4279c0279796f237aa92fe3b64560bf6
бугага
2.6.5 !!!
бугага
centos же
я в 1.8 и базу продолбил всю один раз и не восстановил
в ubuntu 16.04 и сейчас по дефолту 2.6
кого это волнует?
кто вообще в своем уме ставит из дистра монгу?
Ну понимаете. Если она работает и есть не просит, то у нас хватает других дел, чем гнаться за самой-самой последней версией. Да, и у нас установка не из репозов была.
И вообще, пинять на то, что все проблемы из-за старой версии - не корректно. Это релизная для своего времени стабильная версия, она должна работать.
Или, например, расскажите тогда нам, как переносят базы, когда индексы с данными тянут в сумме под 800гб, данные постоянно меняются и базой почти постоянно работают под пару сотен коннектов. Да, она у нас на 2. Если задача плавного переезда 2 -> 3 в такой ситуации для вас лёгкий орешек - я завидую :)
Ну, аккуратно жили с бэкапами. До 3.0 монга была так, beta. Но при наличии 3.0 и возможности легко ее поставить. Жить на 2.6 в принципе смысла не имеет.
Ну и к тому же, никто не будет ничего фиксить, пока на поддерживаемой версии не воспроизведется.
Что это?
Господа, вижу в 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
какие советы будут
я подумываю о разрыве реплики и поторном копировании базы
и ещё момент
мастер останавливать не вкоме случае нельзя
тоесть при копировании я скопирую лок файл
не может ли эта байда быть из за него?
Попробуйте убрать файлы 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 - это бывший праймари.
Как получится - отпишитесь пожалуйста
переместил файлы и рестартонул
и как оно
,
?
рестартонулась
уже не плохо =)