Но больше похоже на битый файл

Вряд ли эта информация ему поможет =)

Однако не питай иллюзий, монга великолепно крашится и на брэндовых дистрибах

Угу. У меня тоже крашилась когда я просто добавлял индекс

https://jira.mongodb.org/browse/SERVER-22377

В качестве средства уровня "электрошока" я бы запустил mongod через strace -e open и поискал бы что там за дескриптор 4 - открывался ли он, была ли попытка открыть. Если удастся выцепить путь к файлу... посмотреть что за файл. Как безумный вариант - удалить и попробовать запустить снова. Но это всё реанимация - может поможет, может добьет =(

судя по ответу монговцев - типа, ошибка открытия файла, файла нет, мынеприделах =\

Я подозреваю, что вот те ваши махинации с rsync не прошли даром. Как минимум в монге2 был кривоватый инитскрипт, у нас нагруженная до конца база не останавливалась по stop и в результате создавался (кривой) бэкап по ненормально остановленному серверу. Если ваши рсинки были сделаны подобным образом, вполне можно было получить битую структуру данных, на которую вот и нарвались при репликации всей БД.

Еще один вариант - запуститься с repair , но на дисках должно быть место под копию БД и... 700гб. Я не готов сказать сколько займет времени.

восстановил

нужно понять почему упала

Как восстановил?

через репейр

I STORAGE [initandlisten] WARNING: the collection 'cars_logs_new_files_20160418.fs.chunks' lacks a unique index on _id. This index is needed for replication to function properly 2016-05-05T10:47:58.304+0300 I STORAGE [initandlisten] To fix this, you need to create a unique index on _id. See http://dochub.mongodb.org/core/build-replica-set-indexes

чейчас на слейве при старте выдает

У меня было

Если индекс есть то поможет рестарт

я смотрю сейчас синк идет

Перестанет так ругаться

потому что данные просто чудовещные идут

походу вчерашни 200гб докачивает

на мастере "stateStr" : "STARTUP2",

потеря индекса на _id это круто. :( Имхо, вам стоит подумать о переезде на другое железо и более production ready OS..

потеря индекса на _id это круто. :( Имхо, вам стоит подумать о переезде на другое железо и более production ready OS..

ну вот, теперь и ты занимаешься gentoo shaming

мастер прокачал 92 гб и опять упал

куда смотреть подскажите

как тебе это удаётся?

так снова repair, если помогает

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

но я не могу понять почему падает

но я не могу понять почему падает

а в логе что?

тоже что и было в первый раз

но я не могу понять почему падает

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

ну кто тож знает

где гарантия что она опять не ляжет даже когда засинхронитсья

да никто не знает. ругается она на файл, который по её мнению был да всплыл. Чтобы попытаться понять что за файл вообще она ищет, я писал, попробуйте запустить mongod через strace , т.е # strace -e open .../mongod ...опции...

когда упадет, возможно, будет видно какой файл была попытка открыть или хотя бы что это за дескриптор был

спасибо попробую

Коллеги, ищем докладчиков по Mongo на http://devconf.ru/ru/offers

Коллеги, ищем докладчиков по Mongo на http://devconf.ru/ru/offers

Оно прилеплено всё ещё:)

Как там дела у James?

Мы вот сегодня сделали первый шаг по переходу с 2-ки на 3.2. Поскольку сразу на 3.2 нельзя, надо сначала на 3.0, а с нее уже прыгать на 3.2. Вооот. Делали всё по доке. Обновили обе ноды в репликасете, но бд оставили в старом формате. Потом на слейве переключили на WT. Реплика пересоздалась, вроде всё ок. Сделали её мастером - и началось! Все запросы на запись в бд завершались ошибкой без каких-либо вменяемых описаний - Error update и всё тут. Вернули мастером ноду с базой в старом формате. Повторили переключение еще раз - со второго раза вроде завелось... Ох. Игра с огнем эта монгадб.

Ну, wt - хороший движок ;) но отдельно от монги :)

