39.5 GiB + 581.5 KiB = 39.5 GiB mongod --------------------------------- 39.6 GiB

Всем привет! Скажите, процесс Mongod - многонитиевый? Если посадить один mongod (как участника replica set) на 16-ядерную машину и нагрузить хорошенько запросами, мы имеем шанс увидеть высокую степень утилизации CPU?

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

там одна, это шард

Парни, правильно я понимаю, что в файле server.js строчка app.use('/api/items', items); а именно «/api/items» указывает на коллекцию «items», если речь идет о бесплатной БД от mLab ?

^ че, никто не знает? 😢

Ну допустим mongoDB Api access url

Это реально без проблем. Первоначальный коннект к БД у вас все равно идет в рантайме, просто один раз при запуске приложения

Парни, правильно я понимаю, что в файле server.js строчка app.use('/api/items', items); а именно «/api/items» указывает на коллекцию «items», если речь идет о бесплатной БД от mLab ?

Врятлт ктото ответит, и отсылаю вас к докам того самого метода use который вы используете

конечно

А какие задачи решаете с помощью транзакций?

@dd_bb а есть возможно выставить праймари через секондари?

у меня пришел ООМ

и убил праймари

а реплика не переизбрала нового

Не устанавиливается mongo :’(

Не устанавиливается mongo :’(

на сайте монги есть гайд, одной этой командой не отделаешься

на сайте монги есть гайд, одной этой командой не отделаешься

ок, спс

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

а реплика не переизбрала нового

Она одна осталась?

да там были танцы с бубнами. Остлось 3 реплики и один арбитр

но почему то монга не переизбрала нового праймари

Уберите арбитр

почему?

Потому что осталось 4 ноды

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

и приоритеты стояли

должен был избраться с приоритетом 1 а другие были с 0

и приоритеты стояли

Тогда ищите проблему тут

должен был избраться с приоритетом 1 а другие были с 0

Приоритет 0 это не выбираемая нода

хм

И она не может учавствовать в голосовании

в доках не видел об этом инфу

у арбитра 0 приоритет и один голос

в доках не видел об этом инфу

https://docs.mongodb.com/manual/core/replica-set-priority-0-member/

а как арбитр с 0 приоритетом голосует?

и у нас вот так вот

одна нода была с приоритетом 1

и он ее не выбрал

Вы неверно настроили приоритет

У вас скорее всего сейчас нет кворума для выборов

а можно заселектить сколько голосов у ноды?

Если вы хотели дать каким-то нодам больше веса, чтоб увеличить их шанс на победу в выборах, вам было необходимо дать им больший приоритет. 0 приоритет лишает ноду возможности учавствовать в выборах в любой роли, но позволяет использовать её для запросов.

а можно заселектить сколько голосов у ноды?

Зачем?

Если вы хотели дать каким-то нодам больше веса, чтоб увеличить их шанс на победу в выборах, вам было необходимо дать им больший приоритет. 0 приоритет лишает ноду возможности учавствовать в выборах в любой роли, но позволяет использовать её для запросов.

понял

вам необходимо исправить ошибку конфигурации кластера

Вернуть всем нодам-участникам приоритет 1, а нодам которые в приоритете выставить 2-3

выставил приоритеты 4 и 3 на нодах в основном цд и 2 на резервном

ну или так

понял буду копать туда

спасибо

Доброго дня, прошу помощи советом Делаю группировку. К каждой группе пушу целиком документы, участвующие в группировке. Как мне потом к каждому документу внутри группы лукапнуть данные из другой коллекции? db.getCollection('contacts').aggregate([ { "$group": { "_id": {"vk":"$vk"}, "data": {"$push":"$$ROOT"}, "count":{"$sum":1} } }, { "$match": { "count": {"$gt":1} } } ])

Документы contacts выглядят примерно так { "name" : "Пёрт Иванов", "email" : "petr@ya.ru", "uid" : 777, "vk" : 123456, } Лукапнуть нужно документы из коллекции deals, документы которой имеют вид { "name" : "Сделка 1", "contactId" : 777, ... }

Сам лукап у меня имеет такой вид $lookup: { from: "deals", localField: "data.uid", foreignField: "contactId", as: "deals" }

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

Надеюсь понятно обрисовал ситуацию, прошу простить за невежество в терминах - нуб :)

Надеюсь понятно обрисовал ситуацию, прошу простить за невежество в терминах - нуб :)

Можешь ещё составить вид документа, который ты ожидаешь получить, включая все поля?

На выходе хочу получить что-то типа такого [ { "_id": { "vk": 123456 }, "data": [ { "name": "Пёрт Иванов", "uid": 777, "email" : "petr@ya.ru", "vk": 123456, "deals": [ { "name" : "Сделка 1", "contactId" : 777, ... } ] }, { "name": "Пёрт Иванов", "vk": 123456, "uid": 888, "deals": [] } ], "count": 2 } ]

Переделал $lookup и поместил его перед группировкой. Заработало. Только получается, что он теперь ко всем "contacts" лукапит "deals", а уже потом группирует. Есть ли более адекватное решение? $lookup: { from: "deals", localField: "uid", foreignField: "contactId", as: "deals" }

Всем привет. У нас в коллекции с 250 миллионами документов стал очень сильно тормозить запрос .find({ _id: null }), индекс на это поле есть. В коллекции всего-лишь одна запись с _id: null

Кто-нибудь может помочь?

Стал тормозить после переезда с local nvme ssd диска в гугл клауде на persistent ssd (сетевой)

Все в огне горит)

Стал тормозить после переезда с local nvme ssd диска в гугл клауде на persistent ssd (сетевой)

это вы _очень_ зря

заменить на _id: { $type: 10 }

_id: null это $exists: false || $type: 10

это вы _очень_ зря

Локальные nvme ssd диски у гугл клауда часто сбоят, а при ошибке хоста вообще удаляются все данные

заменить на _id: { $type: 10 }

Спасибо, сейчас попробую

Локальные nvme ssd диски у гугл клауда часто сбоят, а при ошибке хоста вообще удаляются все данные

с сетевыми дисками у вас будет очень много проблем

с сетевыми дисками у вас будет очень много проблем

Например? Вроде иопсов и пропускной способности хватает

latency, пропускная полоса

если бы у вас хватало, у вас бы запрос не тормозил :)

раньше вот хватало

Да это очень странно, по графикам видно что там используется 3000 iops в пике из 15000

И 20мб из 240

Это единственный запрос, который стал тормозить после переезда

Попробовал reIndex сделать, не помогло)

Попробовал reIndex сделать, не помогло)

зачем?

зачем?

Сам не знаю)

reIndex по _id это что-то очень странное

это имеет смысл если у вас что-то очень сильно сломалось

заменить на _id: { $type: 10 }

Не помогло. Может ли лагать из-за того что включен read concern: majority и вторая реплика сейчас синкается?

¯\_(ツ)_/¯ explain({executionStats: true})

¯\_(ツ)_/¯ explain({executionStats: true})

Магия в том что на этом же сервере монги есть другая бд (в том же инстансе), в которой также такая же коллекция с такого же типа данными и индексами, и там этот запрос не лагает (выполняется за 1ms)