у меня кажется все сейчас заработало

надо проверить в mongoose

Кажется все работает правильно. Странно, что до этого в другой базе не работало

А кстати, да у меня тут есть индексы. В той базе их не было

Спасибо всем большое)

Всем привет! При помощи graphql создаю пользователя в mongodb и первый юзер создается без проблем, после чего возвращается его id (1 скрин). Но когда пытаюсь создать второго юзера, кидает ошибку (2 скрин). Юзер скима 3 скрин. В чём может быть дело?

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

А тк его ни в модели, ни в данных нет, то = нул, второй нул не хочет вставлять

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

Да я вижу текст, но пока не особо понимаю где, что смотреть)

Только начал юзать монго

Да я вижу текст, но пока не особо понимаю где, что смотреть)

Я бы на твоем месте просто дропнул базу)) (плохие советы)

Я бы на твоем месте просто дропнул базу)) (плохие советы)

Что значит дропнул базу?

Что значит дропнул базу?

удалил. Но не базу а коллекцию. Не правильно выразился)

Я бы на твоем месте просто дропнул базу)) (плохие советы)

Главное, чтобы не на проде)

Доброго дня нужна помощь, не получается добавить новую реплику. Есть репликасет в одном дц, нужно добавить еще несколько серверов в другом, обмен через openvpn, проходит 10 попыток, после чего монга отключается, причем попытки могут длиться и почти полдня и несколько минут. Ошибки примерно такие: 2021-01-31T11:46:13.675+0300 E REPL [replication-38] Initial sync attempt failed -- attempts left: 0 cause: NetworkInterfaceExceededTimeLimit: error fetching oplog during initial sync: Operation timed out, request was RemoteCommand 534461 -- target:10.1.1.14:27017 db:local expDate:2021-01-31T11:46:13.666+0300 cmd:{ find: "oplog.rs", filter: { ts: { $gte: Timestamp 1612082689000|1 } }, tailable: true, oplogReplay: true, awaitData: true, maxTimeMS: 2000, term: 52, readConcern: { afterOpTime: { ts: Timestamp 1612082689000|1, t: 52 } } }

вроде никаких ошибок в openvpn не вижу, может увеличить в монге таймауты, местами так рекомендуют? но не нашел какие таймауты. Кстати гуглил ошибку и видел разные значения maxTimeMS: хотя вроде как это таймаут запроса, а не интерфейса

в новом дц на этих же серверах подымали независимо репликасет, проблем не было

Добрый день. Вопрос можно задать?

пытаюсь подключиться на локальном компе к mongo atlas. использую uri для подключения через driver >=3.6. Установлена свежая версия nodejs. Подключение не происходит. Пробую через драйвер 2.2.12 и все норм. В чем может быть проблема? Почему так?

Доброго дня нужна помощь, не получается добавить новую реплику. Есть репликасет в одном дц, нужно добавить еще несколько серверов в другом, обмен через openvpn, проходит 10 попыток, после чего монга отключается, причем попытки могут длиться и почти полдня и несколько минут. Ошибки примерно такие: 2021-01-31T11:46:13.675+0300 E REPL [replication-38] Initial sync attempt failed -- attempts left: 0 cause: NetworkInterfaceExceededTimeLimit: error fetching oplog during initial sync: Operation timed out, request was RemoteCommand 534461 -- target:10.1.1.14:27017 db:local expDate:2021-01-31T11:46:13.666+0300 cmd:{ find: "oplog.rs", filter: { ts: { $gte: Timestamp 1612082689000|1 } }, tailable: true, oplogReplay: true, awaitData: true, maxTimeMS: 2000, term: 52, readConcern: { afterOpTime: { ts: Timestamp 1612082689000|1, t: 52 } } }

NAT используется? Телнетом на порт сервера можете зайти?

Телнетом цепляется в тебе стороны, да в одну сторону нат есть

NAT используется? Телнетом на порт сервера можете зайти?

Данные передаются некоторое время а потом ошибка тайм-аут, все удаляется и заново начинается. Версия 3.4

Хочу сделать Load More, использую mongoose, можете подсказать, как это можно реализовать?

Хочу сделать Load More, использую mongoose, можете подсказать, как это можно реализовать?

