Подскажите пару моментов с подключением монго?

Так ты вопрос задай.

Господа, на 3.4.13 начала падать монга. на 3 гигах памяти. ранее ей было достаточно... нагрузки там нету. это просто ci система

пока из замеченного падает на дебиан 8+

Други, подскажите. монга у меня около 300гб, сейчас понадобились еще мемберы в RS. я снял дамп тачки с базой, и залил дамп на новый хост, чтобы с нуля реплика не поднималась ибо долго, но оно пишет 2018-03-01T06:25:00.834+0000 I REPL [ReplicationExecutor] could not find member to sync from 2018-03-01T06:25:00.834+0000 E REPL [rsBackgroundSync] too stale to catch up -- entering maintenance mode 2018-03-01T06:25:00.834+0000 I REPL [rsBackgroundSync] our last optime : (term: -1, timestamp: Feb 28 00:15:16:33) 2018-03-01T06:25:00.834+0000 I REPL [rsBackgroundSync] oldest available is (term: -1, timestamp: Feb 28 16:05:42:b8) 2018-03-01T06:25:00.834+0000 I REPL [rsBackgroundSync] See http://dochub.mongodb.org/core/resyncingaverystalereplicasetmember 2018-03-01T06:25:00.834+0000 I REPL [ReplicationExecutor] going into maintenance mode with 5 other maintenance mode tasks in progress вот читаю стэк, пишут с нуля поднимать, очищать data folder можно ли как то еще?

А размер оплога какой?

configured oplog size: 2768.711669921875MB

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

а как понять, до какого размера ?

Ну разница между временем последней и первой записи, даст вам понимание операционного окна

а как понять, до какого размера ?

как я понимаю, вам нужен полный дамп с текущего засинхронизированного хоста, вместе с оплогом. Вливайте его в новую базу и вставляйте в репликасет - должен подхватиться и начать досинкиваться. Выше правильно отметили про размер оплога Вкратце я бы смотрел как: на рабочем репликасете запустите rs.printSlaveReplicationInfo() интересует строка log length start to end: - это будет ориентировочное время, за какой период у вас лежат данные в оплоге. Вот за это время надо успеть сделать дамп, влить его на новый хост, который планируете добавить в репликасет, и подключить его. Если успеете , то новый хост найдет нужные данные для досинкивания. проверять состояние можно через rs.printSlaveReplicationInfo() — будет видно время отставания. Вообще же я сомневаюсь, что дамп базы + restore ее на новом хосте будет ощутимо быстрее, чем синк данных в изначально пустую базу. Рассмотрите вариант синка с нуля, но опять же - прикиньте размер оплога, чтобы изначальный синк (там еще будет построение индексов, если мне не изменяет память) успел пройти за то время, на которое хватает оплога.

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

Нет) увы)

Спасибо за разьяснения

Господа, добрый день, Кому-то известно insert vs insert_many с точки зрения используемых файловых дескрипторов имеют отличия? Заранее благодарен за ответ.)

А при чем тут дескпторы? Если подразумеваются коннекты, то сколько откроете столько и будет использовано

Подразумевается операция записи на жесткий диск

На диске коллекция выглядит как один файл плюс файлы индексов, так что об этом не стоит беспокоиться

Вообще с чего аозникла необходимость в контроле дескрипторов?

В связи с большим кол-вом используемых дескрипторов на запись

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

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

К сожалению есть просто факт, IOPS очень большой и это проблема.

По умолчанию все буферится и скидывается на диск периодически. Вы модете только принадительно вкючить журналировагие каждого инсерта, но видимо вам это не требуется

Сколько вставок в базу идет?

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

Никак.

Спасибо

К сожалению есть просто факт, IOPS очень большой и это проблема.

Дескриптор никак не относится к количеству IOPS, это просто пайп

Ваша проблема не в количестве открытых дескрипторов, а в том, что объём чтения или записи превышает возможности железа. Лучшая стратегия разобраться какие запросы создают такую нагрузку.

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

