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

всем привет, а подскажите что в mongodb значит returned document?

но выглядит правдоподобно)

ОЙ, то есть Cannot access 'book' before initialization

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

Всем привет, кто-то из вас когда-нибудь заливал на монго бота для дискорда?

Привет всем! Нужна помощь с шардированной mongodb. Ситуация такая: Имеются 4 рабочие шарды c размером одной из баз около 2TB, т.е. по 500 Гигов на шарду. Потребовалось добавить 5ю шарду и тут возникла проблема с долгой балансировкой. За 1 месяц перенеслось около 15% . Вопрос в след. нормальная ли данная ситуация? либо есть проблема которую я не вижу? mongos> sh.status() --- Sharding Status --- sharding version: { "_id" : 1, "minCompatibleVersion" : 5, "currentVersion" : 6, "clusterId" : ObjectId("5fb65dda1d6aedfdh23832") } shards: { "_id" : "1_shard", "host" : "1_shard/m1.shard.ru:28100,m2.shard.ru:28100", "state" : 1 } { "_id" : "2_shard", "host" : "2_shard/m2.shard.ru:28200,m3.shard.ru:28200", "state" : 1 } { "_id" : "3_shard", "host" : "3_shard/m3.shard.ru:28300,m4.shard.ru:28300", "state" : 1 } { "_id" : "4_shard", "host" : "4_shard/m4.shard.ru:28400,m5.shard.ru:28400", "state" : 1 } { "_id" : "5_shard", "host" : "5_shard/m1.shard.ru:28500,m5.shard.ru:28500", "state" : 1 } active mongoses: "4.4.1" : 5 "4.4.2" : 1 autosplit: Currently enabled: yes balancer: Currently enabled: yes Currently running: yes Collections with active migrations: ebase.Message started at Tue Oct 25 2022 11:08:30 GMT+0300 (MSK) Failed balancer rounds in last 5 attempts: 0 Migration Results for the last 24 hours: 21 : Success 17 : Failed with error 'aborted', from 2_shard to 5_shard 677 : Failed with error 'aborted', from 1_shard to 5_shard databases: { "_id" : "config", "primary" : "config", "partitioned" : true } config.system.sessions shard key: { "_id" : 1 } unique: false balancing: true chunks: 1_shard 205 2_shard 205 3_shard 205 4_shard 205 5_shard 204 too many chunks to print, use verbose if you want to force print { "_id" : "ebase", "primary" : "4_shard", "partitioned" : true, "version" : { "uuid" : UUID("den6c870-a8b7-446d-9894-66b80ddd1d07"), "lastMod" : 1 } } ebase.Message shard key: { "_id" : "hashed" } unique: false balancing: true chunks: 1_shard 32725 2_shard 32725 3_shard 32723 4_shard 32723 5_shard 4695 too many chunks to print, use verbose if you want to force print { "_id" : "test", "primary" : "3_shard", "partitioned" : false, "version" : { "uuid" : UUID("94d782h0-a8c2-4129-ad27-a60e9fsd1fe6"), "lastMod" : 1 } }

Увы, это нормальная ситуация

у вас достаточно старая версия монги, в 5.x и 6.x ситуацию немного улучшили, можете попробовать аккуратно до 5.x апнутся. С 6.x могут быть проблемы с драйверами, нужно будет протестировать совместимость

хм. спасибо за совет, были планы обновить до 4.4.17 для начала, если ситуация не улучшится, будем смотреть в сторону 5) спасибо!

