окей, а я про -local и спрашивал

Было три среплицированных сервера. Один упал - сдох. Ключи mongo.key были с этого сервера и он был Primary. Хочу теперь чтобы второй и третий работал только между собой. Сгенерил ключи mongo.key со второго и перебросил на третий. Рестартанул. Все сделал правильно? Или еще что-нибудь надо сделать?

Или надо еще где-нибудь прописывать что второй стал Primary?

Или надо еще где-нибудь прописывать что второй стал Primary?

Версия монги какая?

version: "3.10.0-327.10.1.el7.x86_64"

Я убрал через rs.remove тот первый сервер который упал.

вроде бы все норм работает. В логе ошибок нету. Но, почему то программа не соединяется.

SocialServer failed - Reason: A JSONArray text must start with '[' at character 1 of {"error": "Unable to fetch API key"}

это в логах программы (не базы)

Я убрал через rs.remove тот первый сервер который упал.

Проверь что выбрали нового primary. Чётное количество нод может и не выбрать. (rs.status()). Второй вариант проверь что есть активные secondary (priority =! 0 и не hidden), при условии что запросы с readPreference secondary

И ищи оригинальную ошибку. Та, которую ты привёл не по монгу.

внезапно :)

Здравствуйте! Может кто сталкивался с такой задачей. Осваиваю полнотекстовый поиск в монге разобрался как это делать для конструкции типа {'ключ': 'текст'}. Но мне теперь нужно сделать для {'ключ': {'номер страницы': 'текст', и т.д.}} Основная задача хранить текст по странично из pdf. Такое вообще возможно? Гуглить пробовал.

спасибо. и индекс создавать по text я так понимаю, а не по ключ. а можно будет как результат поиска не всю запись целиком, а так что бы узнать номер страницы?

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

@dd_bb напомни пожалуйста, если не сложно, про ограничения касательно "кастомного" _id ? там было что то связано толи с размером толи с индексацией.

1024 байта.

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

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

Спс.

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

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 это такой совсем дубовый вариант

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