Спасибо, тогда вот вопрос, при insertMany у нас происходит последовательный доступ к диск?

Спасибо, тогда вот вопрос, при insertMany у нас происходит последовательный доступ к диск?

Вы вообще никак не можете контролировать порядок доступа к данным на диске.

Меня интересует как это реализовано в mongodb

Нет никакого способа это спрогнозировать.

Может и да, может и нет

insertMany это просто сгруппированные в один сетевой пакет множества insert

Да, спасибо.

Насколько большой у вас поток данных в субд?

Спасибо, тогда вот вопрос, при insertMany у нас происходит последовательный доступ к диск?

https://github.com/mongodb/mongo/blob/a77297dbe34d5cd838a4da55e9d83dc70c510bba/src/mongo/db/catalog/collection_impl.cpp#L452 судя по этому коду доступ последовательный

файловая система ext3-4 не гарантирует последовательный доступ

https://github.com/mongodb/mongo/blob/a77297dbe34d5cd838a4da55e9d83dc70c510bba/src/mongo/db/catalog/collection_impl.cpp#L452 судя по этому коду доступ последовательный

Нет, вы не правы. Весь код сводится к recordStore->insertRecords Это высокоуровневый API для подключаемых record stores. Реальное поведение будет зависеть от используемого. С 3.2 это WiredTiger, который использует copy-on-write. Предсказать какая нагрузка будет в случае вставки ряда документов — невозможно. Это будет зависеть от ряда факторов: сколько reusable pages есть, хватает ли их для вмещения данных, в каких областях дискового хранилища они находятся

спасибо

Второй момент: даже если приложение чего-то хочет от ФС последовательно, это не значит что с диска это будет прочитано последовательно.

Как на самом деле данные будут прочитаны с диска тоже крайне сложно предсказать.

Всё это носит вероятностный характер.

Нет, вы не правы. Весь код сводится к recordStore->insertRecords Это высокоуровневый API для подключаемых record stores. Реальное поведение будет зависеть от используемого. С 3.2 это WiredTiger, который использует copy-on-write. Предсказать какая нагрузка будет в случае вставки ряда документов — невозможно. Это будет зависеть от ряда факторов: сколько reusable pages есть, хватает ли их для вмещения данных, в каких областях дискового хранилища они находятся

Не спорю, код mongodb смотрю второй или третий раз в жизни, но вижу, что WiredTigerRecordStore::_insertRecords так же последовательно пишет данные, по одной записи. Насчет файловых систем безусловно всё так, рассуждаю исключительно с точки зрения того, как это описано в коде и не более

Не спорю, код mongodb смотрю второй или третий раз в жизни, но вижу, что WiredTigerRecordStore::_insertRecords так же последовательно пишет данные, по одной записи. Насчет файловых систем безусловно всё так, рассуждаю исключительно с точки зрения того, как это описано в коде и не более

Вы опять делаете неверное предположение, основываясь на обрывочной информации. Указанный вами класс это реализация интерфейса record store. Тот факт что там последовательно вызываеются методы setkey setvalue самого WiredTiger ещё не означает что операции на деле будут выполнятся последовательно.

Если вы хотите разобраться в этом вопросе, почитайте документацию к WiredTiger или статьи о его архитектуре. Они в интернете есть.

Есть даже несколько сравнений WT с другими KV хранилищами.

Вы опять делаете неверное предположение, основываясь на обрывочной информации. Указанный вами класс это реализация интерфейса record store. Тот факт что там последовательно вызываеются методы setkey setvalue самого WiredTiger ещё не означает что операции на деле будут выполнятся последовательно.

ага, понятно. То есть операции записи где-то внизу (имею ввиду в коде) асинхронные?

Если вы хотите разобраться в этом вопросе, почитайте документацию к WiredTiger или статьи о его архитектуре. Они в интернете есть.

да, хорошо, спасибо!

ага, понятно. То есть операции записи где-то внизу (имею ввиду в коде) асинхронные?

