Можно сортировать по самому objectId т.к. всё корректно отрабатывать будет, также время создания можно из ObjectId вытащить.

О спасибо об этом не знал.

https://medium.com/serpapi/mongodb-benchmark-3-4-vs-4-4-vs-5-0-vs-6-0-cb65146ae5ee Всем здравствуйте! Хотим монгу на 6 версию с 4.4 обновить. Наткнулись на такую статью. Подскажите, пожалуйста, этой статье можно верить? Или кто-нибудь сталкивался с деградацией, после обновления?

https://medium.com/serpapi/mongodb-benchmark-3-4-vs-4-4-vs-5-0-vs-6-0-cb65146ae5ee Всем здравствуйте! Хотим монгу на 6 версию с 4.4 обновить. Наткнулись на такую статью. Подскажите, пожалуйста, этой статье можно верить? Или кто-нибудь сталкивался с деградацией, после обновления?

Я извиняюсь, есть ли в монге метод при создании документа что б его вернул? При обновлении нашел, а при создании не увидел. Иль самому делать доп запрос?

Насколько хорошей идеей будет удалять документ из MongoDB по составному индексу? Или это нежелательно и лучше удалять по id?

Удаление документов из MongoDB по составному индексу возможно и может быть полезным в некоторых ситуациях. Однако, есть несколько вещей, которые следует учесть: 1. Производительность: Удаление документов по составному индексу может быть медленнее, чем удаление по идентификатору (id). При использовании составного индекса MongoDB должна выполнить дополнительные операции для поиска и удаления соответствующих документов. 2. Уникальность: Если составной индекс не является уникальным, удаление по нему может привести к удалению нескольких документов, соответствующих критериям индекса. В то время как удаление по идентификатору (id) гарантирует удаление только одного документа. 3. Читаемость кода: Удаление по идентификатору (id) является более понятным и ясным для других разработчиков. Они могут легко понять намерение удаления документа по его уникальному идентификатору. В целом, рекомендуется использовать удаление по идентификатору (id), если это возможно. Однако, если у вас есть особые требования или конкретные сценарии использования, где удаление по составному индексу имеет смысл, то вы можете использовать его. Важно оценить производительность и уникальность составного индекса перед его использованием для удаления документов.

Вот и делай дальше с ним что хочешь, монга ж просто вставляет его в коллекцию

Да тоже думал так и сделать и лишний раз не нагружать

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

А зачем при обновлении сделали?

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

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

try{...insert... return true}catch{return false}

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

Я пока не совсем понимаю разницы, между вставкой и обновлении, почему в первом случае решили не возвращать документ, а во втором сделали возврат

И в первом и во втором случае можно обойтись без возврата

У меня возникают вопросы по поводу того почему insert не возвращает значение из за того что сама MongoDB может генерировать ObjectId но она его не возвратит.

Немного не понял, но инсерт возвращает айди в ответе

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

InserOneAsync ничего не возвращает, просто Task

Добрый день. Не знаю, точно ли я по адресу, тем не менее, вдруг направите в нужном направлении. Дано: 0 опыта и знаний по монго. Тем не менее, имеется одна БД в составе ПО, которая крутилась на отдельной виртуалке. Так вышло, что виртуализация поднакрылась медным тазом 29.06 вечером. Последний бэкап виртуалки целиком от 29.06 03:00. Быстренько восстановили виртуалку из бэкапа, данные продолжили писаться в неё. Однако удалось восстановить образ виртуалки с базой монго на момент накрытия тазом. В используемой в данный момент базе нет данных за 29.06. В восстановленном образе есть данные за 29.06, но нет всего, что после. Есть ли какие-либо способы внести в используемую сейчас базу утерянные данные за 29.06?

Добрый день. Не знаю, точно ли я по адресу, тем не менее, вдруг направите в нужном направлении. Дано: 0 опыта и знаний по монго. Тем не менее, имеется одна БД в составе ПО, которая крутилась на отдельной виртуалке. Так вышло, что виртуализация поднакрылась медным тазом 29.06 вечером. Последний бэкап виртуалки целиком от 29.06 03:00. Быстренько восстановили виртуалку из бэкапа, данные продолжили писаться в неё. Однако удалось восстановить образ виртуалки с базой монго на момент накрытия тазом. В используемой в данный момент базе нет данных за 29.06. В восстановленном образе есть данные за 29.06, но нет всего, что после. Есть ли какие-либо способы внести в используемую сейчас базу утерянные данные за 29.06?