Привет всем! Нужна помощь с шардированной mongodb. Ситуация такая: Имеются 4 рабочие шарды c размером одной из баз около 2TB, т.е. по 500 Гигов на шарду. Потребовалось добавить 5ю шарду и тут возникла проблема с долгой балансировкой. За 1 месяц перенеслось около 15% . Вопрос в след. нормальная ли данная ситуация? либо есть проблема которую я не вижу? mongos> sh.status() --- Sharding Status --- sharding version: { "_id" : 1, "minCompatibleVersion" : 5, "currentVersion" : 6, "clusterId" : ObjectId("5fb65dda1d6aedfdh23832") } shards: { "_id" : "1_shard", "host" : "1_shard/m1.shard.ru:28100,m2.shard.ru:28100", "state" : 1 } { "_id" : "2_shard", "host" : "2_shard/m2.shard.ru:28200,m3.shard.ru:28200", "state" : 1 } { "_id" : "3_shard", "host" : "3_shard/m3.shard.ru:28300,m4.shard.ru:28300", "state" : 1 } { "_id" : "4_shard", "host" : "4_shard/m4.shard.ru:28400,m5.shard.ru:28400", "state" : 1 } { "_id" : "5_shard", "host" : "5_shard/m1.shard.ru:28500,m5.shard.ru:28500", "state" : 1 } active mongoses: "4.4.1" : 5 "4.4.2" : 1 autosplit: Currently enabled: yes balancer: Currently enabled: yes Currently running: yes Collections with active migrations: ebase.Message started at Tue Oct 25 2022 11:08:30 GMT+0300 (MSK) Failed balancer rounds in last 5 attempts: 0 Migration Results for the last 24 hours: 21 : Success 17 : Failed with error 'aborted', from 2_shard to 5_shard 677 : Failed with error 'aborted', from 1_shard to 5_shard databases: { "_id" : "config", "primary" : "config", "partitioned" : true } config.system.sessions shard key: { "_id" : 1 } unique: false balancing: true chunks: 1_shard 205 2_shard 205 3_shard 205 4_shard 205 5_shard 204 too many chunks to print, use verbose if you want to force print { "_id" : "ebase", "primary" : "4_shard", "partitioned" : true, "version" : { "uuid" : UUID("den6c870-a8b7-446d-9894-66b80ddd1d07"), "lastMod" : 1 } } ebase.Message shard key: { "_id" : "hashed" } unique: false balancing: true chunks: 1_shard 32725 2_shard 32725 3_shard 32723 4_shard 32723 5_shard 4695 too many chunks to print, use verbose if you want to force print { "_id" : "test", "primary" : "3_shard", "partitioned" : false, "version" : { "uuid" : UUID("94d782h0-a8c2-4129-ad27-a60e9fsd1fe6"), "lastMod" : 1 } }

Привет всем! Нужна помощь с шардированной mongodb. Ситуация такая: Имеются 4 рабочие шарды c размером одной из баз около 2TB, т.е. по 500 Гигов на шарду. Потребовалось добавить 5ю шарду и тут возникла проблема с долгой балансировкой. За 1 месяц перенеслось около 15% . Вопрос в след. нормальная ли данная ситуация? либо есть проблема которую я не вижу? mongos> sh.status() --- Sharding Status --- sharding version: { "_id" : 1, "minCompatibleVersion" : 5, "currentVersion" : 6, "clusterId" : ObjectId("5fb65dda1d6aedfdh23832") } shards: { "_id" : "1_shard", "host" : "1_shard/m1.shard.ru:28100,m2.shard.ru:28100", "state" : 1 } { "_id" : "2_shard", "host" : "2_shard/m2.shard.ru:28200,m3.shard.ru:28200", "state" : 1 } { "_id" : "3_shard", "host" : "3_shard/m3.shard.ru:28300,m4.shard.ru:28300", "state" : 1 } { "_id" : "4_shard", "host" : "4_shard/m4.shard.ru:28400,m5.shard.ru:28400", "state" : 1 } { "_id" : "5_shard", "host" : "5_shard/m1.shard.ru:28500,m5.shard.ru:28500", "state" : 1 } active mongoses: "4.4.1" : 5 "4.4.2" : 1 autosplit: Currently enabled: yes balancer: Currently enabled: yes Currently running: yes Collections with active migrations: ebase.Message started at Tue Oct 25 2022 11:08:30 GMT+0300 (MSK) Failed balancer rounds in last 5 attempts: 0 Migration Results for the last 24 hours: 21 : Success 17 : Failed with error 'aborted', from 2_shard to 5_shard 677 : Failed with error 'aborted', from 1_shard to 5_shard databases: { "_id" : "config", "primary" : "config", "partitioned" : true } config.system.sessions shard key: { "_id" : 1 } unique: false balancing: true chunks: 1_shard 205 2_shard 205 3_shard 205 4_shard 205 5_shard 204 too many chunks to print, use verbose if you want to force print { "_id" : "ebase", "primary" : "4_shard", "partitioned" : true, "version" : { "uuid" : UUID("den6c870-a8b7-446d-9894-66b80ddd1d07"), "lastMod" : 1 } } ebase.Message shard key: { "_id" : "hashed" } unique: false balancing: true chunks: 1_shard 32725 2_shard 32725 3_shard 32723 4_shard 32723 5_shard 4695 too many chunks to print, use verbose if you want to force print { "_id" : "test", "primary" : "3_shard", "partitioned" : false, "version" : { "uuid" : UUID("94d782h0-a8c2-4129-ad27-a60e9fsd1fe6"), "lastMod" : 1 } }