Внутри ВАЗ 2108 тоже неплохой движок. Но отдельно от ВАЗ 2108 =) А толку,

Я использовал wt отдельно от монги :)

Но потом забил

А может кто знает, зачем монга (3, 3.2) при создании реплики "с нуля" на secondary ноде дважды перестраивает индексы? Т.е мы наблюдаем такое: убиваем данные на secondary, начинается sync init. После этого - запускается создание индексов. После этого опять sync init , но уже быстрый, данных для синка нет, и снова - пересоздает индексы! o_0 Повторение мать учения, чтоли?

Может для теста, что вторая попытка совпала с первой... А сколько реплик?

2

ну, в смысле, всего 2 сервера в сете

+арбитр, конеч

привет

count очень медленный что делать?

db.media.explain().find({ok: true, is_private: false, created_year:{$in: [2000, 2001, 2002]}}).sort({ index: 1, min_created_date: 1 }).count()

{ "stage" : "IXSCAN", "keyPattern" : { "is_private" : -1, "ok" : 1, "index" : 1, "min_created_date" : 1, "created_year" : 1 } }

но почему выполняется 68508ms

что я делаю не так?

как жить?

Каунт медленный везде

да знаю

но что делать?

Сделай условие по created date чтобы было сравнение и сортировку сначала по нему

сори но я не понял

а зачем sort в count?

а зачем sort в count?

Чтобы правильно траверсилось

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

Да, кстати, можно попробовать его убрать

да

я сам не заметил

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

ну а размер БД, индексов и сколько памяти на сервере?

Serge почему-то не спросил про версию =)

3.2 запущена на моем mbp retina i5 с 8гб > db.stats() { "db" : "picryl", "collections" : 23, "objects" : 4934972, "avgObjSize" : 2385.8588638395518, "dataSize" : 11774146689, "storageSize" : 5409226752, "numExtents" : 0, "indexes" : 128, "indexSize" : 2304520192, "ok" : 1 }

> db.media.stats() { "ns" : "picryl.media", "count" : 2793589, "size" : 6722435508, "avgObjSize" : 2406, "storageSize" : 3025006592, "capped" : false, }

ну а размер БД, индексов и сколько памяти на сервере?

если вас интересует размер памяти и индексов значит эта проблема с индексами решаема?

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

минута на этот запрос - это много

Ну, значит делай индекс по году и меньше больше

я не знаю точно в чем проблема. Возможно, индексы вытеснены из памяти и монга шуршит диском. Какая ОС? Что-то еще тяжелое запущено?

Ну, значит делай индекс по году и меньше больше

раньше была такая выборка { ok: true, is_private: false, max_created_date: { '$gte': Tue Jan 01 1895 03:00:00 GMT+0300 (MSK) }, min_created_date: { ' $lte': Sun Dec 31 1905 03:00:00 GMT+0300 (MSK) } } sort: { index: 1, min_created_date: 1 } это гораздо хуже работало

вообще я не желаю получить ответ

просто хотел убедиться что это не только у меня проблема

imho, памяти не хватает

раньше была такая выборка { ok: true, is_private: false, max_created_date: { '$gte': Tue Jan 01 1895 03:00:00 GMT+0300 (MSK) }, min_created_date: { ' $lte': Sun Dec 31 1905 03:00:00 GMT+0300 (MSK) } } sort: { index: 1, min_created_date: 1 } это гораздо хуже работало

а тебе что надо? чтобы попадало в диапазон по двум полям попадало?

просто хотел убедиться что это не только у меня проблема

не, ну count - всегда долго, потому что, если не по индексу, то fullscan

вообще, если добиться index only запроса, то должно быть сильно быстрее count делать

у медия нет точной даты создания - есть диапазон он хранится как 2 поля min и max и мне нужно выбрать например медиа в диапазоне с 1900 по 1915

я понял, да

значит так, я такую задачу решал;)

так запрос в индекс бьет же

IXSCAN

трахался, чтобы попасть в индекс, очень долго

IXSCAN

не должно быть так долго тогда, ну только если индекс в памяь не влез, конечно...