Покажите пример запроса на обновление. У вас ведь $set используется? Если так, то можно отправлять только перечень изменнённых полей. Вообще, можно же проверить на стенде.

нет, не использутся никаких $, просто findOneAndUpdate({key:queriedKey}, {fullUpdatedObject})

подскажите, по дефолту findOneAndUpdate , если ему передать не весь новый объект, а только небольшую его часть, только замененные поля, то он не удалит старые поля, если на них не пришёл апдейт? Сейчас я просто передаю ему обновленный экземпляр документа целиком, И работает нормально, не хотелось бы сломать

Без использования $set старые поля выпилятся.

нет, не использутся никаких $, просто findOneAndUpdate({key:queriedKey}, {fullUpdatedObject})

Вообще, согласно https://docs.mongodb.com/manual/reference/method/db.collection.findOneAndUpdate/ второй агрумент - это документ, который должен содержать update operators (https://docs.mongodb.com/manual/reference/operator/update/)

Вообще, согласно https://docs.mongodb.com/manual/reference/method/db.collection.findOneAndUpdate/ второй агрумент - это документ, который должен содержать update operators (https://docs.mongodb.com/manual/reference/operator/update/)

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

а что мешает просто попробовать и для себя все разобрать?

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

Пример: db.ttt.findOneAndUpdate({"_id" : ObjectId("5b4cae20159693e01341481a")}, {$set: {"nhn" : "avd_5", "field2": "values", ...}})

Пример: db.ttt.findOneAndUpdate({"_id" : ObjectId("5b4cae20159693e01341481a")}, {$set: {"nhn" : "avd_5", "field2": "values", ...}})

>{$set: {"nhn" : "avd_5", "field2": "values", ...}} Это должно руками прописаться? я просто не знаю, объект с каким набором полей придёт.

Я бы тут делал что-то типа Object.assign({},OriginalDocument, {updatedfieldX : update}), но не предоставляется возможность

Я бы тут делал что-то типа Object.assign({},OriginalDocument, {updatedfieldX : update}), но не предоставляется возможность

Не, вы не с той стороны смотрите :) Делайте так: ставьте полученный документ как value для $set. То есть: db.ttt.findOneAndUpdate(<filter doc>, {$set: <new doc>}

Такого не знаю. Не типичный случай какой-то... Попробуйте поискать и поднять web-интефейс какой-нибудь для монги.

Не, вы не с той стороны смотрите :) Делайте так: ставьте полученный документ как value для $set. То есть: db.ttt.findOneAndUpdate(<filter doc>, {$set: <new doc>}

Спасибо, кажется что-то начинаю понимать.

Спасибо, кажется что-то начинаю понимать.

Отлично! рад помочь!

господа как лучше монгу для стейджа в кубере собирать ? нашел хелм чарт но он делает полную фигню и в мемберы пихает ip вместо имен.

дальше выглядит будто надо руками

про http://k8smongodb.net/ знаю но ответа не нашёл.

дальше выглядит будто надо руками

Увы, руками.

рукми я сделал. но это чот жопа :)

Шедулеры контейнеров не учитывают внутреннее состояние сервисов и творят ужасные вещи

Тебе что надо?

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

может быть совета или слов типа "болт забей на хельм чарт иди и собирай инит контейнер"

Добрый день, занимаюсь индексацией и не совсем понимаю куда добавить её в коде сервера. Может есть у кого какие советы? Знаю, что можно в compass добавить, но вдруг придётся менять сервер бд и всё полетит, по этому хочется в коде Если у кого есть какие идеи - поделитесь

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

Какую проблему ты решаешь автоматизацией?

Какую проблему ты решаешь автоматизацией?

инсталл приложения на неизвестной инфраструктуре с поднятым кубером

в идеале хочу ворклоу в стиле helm inspect blablba vim valiues.yml helm install blabla

инсталл приложения на неизвестной инфраструктуре с поднятым кубером

А откуда берётся «неизвестность» инфраструктуры, если это стейжжинг?