https://stackoverflow.com/questions/24689344/lazy-loading-more-data-scroll-in-mongoose-nodejs

Спасибо, попробую

Коллеги, такой вопрос - пытаюсь поднять шардинг кластер на свежей версии mongoDB, балансер режет на чанки но возле всех чанков выставляется признак jumbo и миграции между нодами шардинг кластера не происходит. на версии 4.4.3 ошибка BSONObjectTooLarge: BSONObj size: 16805367 (0x1006DF7) is invalid. Size must be between 0 and 16793600(16MB) First element: на версии 4.2.12 ошибка Chunk move failed :: caused by :: ChunkTooBig: Cannot move chunk: the maximum number of documents for a chunk is 366, the maximum chunk size is 1048576, average document size is 3717. Found 58717 documents in chunk вопрос - почему балансировщик сам режет на шарды которые не могут пролезть в миграцию? делал chunksize: 1024 attemptToBalanceJumboChunks : true не помогло

возможно дело в ключе шардирования, он довольно равномерно разделяет документы в коллекции, но для каждого уникального ключа - обьем данных ~ миллионы документов. Если руками нарезать чанки на более маленькие - со временем флаг jumbo перестает выставляться и данные начинают мигрировать. но это очень муторное и не автоматизированное занятие, ощущение что я делаю чтото не так

Подскажите в чем проблема, раскатил стэндэлон монгу в кубере, коннект к базе извне проходит нормально, монгорестор падает - connection refused

Короче с божьей помощью рестор запустился, в чем была проблема не знаю

Приветствую! Ребят, прошу о помощи) 1) Примерная структура коллекции: peoples: [ {login: login1, platform: platform1, id: objectID, ... foo:bar } {login: login1, platform: platform2, id: objectID, ... foo:bar } {login: login3, platform: platform1, id: objectID, ... foo:bar } {login: login5, platform: platform1, id: objectID, ... foo:bar } {login: login5, platform: platform2, id: objectID, ... foo:bar } {login: login6, platform: platform2, id: objectID, ... foo:bar } ] 2) В рамках платформы, логины не повторяются 3) Задача в следующем: 3.1) мы получаем входные данные, массив содержащий объекты с именем платформы и логином [ {login: login1, platform: platform1}, {login: login3, platform: platform3}, {login: login4, platform: platform3}, ] 3.2) Необходимо получить документы пользователей, по ключу логин+платформа. 3.3) Если для какого-то элемента, из массива условий (п.3.1), нет созданного документа, его необходимо создать (для нового (пустого) документа требуются только эти два поля) и вернуть новый док 3.4) в конечном итоге мы должны получить массив документов пользователей, независимо от того, были ли уже созданные доки в базе можно ли это решить одним запросом к базе? либо как то, чтобы не делать на каждое условие из массива что-то типа firstOrCreate()?

Коллеги, такой вопрос - пытаюсь поднять шардинг кластер на свежей версии mongoDB, балансер режет на чанки но возле всех чанков выставляется признак jumbo и миграции между нодами шардинг кластера не происходит. на версии 4.4.3 ошибка BSONObjectTooLarge: BSONObj size: 16805367 (0x1006DF7) is invalid. Size must be between 0 and 16793600(16MB) First element: на версии 4.2.12 ошибка Chunk move failed :: caused by :: ChunkTooBig: Cannot move chunk: the maximum number of documents for a chunk is 366, the maximum chunk size is 1048576, average document size is 3717. Found 58717 documents in chunk вопрос - почему балансировщик сам режет на шарды которые не могут пролезть в миграцию? делал chunksize: 1024 attemptToBalanceJumboChunks : true не помогло

Вы шардировали существующую коллекцию?

Вы шардировали существующую коллекцию?

да, восстановленную из бекапа на тестовый стенд

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

это если ключа шардирования хватает чтоб на каждое реальное значение ключа попадал один чанк

если не хватает, то необходимо менять шард ключ

вы можете в sh.status(true) увидеть список чанков с jubmo флагом

если после ручного разделения дальше чанки разделяются нормально, то возьмите список чанков с jumbo флагом в коллекции chunks на конфиг сервере и пройдитесь по ним скриптом чтоб порезать

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

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

к сожалению нет

чанки разделяются в момент вставки документа

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