Нет, асинхронность и последовательный доступ к диску это разные вещи. Представьте себе WT как обычный GC на счетчике указателей. Грубо говоря WT оперирует ссылками на страницы. Он никогда не меняет содержимое существующей страницы, а только создаёт новую и заменяет указатель. Когда на страницу нет больше указателей, страница помечается как свободная. Свободные страницы могут использоваться как новые. Исходя из этого даже последовательное изменение данных не гарантирует последовательного положения страниц в дисковом хранилище.

Stable: 3.6.3 (Feb 23, 2018), Bugfix: 3.4.13 (Feb 10, 2018) 3.6.3: https://docs.mongodb.com/manual/release-notes/3.6/#february-23-2018 3.4.13: https://docs.mongodb.com/manual/release-notes/3.4/#feb-10-2018 3.2.19: https://docs.mongodb.com/manual/release-notes/3.2/#feb-6-2018 (End of life: September 2018) 3.0.x: Support ended February 2018

Друзья, помните я когда-то спрашивал о своей структуре данных и о том, как ее обновлять: https://stackoverflow.com/questions/48967418/multiple-arrays-of-objects-inside-array-of-objects-in-mongodb Дак вот в 3.6 то, оказывается, эти фичи допилили как раз: http://thecodebarbarian.com/a-nodejs-perspective-on-mongodb-36-array-filters.html и это нормально считается когда в документах есть массив с объектами, в которых тоже есть массивы.

@websanya это касается только nodejs, оптимизаций не подвезли, связанных с такими массивами?

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

@websanya это касается только nodejs, оптимизаций не подвезли, связанных с такими массивами?

Не, это в самом ядре добавили.

В смысле если я на джавке сижу, я почувствую разницу то?

Дык тут разница в том, что принципиально не было этого функционал.

$[]

ArrayFilters.

Фильтры к сожалению индексы не используют, поэтому это полудохлая фича, но тем не менее.

И теперь можно несколько $[] использовать за раз.

Это добавлено в ядро, поэтому все дравйвера тоже теперь это будут использовать с 3.6

Здравствуйте. Использую http метод GET базы. Что нужно вводить в "query"?

странный вопрос, вы с помощью чего к монге цепляетесь?

странный вопрос, вы с помощью чего к монге цепляетесь?

Да через один конструктор телеграм бота делаю

UpdateDB: {"collection":"cryptobot","query":[[{"username":"${global.message.from.username}","messages":[{"time":"${global.message.date}","text":"${global.message.text}"}]}]],"upsert":true} ReadDB: {"collection":"cryptobot"} SendMessage: "${data}" Почему-то по команде отправляет пустую базу

для начала назовите конструкто/язык/драйвер

для начала назовите конструкто/язык/драйвер

www.mega-bot.com

там регаться надо, видимо там же спрашивайте у саппорта почему не работает

он на работе...

диалог не получается)))

Здравствуйте. Подскажите пожалуйста, у меня есть коллекция 'Settings', в которой находится объект 'table'. Как я могу добавлять новые поля не в саму коллекцию, а именно в объект?! Заранее спасибо

Через точку, как и в обычном js

table.v1

И дальше вставка объекта в коллекцию, лиьо через апдейпт

Здравствуйте. Установил монгодб на комп. что ту длаьше делать?

Здравствуйте. Установил монгодб на комп. что ту длаьше делать?

использовать

Знать бы, как... Создало папку, там файлы какие-то

Знать бы, как... Создало папку, там файлы какие-то

https://docs.mongodb.com/

Не подскажете, можно ли сделать примерно следующее: Поставить кластер из 3-ех арбитров за ~keepalived и подключить это к 2-ум нодам как арбитр? Т.е. я хочу реплику с арбитром, но так, чтобы 2 ноды думали что общаются с одним арбитром, хотя на самом деле общаются с балансером, за которым стоит кластер арбитров Даже не спрашивайте зачем

балансер раздает на живого арбитра с самым высоким приоритетом, а не round-robin-ом нужно для того, чтобы нода не уходила в секондари, когда отваливается арбитр + праймари