А откуда берётся «неизвестность» инфраструктуры, если это стейжжинг?

на продуктовой среде стартовать сервисы типа монги в контейнере глупость несустветная. но в режиме поиграть или подевелопить это самое оно

Для поиграть mlaunch есть

Который может тебе развернуть кластер из десяти шардов за две минуты в одну команду :)

хм. не то.

монга не самоцель а кусочек инфры

в иделе надо по ссылке на дев задачку.

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

Добрый день, занимаюсь индексацией и не совсем понимаю куда добавить её в коде сервера. Может есть у кого какие советы? Знаю, что можно в compass добавить, но вдруг придётся менять сервер бд и всё полетит, по этому хочется в коде Если у кого есть какие идеи - поделитесь

Совсем не понятна ваша проблема. Индексацией чего? П&чем тут компас и каким образом тут другая база данных

в иделе надо по ссылке на дев задачку.

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

ясно спасибо за мнение.

Я пару лет назад полгода пытался в ранчере это сделать.

Это ОЧЕНЬ СЛОЖНО. Не меньше пары человеколет

пока мне кажется что дя задачи будет достаточно инит контейнера.

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

и данные можно дропнуть

Зачем нужно каждый раз катать реплику?

что бы похоже было.

Это требование стоит сотни тысяч долларов :)

Её можно поднять и не катать

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

А базы дропать это вопрос часа работы

Сделать три кластера: stand, repset, 3x shard. И пусть разрабы в них развлекаются.

не. зачем. ci сам справится с поднятием и убиением.

Не справится

Под какой запрос вы хотите их индексировать?

не. зачем. ci сам справится с поднятием и убиением.

Если коротко, то автоматический FT, в частности выборы, делают систему недетерминированной для внешнего наблюдателя.

чой то ? для выборов есть подкалдка в виде priority

А чем тебе приоритет поможет?

хельмовый чарт сейчас поднимает куберовский стейтфул сет. для машины с именем mongodb-primary-0 при инициализации репликасета выставляется 5-ка. для слейвов 2-ка. детерминированность выборов обеспечена. imho

Ну запуль тогда пуллреквест в хельму

Если айпишники это твоя единственная с ней проблема :)

Но я бы ее стал тратить нервы, время и бабки на эту затею. Готовы кластер тупо дешевле и надёжнее. Плюс всегда можно по результатам билда/тестирования посмотреть что в базе. Отлаживать проще.

пока единственная да

парни с канала пр кубер говорят что в стейтфулсете ойпишники неизменны

Ну тогда в чём проблема вообще?

в том что чарт не работает как надо и требует ручной иниципализации :)

ERROR: S client not available

но я уже понял что тут я не получу нужный ответ и отстал да :)

А причём тут монга?

ну а вдруг тут есть люди с похожим кейсом..

У вас уже итак в запросе есть точное совпадение по _id, индекс по второму полю ничего не даст

У вас уже итак в запросе есть точное совпадение по _id, индекс по второму полю ничего не даст

Согласен, но для будущего (если я правильно понял ментора) эта индексация ускорит скорость запроса при большом количестве данных

Не ускорит

Не ускорит

Так или иначе не моя прихоть) Если есть идеи как сделать, буду рад выслушать

Сделать compound index по _id и survey.user._id. https://docs.mongodb.com/manual/core/index-compound/#create-a-compound-index Потом сменить ментора. Этот индекс не будет использоваться, потому что у вас уже есть точный идентификатор документа: _id. Быстрее уже просто невозможно. Плюс предварительная оптимизации — неэффтивна. Вы никогда не угадаете где у вас будет бутылочное горлышко.

Сделать compound index по _id и survey.user._id. https://docs.mongodb.com/manual/core/index-compound/#create-a-compound-index Потом сменить ментора. Этот индекс не будет использоваться, потому что у вас уже есть точный идентификатор документа: _id. Быстрее уже просто невозможно. Плюс предварительная оптимизации — неэффтивна. Вы никогда не угадаете где у вас будет бутылочное горлышко.

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