если данных нет в бэкапах то восстановить неоткуда. разве что вы в логи писали данные и оттуда можно вытащить.

Так я и говорю что он не возвращает Id.

Экспортнуть по датам или таймштампам, если они присутствуют, и смёрджить импортом, если структура доков не слишком сложная для экспорта и он правильно всё прохавает. На отдельном инстансе проверяется.

Ок, т.е. можно сдампить данные за определённый срок и импортировать их в другую базу? Опять же, они полные клоны, просто в разных временах существуют будто бы.)

Всем привет. Подскажите, плиз, как вообще работает oplog? Не могу понять... Сначала делаю фулл бэкап в директорию backup Затем делаю изменения в бд, и делаю бэкап в директорию backup с флагом --oplog. Появляется файл oplog.bson. Содержимое следующее {"op":"n", "ns":"", "o": "msg":{"periodic noop"}, "ts":{"$timestamp":{"t":1686761275,"i":1}}, "t":{"$numberLong":"6"}, "v":{"$numberLong":"2"}, "wall":{"$date":{"$numberLong":"1686761275306"}}} Затем снова делаю изменения в монге, добавляю бд и коллекции. Запускаю mongodump с флагом —oplog. Файл oplog.bson просто перезатирается и не содержит информации, таймстамп о предыдущем бэкапе. {"op":"n","ns":"", "o":{"msg":"periodic noop"}, "ts":{"$timestamp":{"t":1686764685,"i":1}}, "t":{"$numberLong":"6"}, "v":{"$numberLong":"2"}, "wall":{"$date":{"$numberLong":"1686764685631"}}} Так и должно быть или упускаю какие-то моменты? Для фул бэкапа использую `mongodump --username backup_user --password backuppass12345 --host=rs0/mongodb-home-1:27017,mongodb-home-2:27017,mongodb-home-3:27017 --authenticationDatabase=admin --out=$(hostname)-$(date +%d%m%y)` Для инкрементального `mongodump --username backup_user --password backuppass12345 --host=rs0/mongodb-home-1:27017,mongodb-home-2:27017,mongodb-home-3:27017 --authenticationDatabase=admin --out=$(hostname)-$(date +%d%m%y) --oplog`

Да, oplog и содержимое коллекций при повторном вызове mongodump заменяется на новое содержимое базы на момент бэкапа

Различные директории, в этом случае у вас будут срезы на момент бэкапа

хотелось бы сохранить место. Я думал, что если буду делать бэкап в течение семи дней с флагом oplog, то смогу вернуться к бэкапу, который был например на 3ий день. А так получается, какой бэкап крайний, тот и восстанавливается.

Пробуйте Перкону или сторонние бэкап движки.

хотелось бы сохранить место. Я думал, что если буду делать бэкап в течение семи дней с флагом oplog, то смогу вернуться к бэкапу, который был например на 3ий день. А так получается, какой бэкап крайний, тот и восстанавливается.

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

может быть уже есть готовые инструменты?

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

купи самый дешевый хостинг и сам себе сделай )

Привет. Подскажите пж. Стэк: монга 6 + монгус и нода. Так вышло что база упала (так и не понял почему), и заново не переподключилась пока вручную не перезапустил скрипт. Соответственно скрипт работал и кидал запросы на базу, а она лежала и выходили ошибки. Вопрос в том, как можно обезопаситься от таких ситуаций, на случай ночного падения базы, чтоб система условно заново реконнектнулась ?

Как обезопаситься от того, что вы не понимаете почему упала СУБД? Ответ в вопросе после запятой.

Есть плагины мангуста для пррверки коннекшна. Если не подкл то само подклбчить. Mongoose autoconnect Типа такого. Погуглите даьлше плз сами

Всем привет. Может кто подскажет: какой командой добавить реплику к шарду? Хочу повысить отказоустойчивость. Новый сервер настроен и готов. Выполнять же все в роутере нужно?