« Rev
@mongodb_ru   555
Fwd »


Roman
Wat?
Nothing. Absolutely nothing.
Artem
Всем привет! Периодически отваливается монга с вот таким логом https://pastebin.com/hMHfHni7. Решается удалением файлов из /var/lib/mongodb/journal. Может, кто сталкивался и знает более "валидные" варианты решения.
Маfеt
Это спам
Max
Привет! Время от времени ловлю ошибки: MongoErrorPool.write(mongodb-core.lib.connection:pool) error pool destroyed (node.js, mongoose, Mongodb Atlass) При чём не понятно где падают и почему, подскажите плиз в какую сторону копать.
p
Всем привет! Есть коллекция документов, у которых одно из полей - массив документов. Можно как-то в Robo3T выбрать один документ из коллекции и среди его поддокументов отобразить только отфильтрованные по признаку?
p
да как в монге, ищи $elemMatch
так он мне выдаст документ у которого в поле-массиве есть документ удовлетворяющий условию. а у меня у документа в поле-массиве тясячи документов и мне по ним бы поиск запустить. надеюсь внятно объяснил...
Yurii
так он мне выдаст документ у которого в поле-массиве есть документ удовлетворяющий условию. а у меня у документа в поле-массиве тясячи документов и мне по ним бы поиск запустить. надеюсь внятно объяснил...
ну тогда обычным query не решишь, писать агрегацию, где после такого матча сделать $unwind по чему делал $elemMatch, потом второй матч и $group обратно
tsar
как сделать update поля относительно другого поля?
Artem
Всем привет! Периодически отваливается монга с вот таким логом https://pastebin.com/hMHfHni7. Решается удалением файлов из /var/lib/mongodb/journal. Может, кто сталкивался и знает более "валидные" варианты решения.
В общем нашел следующие таски: https://jira.mongodb.org/browse/SERVER-5380 и https://jira.mongodb.org/browse/SERVER-20342 - если в кратце то разрабы это и советуют (удалять журналы)
Omer
Здравствуйте! Недавно с монгой работаю и за поиском истины пришел к вам) У меня подобная проблема возникла и решения найти пока не получилось. Сама реплика живет без oplog колеекции (судя по всему) Предполагаю (поправьте, если ошибаюсь), что по этой причине не получается сделать рестор с point in time --oplogReplay Не мог бы кто подсказать решится ли эта проблема созданием оплог коллекции?
Omer
Коллеги, добрый день. Подскажите плз, такая проблема: поднят реплика сет из трех монг, и был сделан бэкап с помощью mongodump - но без флага --oplog и без указания идентификатора сета, т.е. фактически дамп с одной ноды. Можно ли его каким-то образом через mongorestore восстановить? Сейчас все попытки заканчиваются тем, что кластер через какое-то время отторгает новые данные
Omer
Артем, спасибо что ответили) это та, что лежит в коллекции local?
Artem
Артем, спасибо что ответили) это та, что лежит в коллекции local?
Если вы про oplog.rs, то да эта что в коллекции local
Omer
да, да про нее
Omer
вообще, в принципе, не могли бы подсказать какой-нибудь ресурс или статью, где пошагово рассказывается, как поднять реплику грамотно? посмотрю на этапы все и проверю, не упустил ли я чего
tsar
как в монго обновитm поле относительно другого поля?
yopp
как в монго обновитm поле относительно другого поля?
Если вы хотите использовать значение одного поля, чтоб обновить другое поле, то это пока все ещё не возможно одним запросом.
tsar
спасибо
hi
всем привет, что-то с монгой странный затык, может кто знает? пример структуры, т.е. contracts это массив обьектов, обычно в нем по одному обьекту, но может быть и больше { "data" : { "contracts" : [ { "dateSigned" : "2019-05-31T00:00:00+03:00" } ] } } { "data" : { "contracts" : [ { "dateSigned" : "2019-05-31T00:00:00+03:00" } ] } } { "data" : { "contracts" : [ { "dateSigned" : "2019-05-31T00:00:00+03:00" } ] } } { "data" : { "contracts" : [ { "dateSigned" : "2019-05-31T00:00:00+03:00" } ] } } { "data" : { "contracts" : [ { "dateSigned" : "2019-05-31T00:00:00+03:00" } ] } } есть такой индекс db.col.createIndex({'data.contracts.dateSigned':1}) вот такой запрос использует COUNT stage, все нормально (такой же запрос, но с $gte аналогично) db.col.find({"data.contracts.dateSigned":{$lte:"2019-06-01T00:01:01+03:00"}}).count() а вот такой уже делает еще FETCH зачем-то db.col.find({"data.contracts.dateSigned":{$gte:"2019-05-01T16:00:00+03:00",$lte:"2019-06-02T00:00:00+03:00"}}).count()
hi
"totalKeysExamined" : 115712, "totalDocsExamined" : 114605, такое чувство, что fetch нужно, чтобы перепроверить результаты, потому что планировщик не обладает актуально статистикой. я пересоздал индексы, но это не помогло и какого-то способа обновить статистику не нашел тоже (аналога analyze)
yopp
А, с 3.6 возможен: Changed in version 3.6: An index can cover a query on fields within embedded documents.
yopp
Покажите explain с executionStats
hi
Если я правильно помню, то по вложенным ключам covered query невозможен
но если в условии только $gt или $lt работает же. версия 4.0.9
yopp
Да
hi
Да
{ "queryPlanner" : { "plannerVersion" : 1, "namespace" : "test.col", "indexFilterSet" : false, "parsedQuery" : { "$and" : [ { "data.contracts.dateSigned" : { "$lt" : "2019-06-02T00:00:00+03:00" } }, { "data.contracts.dateSigned" : { "$gt" : "2019-05-01T16:00:00+03:00" } } ] }, "winningPlan" : { "stage" : "FETCH", "filter" : { "data.contracts.dateSigned" : { "$lt" : "2019-06-02T00:00:00+03:00" } }, "inputStage" : { "stage" : "IXSCAN", "keyPattern" : { "data.contracts.dateSigned" : 1 }, "indexName" : "data.contracts.dateSigned_1", "isMultiKey" : true, "isUnique" : false, "isSparse" : false, "isPartial" : false, "indexVersion" : 2, "direction" : "forward", "indexBounds" : { "data.contracts.dateSigned" : [ "(\"2019-05-01T16:00:00+03:00\", {})" ] } } }, "rejectedPlans" : [ { "stage" : "FETCH", "filter" : { "data.contracts.dateSigned" : { "$gt" : "2019-05-01T16:00:00+03:00" } }, "inputStage" : { "stage" : "IXSCAN", "keyPattern" : { "data.contracts.dateSigned" : 1 }, "indexName" : "data.contracts.dateSigned_1", "isMultiKey" : true, "isUnique" : false, "isSparse" : false, "isPartial" : false, "indexVersion" : 2, "direction" : "forward", "indexBounds" : { "data.contracts.dateSigned" : [ "[\"\", \"2019-06-02T00:00:00+03:00\")" ] } } } ] }, "executionStats" : { "executionSuccess" : true, "nReturned" : 93379, "executionTimeMillis" : 15229, "totalKeysExamined" : 115770, "totalDocsExamined" : 114662, "executionStages" : { "stage" : "FETCH", "filter" : { "data.contracts.dateSigned" : { "$lt" : "2019-06-02T00:00:00+03:00" } }, "nReturned" : 93379, "executionTimeMillisEstimate" : 14846, "works" : 116325, "advanced" : 93379, "needTime" : 22391, "needYield" : 554, "saveState" : 1446, "restoreState" : 1446, "isEOF" : 1, "invalidates" : 0, "docsExamined" : 114662, "alreadyHasObj" : 0, "inputStage" : { "stage" : "IXSCAN", "nReturned" : 114662, "executionTimeMillisEstimate" : 390, "works" : 115771, "advanced" : 114662, "needTime" : 1108, "needYield" : 0, "saveState" : 1446, "restoreState" : 1446, "isEOF" : 1, "invalidates" : 0, "keyPattern" : { "data.contracts.dateSigned" : 1 }, "indexName" : "data.contracts.dateSigned_1", "isMultiKey" : true, "isUnique" : false, "isSparse" : false, "isPartial" : false, "indexVersion" : 2, "direction" : "forward", "indexBounds" : { "data.contracts.dateSigned" : [ "(\"2019-05-01T16:00:00+03:00\", {})" ] }, "keysExamined" : 115770, "seeks" : 1, "dupsTested" : 115770, "dupsDropped" : 1108, "seenInvalidated" : 0 } } }, "ok" : 1 }
yopp
попробуйте в запросе явно указать поля в проекции, чтоб запрос удовлетворял covered query: _id: 0, «...,signed”: 1
hi
попробуйте в запросе явно указать поля в проекции, чтоб запрос удовлетворял covered query: _id: 0, «...,signed”: 1
пробовал, не помогало и то что сейчас скинул, это вот такой запрос, не find даже db.col.explain('executionStats').count({"data.contracts.dateSigned":{$gt:"2019-05-01T16:00:00+03:00",$lt:"2019-06-02T00:00:00+03:00"}})
hi
Покажите эксплейн с проекцией. Ещё не очень понимаю: у вас даты в строках?
> db.col.explain('executionStats').find({"data.contracts.dateSigned":{$gt:"2019-05-01T16:00:00+03:00",$lt:"2019-06-02T00:00:00+03:00"}},{_id:0,'data.contracts.dateSigned':1}).count() { "queryPlanner" : { "plannerVersion" : 1, "namespace" : "test.col", "indexFilterSet" : false, "parsedQuery" : { "$and" : [ { "data.contracts.dateSigned" : { "$lt" : "2019-06-02T00:00:00+03:00" } }, { "data.contracts.dateSigned" : { "$gt" : "2019-05-01T16:00:00+03:00" } } ] }, "winningPlan" : { "stage" : "FETCH", "filter" : { "data.contracts.dateSigned" : { "$lt" : "2019-06-02T00:00:00+03:00" } }, "inputStage" : { "stage" : "IXSCAN", "keyPattern" : { "data.contracts.dateSigned" : 1 }, "indexName" : "data.contracts.dateSigned_1", "isMultiKey" : true, "isUnique" : false, "isSparse" : false, "isPartial" : false, "indexVersion" : 2, "direction" : "forward", "indexBounds" : { "data.contracts.dateSigned" : [ "(\"2019-05-01T16:00:00+03:00\", {})" ] } } }, "rejectedPlans" : [ { "stage" : "FETCH", "filter" : { "data.contracts.dateSigned" : { "$gt" : "2019-05-01T16:00:00+03:00" } }, "inputStage" : { "stage" : "IXSCAN", "keyPattern" : { "data.contracts.dateSigned" : 1 }, "indexName" : "data.contracts.dateSigned_1", "isMultiKey" : true, "isUnique" : false, "isSparse" : false, "isPartial" : false, "indexVersion" : 2, "direction" : "forward", "indexBounds" : { "data.contracts.dateSigned" : [ "[\"\", \"2019-06-02T00:00:00+03:00\")" ] } } } ] }, "executionStats" : { "executionSuccess" : true, "nReturned" : 93382, "executionTimeMillis" : 14320, "totalKeysExamined" : 115852, "totalDocsExamined" : 114742, "executionStages" : { "stage" : "FETCH", "filter" : { "data.contracts.dateSigned" : { "$lt" : "2019-06-02T00:00:00+03:00" } }, "nReturned" : 93382, "executionTimeMillisEstimate" : 13882, "works" : 116304, "advanced" : 93382, "needTime" : 22470, "needYield" : 451, "saveState" : 1328, "restoreState" : 1328, "isEOF" : 1, "invalidates" : 0, "docsExamined" : 114742, "alreadyHasObj" : 0, "inputStage" : { "stage" : "IXSCAN", "nReturned" : 114742, "executionTimeMillisEstimate" : 320, "works" : 115853, "advanced" : 114742, "needTime" : 1110, "needYield" : 0, "saveState" : 1328, "restoreState" : 1328, "isEOF" : 1, "invalidates" : 0, "keyPattern" : { "data.contracts.dateSigned" : 1 }, "indexName" : "data.contracts.dateSigned_1", "isMultiKey" : true, "isUnique" : false, "isSparse" : false, "isPartial" : false, "indexVersion" : 2, "direction" : "forward", "indexBounds" : { "data.contracts.dateSigned" : [ "(\"2019-05-01T16:00:00+03:00\", {})" ] }, "keysExamined" : 115852, "seeks" : 1, "dupsTested" : 115852, "dupsDropped" : 1110, "seenInvalidated" : 0 } } }, "ok" : 1 }
hi
такое чувство, что индекс не может двусторонние границы ставить
yopp
Попроуйбе сбросить план: https://docs.mongodb.com/manual/reference/method/PlanCache.clear/#PlanCache.clear
yopp
И покажите план если не делать count()
yopp
А у вас там не массив случайно?
hi
И покажите план если не делать count()
спросил план, вот без каунта db.col.explain('executionStats').find({"data.contracts.dateSigned":{$gt:"2019-05-01T16:00:00+03:00",$lt:"2019-06-02T00:00:00+03:00"}},{_id:0,'data.contracts.dateSigned':1}) { "queryPlanner" : { "plannerVersion" : 1, "namespace" : "test.col", "indexFilterSet" : false, "parsedQuery" : { "$and" : [ { "data.contracts.dateSigned" : { "$lt" : "2019-06-02T00:00:00+03:00" } }, { "data.contracts.dateSigned" : { "$gt" : "2019-05-01T16:00:00+03:00" } } ] }, "winningPlan" : { "stage" : "PROJECTION", "transformBy" : { "_id" : 0, "data.contracts.dateSigned" : 1 }, "inputStage" : { "stage" : "FETCH", "filter" : { "data.contracts.dateSigned" : { "$lt" : "2019-06-02T00:00:00+03:00" } }, "inputStage" : { "stage" : "IXSCAN", "keyPattern" : { "data.contracts.dateSigned" : 1 }, "indexName" : "data.contracts.dateSigned_1", "isMultiKey" : true, "isUnique" : false, "isSparse" : false, "isPartial" : false, "indexVersion" : 2, "direction" : "forward", "indexBounds" : { "data.contracts.dateSigned" : [ "(\"2019-05-01T16:00:00+03:00\", {})" ] } } } }, "rejectedPlans" : [ { "stage" : "PROJECTION", "transformBy" : { "_id" : 0, "data.contracts.dateSigned" : 1 }, "inputStage" : { "stage" : "FETCH", "filter" : { "data.contracts.dateSigned" : { "$gt" : "2019-05-01T16:00:00+03:00" } }, "inputStage" : { "stage" : "IXSCAN", "keyPattern" : { "data.contracts.dateSigned" : 1 }, "indexName" : "data.contracts.dateSigned_1", "isMultiKey" : true, "isUnique" : false, "isSparse" : false, "isPartial" : false, "indexVersion" : 2, "direction" : "forward", "indexBounds" : { "data.contracts.dateSigned" : [ "[\"\", \"2019-06-02T00:00:00+03:00\")" ] } } } } ] }, "executionStats" : { "executionSuccess" : true, "nReturned" : 93383, "executionTimeMillis" : 18028, "totalKeysExamined" : 115900, "totalDocsExamined" : 114790, "executionStages" : { "stage" : "PROJECTION", "nReturned" : 93383, "executionTimeMillisEstimate" : 17172, "works" : 117452, "advanced" : 93383, "needTime" : 22517, "needYield" : 1551, "saveState" : 2356, "restoreState" : 2356, "isEOF" : 1, "invalidates" : 0, "transformBy" : { "_id" : 0, "data.contracts.dateSigned" : 1 }, "inputStage" : { "stage" : "FETCH", "filter" : { "data.contracts.dateSigned" : { "$lt" : "2019-06-02T00:00:00+03:00" } }, "nReturned" : 93383, "executionTimeMillisEstimate" : 12704, "works" : 117452, "advanced" : 93383, "needTime" : 22517, "needYield" : 1551, "saveState" : 2356, "restoreState" : 2356, "isEOF" : 1, "invalidates" : 0, "docsExamined" : 114790, "alreadyHasObj" : 0, "inputStage" : { "stage" : "IXSCAN", "nReturned" : 114790, "executionTimeMillisEstimate" : 280, "works" : 115901, "advanced" : 114790, "needTime" : 1110, "needYield" : 0, "saveState" : 2356, "restoreState" : 2356, "isEOF" : 1, "invalidates" : 0, "keyPattern" : { "data.contracts.dateSigned" : 1 },
hi
И покажите план если не делать count()
"indexName" : "data.contracts.dateSigned_1", "isMultiKey" : true, "isUnique" : false, "isSparse" : false, "isPartial" : false, "indexVersion" : 2, "direction" : "forward", "indexBounds" : { "data.contracts.dateSigned" : [ "(\"2019-05-01T16:00:00+03:00\", {})" ] }, "keysExamined" : 115900, "seeks" : 1, "dupsTested" : 115900, "dupsDropped" : 1110, "seenInvalidated" : 0 } } } }, "ok" : 1 }
hi
А у вас там не массив случайно?
где именно? contracts это массив объектов, в которых dateSigned это строка. а data это объект
yopp
А что в плане без $gte?
hi
я читал, что планировщик делает тестовый запрос на 101 документ по разным планам, и в explain это можно посмотреть, но там рассматривались только два варианта (индекс по $gt, FETCH по $lt и наоборот)
hi
А что в плане без $gte?
если find с проекцией, то тоже FETCH делает, если count, то вот
yopp
Меня смущает что в плане bounds только с одной стороны указывается. Если у вас есть возможность, попробуйте в документы добавить поле со значением в Date
hi
А покажите весь план
это с count https://pastebin.com/WXNKdmgM find очень долго идет, могу с лимитом показать
hi
вот find с лимитом https://pastebin.com/SjMjGWUj
yopp
Странно. Я вам рекомендую сделать две вещи: 1) проверить что это воспроизводится на 4.0.10 и завести баг в жире что в вашем случае не используется covered query. 2) сконвертировать значения из строк в date. Меня смущает что генерируется странный шейп и есть ощущение что это из-за строки
yopp
Для теста можете добавить второе поле dateSignedDate или что-то такое
yopp
Ещё есть шанс что это как-то связанно с тем, что у вас там массив
hi
Для теста можете добавить второе поле dateSignedDate или что-то такое
всмысле добавить его в тот же массив или просто в документ?
yopp
Для начала рядом с существующим полем
hi
а, ну тогда такое поле уже есть, сейчас потестирую его
hi
ага, с ним все отлично
hi
и оно в таком же формате
yopp
В смысле там тоже строка или там date?
yopp
😳
yopp
Т.е. у вас в массиве есть поддокументы и там две даты строками, по обеим индекс?
hi
Т.е. у вас в массиве есть поддокументы и там две даты строками, по обеим индекс?
а, извините, я не правильно понял. это я сейчас тестировал поле не из массива, а на уровне с ним
yopp
Понятно, значит третий вариант :)
hi
^
да, значит дело в массиве. попробую обновиться и протестить. а чтобы в тот же массив добавить поле с Date(dateSigned) лучше forEach использовать или aggregate?
yopp
Мне кажется быстрее будет написать обновлятор на forEach
yopp
В AF надо будет ещё помучаться чтоб в массиве документов поля сконверитровать
hi
да, пожалуй что
Viktor
Народ, помогите! Настроил реплику сет, через ансибл. Есть 3 инстанса, один из них арбитр. Приложение понимает только 1 адрес монги, как быть, когда електится другой инстанс в примари?
yopp
Народ, помогите! Настроил реплику сет, через ансибл. Есть 3 инстанса, один из них арбитр. Приложение понимает только 1 адрес монги, как быть, когда електится другой инстанс в примари?
Стоит заменить арбитра на реальную ноду, особенно если вы планируете использовать read/write concern majority. В connection string указаны все три ноды?
« Rev
@mongodb_ru   555
Fwd »