если после ручного разделения дальше чанки разделяются нормально, то возьмите список чанков с jumbo флагом в коллекции chunks на конфиг сервере и пройдитесь по ним скриптом чтоб порезать

ну я смог разбить один чанк руками) это заняло достаточно много времени и обезьяннего труда. а всего чанков под 500)

чанки разделяются в момент вставки документа

а рестор коллекции не есть череда вставок?

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

если у вас коллекция на момент вставки не была шардирования то нет :)

ну создам коллекцию, создам необходимые индексы

индекс шардирования

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

ну да, но я так делал и результат был тотже (

возможно надо поиграться значением chunksize: 1024

ну да, но я так делал и результат был тотже (

когда я так делал - это значение я не меннял, 64мб по умолчанию если я правильно понял

Доброго дня нужна помощь, не получается добавить новую реплику. Есть репликасет в одном дц, нужно добавить еще несколько серверов в другом, обмен через openvpn, проходит 10 попыток, после чего монга отключается, причем попытки могут длиться и почти полдня и несколько минут. Ошибки примерно такие: 2021-01-31T11:46:13.675+0300 E REPL [replication-38] Initial sync attempt failed -- attempts left: 0 cause: NetworkInterfaceExceededTimeLimit: error fetching oplog during initial sync: Operation timed out, request was RemoteCommand 534461 -- target:10.1.1.14:27017 db:local expDate:2021-01-31T11:46:13.666+0300 cmd:{ find: "oplog.rs", filter: { ts: { $gte: Timestamp 1612082689000|1 } }, tailable: true, oplogReplay: true, awaitData: true, maxTimeMS: 2000, term: 52, readConcern: { afterOpTime: { ts: Timestamp 1612082689000|1, t: 52 } } }

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

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

+ вопрос а насколько адекватно в ключ шардирования добавлять даташтамп? не будет такой ситуации что для получения небольшого участка данных монгос пойдёт на все шардинг репликасеты?

возможно надо поиграться значением chunksize: 1024

это очень большой размер чанка

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

До таймаута, в логе какой статус репликации? Нода какие-то данные успевает синхронизировать?

это очень большой размер чанка

при таком значении хотябы 50-80% чанков не помечаюстя как jumbo и нормально мигрируют

Проверьте что по тем адресам которые у вас в rs.config все ноды могут к друг-другу подключатся

при таком значении хотябы 50-80% чанков не помечаюстя как jumbo и нормально мигрируют

покажите пример диапазаона у которого jumbo флаг

+ вопрос а насколько адекватно в ключ шардирования добавлять даташтамп? не будет такой ситуации что для получения небольшого участка данных монгос пойдёт на все шардинг репликасеты?

зависит от запросов, шард ключа и распределения данных по ключу

покажите пример диапазаона у которого jumbo флаг

зависит от запросов, шард ключа и распределения данных по ключу

все запросы используют account_id и store_id. 90% запросов используют также выборку по дататайму

До таймаута, в логе какой статус репликации? Нода какие-то данные успевает синхронизировать?

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

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

проверьте что канал стабильный

скорее всего с тонелем что-то не так

но на всякий случай проверьте что в логах у ноды с которой идёт initial sync

есть небольшой шанс что ей плохеет по какой-то причине

все запросы используют account_id и store_id. 90% запросов используют также выборку по дататайму

а оставшиеся 10%?

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

проверьте что канал стабильный

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

возможно проблема в канале через который проброшен тонель

а оставшиеся 10%?

редкие, там только account_id и store_id

но на всякий случай проверьте что в логах у ноды с которой идёт initial sync

там периодически за минуту-две несколько ошибок 2021-01-29T15:30:35.139+0000 I - [conn296509] AssertionException handling request, closing client connection: 6 socket exception [SEND_ERROR] for 10.20.1.1:39244

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

не наблюдаю ничего подобного

там периодически за минуту-две несколько ошибок 2021-01-29T15:30:35.139+0000 I - [conn296509] AssertionException handling request, closing client connection: 6 socket exception [SEND_ERROR] for 10.20.1.1:39244

socket exception это точно проблема с сетью

socket exception это точно проблема с сетью

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

не наблюдаю ничего подобного

а при первичной вставке?

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

нет, не решить