А индекс работает только для полного совпадения.

А индекс работает только для полного совпадения.

Спс.

всем привет. можете подсказать по логу почему упала монга?

http://pastebin.com/TDTbH5ns

всем привет. можете подсказать по логу почему упала монга?

по стектрейсу находится только https://jira.mongodb.org/browse/SERVER-26890

спс

а где можно подробнее почитать, как "Secondary members copy the oplog from their sync from source"? https://docs.mongodb.com/manual/core/replica-set-sync/#replication

а где можно подробнее почитать, как "Secondary members copy the oplog from their sync from source"? https://docs.mongodb.com/manual/core/replica-set-sync/#replication

что именно тебя интересует?

как это устроено, как работает никаких конкретных вопросов

только код читать?

в local есть capped коллекция rs.oplog. в неё данные пишутся только на master, все кто хочет синхронизироваться с мастером открывают в эту коллекцию tailable cursor и пишут в свою локальную всё что из курсора приезжает

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

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

в целом понятно, спасибо в чем хитрость этого механизма?

в том, чтоб получить point-in-time consistent dump

на который потом можно оплог проиграть

что я делаю не так или упускаю: делаю мапердьюс из не шардированной коллекции в шардировнную (само шардирвоание на бд включено проверено) в результате видно: { "result" : "res.sharded", "counts" : { "input" : NumberLong(20554), "emit" : NumberLong(129504), "reduce" : NumberLong(30650), "output" : NumberLong(0) }, "timeMillis" : 7778, "timing" : { "shardProcessing" : 7597, "postProcessing" : 181 }, "shardCounts" : { "rs0/mongo-mongo1-1:27018,mongo-mongo2-1:27018,mongo-mongo3-1:27018" : { "input" : 20554, "emit" : 129504, "reduce" : 30650, "output" : 42542 } }, "postProcessCounts" : { "rs0/mongo-mongo1-1:27018,mongo-mongo2-1:27018,mongo-mongo3-1:27018" : { "input" : NumberLong(0), "reduce" : NumberLong(0), "output" : NumberLong(0) } }, "ok" : 1 } собственно почему на shardCounts в output есть 42к доков, а в постпроцессинге нет?

мапредьюс с параметром: out: {merge:"res.sharded",nonAtomic:true, sharded: true}

монга 3.4.2, два шарда с репликасетами shards: { "_id" : "rs0", "host" : "rs0/mongo-mongo1-1:27018,mongo-mongo2-1:27018,mongo-mongo3-1:27018", "state" : 1 } { "_id" : "rs1", "host" : "rs1/mongo-mongo4-1:27018,mongo-mongo5-1:27018,mongo-mongo6-1:27018", "state" : 1 }

данные в коллекцию попадают?

а, вижу: "output" : NumberLong(0)

out коллекция существует? по какому ключу она шаржена?

я ее удаляю перед запуском, поэтмоу все дефолтно с _id ключем

и она создается, но пустая

а если второй раз выполнить запрос, не удаляя коллекцию?

тот же самый результат выполнения

причем не шард в не шард отрабатывает корректно

интересно. попробуй без sharded?

ага.

ты ведь на монгосе выполняешь mapreduce, да? :)

да

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

мой случай: Even if the collection is re-created or the entire database is dropped and re-created, or if a different database is used. The name of the output collection can never be used again. Only when outputting into a collection with a different name, the exact same map reduce job processing the exact same data will succeed.

а глобально причина https://jira.mongodb.org/browse/SERVER-17397

The problem emerges on sharded clusters only, and only when the output collection uses a hashed index.

т.е. ты сначала создал коллекцию руками с _id hashed?

изанчально она была создана с индексом хешеным

да

причем там даже отедьлнео поле было как индекс, потом пришлось сменить на _id

он монотонный был, по рекомендациям сделал захешенным

думал схавает

лан спасиб за наводки

всегда рады помочь ?

интересно, а в чём у m/r проблема с hashed _id

вот и я думал не будет хДД

вообще там идет этап сплита перед разливкой по шардам

а вообще, три раза подуймай, нужен ли тебе hashed индекс

и тоже самое про map/reduce. баге третий год пошел, а всем срать :)

при наличии монотонных id особо ничего ен придумаешь

завести отдельный ключ для шардинга

ты зачем шардишь-то?

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

причем если монга справится то много больше терабайта

вот надо от запросов идти

с hashed ключом ты ничего не получишь

только боль и унижение

hashed хорошо работает когда у нас _очень много_ уникально адресуемых данных

над ними еще оидн мап редьюс))) который тоже генерит всеголишь на порядок меньше инфы

и мы никогда не ищем по ключу, всегда обращаемся прямо

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

обычно в «примерно» вся жопа и кроется :)

вот уже столкнулся

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

когда надо «быстро распихать данные по кучу железок»

да есть проблема, у меня нет подходящего поля, которое было бы не монотонное

а что за данные?