А можно поинтересоваться железом существующего кластера, и сетью и железом до нового сервера. А то прям совсем грустные показатели.

Intel(R) Xeon(R) W-2145 CPU @ 3.70GHz 8 X 32 GB DDR4 ECC RAM 2 × 960 GB SATA SSD LAN 1GBit

проверьте за одно что у вас FCV установлен в 4.4 https://www.mongodb.com/docs/manual/release-notes/4.4-upgrade-sharded-cluster/#enable-backwards-incompatible-features там есть ряд вещей которые могут сломаться, например FCV 4.4 включает structured logging. если у вас есть инструменты которые завязаны на анализ логов, их вероятно придётся обновить. https://www.mongodb.com/docs/manual/release-notes/4.4-compatibility/

Intel(R) Xeon(R) W-2145 CPU @ 3.70GHz 8 X 32 GB DDR4 ECC RAM 2 × 960 GB SATA SSD LAN 1GBit

и самой важной инфы про диск нет, какой диск, какая скорость записи/чтения ))) хостинги как обычно хитрят

Пожалуйста, воздержитесь от высказываний формата «дело в руках». Это неконструктивно Ребалансировка достаточно сложная операция, с почти десятком стадий. Одна из сложностей это момент синхронизации между донором и реципиентом, которая требует координации между тремя компонентами. Если переносимыый чанк меняется, монге может потребовать достаточно много времени на его перенос. Скорость балансировки от «рук» не зависит, так как настроек которыми можно что-то в балансировке изменить — нет. В протоколе постепенно что-то меняют в лучшую сторону, но для того чтоб ситуация улучшилась нужно обновлятся до последней стабильной версии. Недели на ребалансировку больших объёмов, к сожалению, ожидаемое поведение. В некоторой степени скорость может зависеть от того, упирается ли монга в ресурсы (диск/сеть/цпу) и насколько большой лаг репликации. Если мне память не изменяет, то при миграции чанков используется writeConcern > 1 (или majority?). Где-то была ручка которой можно его понизить, но это не самый безопасный способ

У меня ребалансировка с 5 до 6 шардов заняло больше месяца. Общий объем был около 4ТБ. ~800млн записей. 5-я монга.

А какой размер чанка?

Также ты всегда гарантируешь, что данные в едином стиле и не надо с бубном танцевать либо ещё что-то делать

с отрицательными датами тоже не надо заморачиваться тогда

А чем тебя 0 не устраивает?

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

с отрицательными датами тоже не надо заморачиваться тогда

а есть примеры где отрицательные даты используютяс7

а есть примеры где отрицательные даты используютяс7

Например сделка произошла в 4 утра по Москве и по тз стоит, что каждый клиент видит своё время и тогда если человек с Бразилии, тогда надо сделать -3 за место -6

архивные записи об истории, антропологические, геологические, археологические исследования, где постоянно идёт работа с отрицательными датами

это про таймзоны

ну да реально есть потребность)

а есть примеры где отрицательные даты используютяс7

Метрики не смотрели, раз уж все так печально, было бы интересно знать, как читает и пишет по сети при такой операции кластер. Прям очень печальный факт.

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

То есть минимум свободной памяти 50%?

Это на сервере?

да

А она нужна вам, другие сервисы еще есть? Почему так много свободной?

там закэшировано 140 гб на сколько я вижу.

Вы конфигурировали настройки по памяти монги?

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

я сейчас заметил что me5 (новая шарда) упирается в диск. Либо это нормальная ситуации при балансировки.

в топе 90% [kworker/u72:2+flush-8:0] и mongodb 90%

а сервер свой, в клауде, реальное железо? Я сейчас посмотрел на свои, 1 в яндексе тоже 2 tb sdd, и на свой из реального железа микро сервер, 2 tb nvme - и на тот и на другой клиенты из клауда пишут одни и те же данные(просто дублируется информация). так вот на сервере от яндекса, существенно видно нагрузка по iotop от mongo до 90%, а реальный ее не замечает просто...

хм, интересно... Да, у нас дэдики в хетснери.

а сервер свой, в клауде, реальное железо? Я сейчас посмотрел на свои, 1 в яндексе тоже 2 tb sdd, и на свой из реального железа микро сервер, 2 tb nvme - и на тот и на другой клиенты из клауда пишут одни и те же данные(просто дублируется информация). так вот на сервере от яндекса, существенно видно нагрузка по iotop от mongo до 90%, а реальный ее не замечает просто...

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