Сделать compound index по _id и survey.user._id. https://docs.mongodb.com/manual/core/index-compound/#create-a-compound-index Потом сменить ментора. Этот индекс не будет использоваться, потому что у вас уже есть точный идентификатор документа: _id. Быстрее уже просто невозможно. Плюс предварительная оптимизации — неэффтивна. Вы никогда не угадаете где у вас будет бутылочное горлышко.

Получается так, что он не даёт мне обратиться к внутренней схеме, мол не понимает синтаксис

Вам в группу по JavaScript

Вам в группу по JavaScript

Хорошо, спрошу там Спасибо за помощь

Вам в группу по JavaScript

Если интересно на досуге подумать,то: Получается так, что когда я делаю compound index по _id и answers.user._id Какие бы я запросы не делал, он всё время кидает на индексирование по _id Со всем остальным работает на ура В чём проблема _id?

Вам в группу по JavaScript

И вообще, делая любой compound index по, например, 2ум полям, где одно _id - он всегда кидает индексирование на UNIQUE _id

Compound index c префиксом по _id никогда не будет иметь смысла

_id это уже _уникальный_ индектификатор документа

Если в запросе есть точное совпадение по _id, базе данных остаётся только отдать вам документ.

Т.е. это запрос со 100% селективностью

Привет! Репликация master-slave, вырубаю мастер ноду, slave не становится primary. Что не так с конфигом? Как-то у меня всегда это без орбитра работало { "_id" : "db-mongo", "version" : 3, "protocolVersion" : NumberLong(1), "members" : [ { "_id" : 0, "host" : "192.168.0.1:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 2.0, "tags" : {}, "slaveDelay" : NumberLong(0), "votes" : 1 }, { "_id" : 1, "host" : "192.168.0.2:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1.0, "tags" : {}, "slaveDelay" : NumberLong(0), "votes" : 1 } ], "settings" : { "chainingAllowed" : true, "heartbeatIntervalMillis" : 2000, "heartbeatTimeoutSecs" : 10, "electionTimeoutMillis" : 10000, "catchUpTimeoutMillis" : 60000, "getLastErrorModes" : {}, "getLastErrorDefaults" : { "w" : 1, "wtimeout" : 0 }, "replicaSetId" : ...) } }

Привет! Репликация master-slave, вырубаю мастер ноду, slave не становится primary. Что не так с конфигом? Как-то у меня всегда это без орбитра работало { "_id" : "db-mongo", "version" : 3, "protocolVersion" : NumberLong(1), "members" : [ { "_id" : 0, "host" : "192.168.0.1:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 2.0, "tags" : {}, "slaveDelay" : NumberLong(0), "votes" : 1 }, { "_id" : 1, "host" : "192.168.0.2:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1.0, "tags" : {}, "slaveDelay" : NumberLong(0), "votes" : 1 } ], "settings" : { "chainingAllowed" : true, "heartbeatIntervalMillis" : 2000, "heartbeatTimeoutSecs" : 10, "electionTimeoutMillis" : 10000, "catchUpTimeoutMillis" : 60000, "getLastErrorModes" : {}, "getLastErrorDefaults" : { "w" : 1, "wtimeout" : 0 }, "replicaSetId" : ...) } }

Так три ноды нужно. В логах наверняка об этом написано.

Так три ноды нужно. В логах наверняка об этом написано.

Т.е. конфиг правильный, но есть конфликт. Вообще, часто использую репликацию из двух нод на неважных системах

Обычно работало

ну, это же даже логически не может работать

Обычно работало

А что в логах-то?

если умерла нода 1, то как нода 2 поймет, что умерла имено нода 1, а не она сама?

нужен минимум третий

Логически я понимаю, что три нужно. Но говорю о практике, где две ноды переключаются в случае чего) я же не придумал)))

Логи гляну сейчас

просто первая отваливалась на короткое время

когда подключалась снова мастером становилась вторая