скорее всего было так

заведи арбитра

заведи арбитра

Где арбитр, там и слейв. Вай нот?

ну может по ресурсам тяжело держать еще одного слейва

можно и так

Да, вы правы, зависит от размера.

2018-08-15T17:57:50.048Z I REPL [ReplicationExecutor] Not starting an election, since we are not electable due to: Not standing for election because I cannot see a majority (mask 0x1)

Видимо вот причина, почему не меняет статус

Я так понимаю, на 3.0 у меня так работало. А на 3.4 такой "сомнительных подход" не катит, просит 2 запущенных ноды для выборов

2018-08-15T17:57:50.048Z I REPL [ReplicationExecutor] Not starting an election, since we are not electable due to: Not standing for election because I cannot see a majority (mask 0x1)

Нет мажорити (большинства) говорит. Это подверждает, что третий нужен ;)

Ага, разобрались! Спасибо!

Но все же странно, что на 3.0 это спокойно работало

И даже конфликтов не припомню

очень вряд ли, что работало

может все таки был арбитр

Неа

2 ноды без арбитра

как одна падает, вторая в primary

что значит "падает"?

ты ее конкретно отключал?

Падает я имею ввиду когда захожу на сервер и киляю процесс

Т.е. при рабочей сети

ну, как я понимаю, то такого быть не должно вообще

На 2.6 вообще кворума не было, насколько я помню. У кого выше приоритет, тот и primary. А если че не так, уходит в rollback и мучайся дальше

нет, в 2.х было такое же поведение

это by design

не помню за 1.х

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

Так то

Ребят, делаю по примеру из док-и драйвера с добавлением поля индексации по увеличению "Single Ascending Index" http://mongodb.github.io/mongo-java-driver/3.4/driver/tutorials/indexes/ пишу: https://ghostbin.com/paste/ecuzn

но новое поле name не добавляется в таком случае

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

в примере док-и ровно так и написано: collection.createIndex(Indexes.ascending("name"));

Ребят, делаю по примеру из док-и драйвера с добавлением поля индексации по увеличению "Single Ascending Index" http://mongodb.github.io/mongo-java-driver/3.4/driver/tutorials/indexes/ пишу: https://ghostbin.com/paste/ecuzn

Подозрительно выглядит append к insertOne.... Точно здесь нет ошибки?

Подозрительно выглядит append к insertOne.... Точно здесь нет ошибки?

сейчас скрин приложу

вот, никаких предупреждений в коде нет

и все прекрасно добавляется, кроме единственного поля с индексированием

и все прекрасно добавляется, кроме единственного поля с индексированием

Все — это что конкретно?

Любите вы ребусы... Ладно. А что такое ...fieldNames в предыдещем скрине?

Любите вы ребусы... Ладно. А что такое ...fieldNames в предыдещем скрине?

fieldNames это просто IDE подсвечивает, что прописать в скобках

подразумевая под названием поля

Блин, или я перепил или вы не по-русски говорите :)

Блин, или я перепил или вы не по-русски говорите :)

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

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

Так индекс делается на существующее поле, а в приведенных документах поля name нет

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

Так индекс делается на существующее поле, а в приведенных документах поля name нет

хм, возможно, Вы правы. А как объявить тогда сверху?

Объявит тогда сверху?? Вы на эротику намекаете? :))))

Объявит тогда сверху?? Вы на эротику намекаете? :))))

ахах, нет. Пытаюсь понять, что добавить )

Смотрите: индекс добавляется на существующее поле. Точнее, скорее всего и на несуществующее можно (может потом появится) но сам факт добавления индекса не создаст само поле. Сделайте это поле так же как делаете другие: url, title и др.

Понял, сейчас попробую вручную поле добавить.

Понял, сейчас попробую вручную поле добавить.

Ну конечно

Извините, я спать ?. Но суть вы поняли

Извините, я спать ?. Но суть вы поняли

да, спасибо, спокойной)

4.0.1 появилась в дебиане:# apt list --upgradable Listing… Готово mongodb-org/jessie 4.0.1~rc1 amd64 [upgradable from: 4.0.0~rc7] mongodb-org-mongos/jessie 4.0.1~rc1 amd64 [upgradable from: 4.0.0~rc7] mongodb-org-server/jessie 4.0.1~rc1 amd64 [upgradable from: 4.0.0~rc7] mongodb-org-shell/jessie 4.0.1~rc1 amd64 [upgradable from: 4.0.0~rc7] mongodb-org-tools/jessie 4.0.1~rc1 amd64 [upgradable from: 4.0.0~rc7]

Всем привет. подскажите, можно ли создать юзера в монге только с одним action: update ?

Всем привет. подскажите, можно ли создать юзера в монге только с одним action: update ?

Можно, но могут быть проблемы

понял ) тогда пожалуй не буду этим заниматься )

Всем привет. подскажите, можно ли создать юзера в монге только с одним action: update ?

Вроде пишут, что можно: https://docs.mongodb.com/manual/reference/privilege-actions/#security-user-actions @dd_bb а какого рода проблемы могут возникнуть?

Драйвера могут при подключении выполнять какие-то команды

Драйвера могут при подключении выполнять какие-то команды

а, ясн...

понял ) тогда пожалуй не буду этим заниматься )

Если будет точно известен какой драйвер, то попробуй

ну вообще планируется ссшится на хост, и делать mongo

Методом проб и ошибок за пару часов можно найти комбинацию прав, которой хватит

ERROR: S client not available

Ни у кого не завалялось какого-нибудь чтива про опыт использования монги на больших кластерах (суммарным объемом от 10ТБ данных)?

А что вас интересует?

Ни у кого не завалялось какого-нибудь чтива про опыт использования монги на больших кластерах (суммарным объемом от 10ТБ данных)?

Извините, нет. Лично я не дорос ещё :)

А что вас интересует?

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

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

Главная проблема: ОЧЕНЬ сложно бэкапить 1) Балансировкой рулить никак нельзя, можно либо руками таскать чанки, либо дать шедулеру окно. 2) Не делать аналитические фуллсканы, а делать прогессивные отчёты. Если нужна настоящая горячяя аналитки, монга не лучший выбор. Но с помощью шардинга и достаточного capacity на шарде, это вполне реально 3) AF отличная штука. Про временные данные данные не понял. В шарде «паралеллизация» будет зависеть от запроса 4) map/reduce лучше избегать 5) ;)

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

ну, 10+ТБ особо и некуда бэкапить, это можно только реплицировать. Вот с АФ я столкнулся с некторыми проблемами (даже без клстера). Например, когда делаешь лукап, такое ощущение, что он делает подзапрос под каждый документ стейджа. Более разумным повоедением было бы собрать все значения localField каждому документу, одним запросом выгрузить все необходимые данные из from коллекции и уже в памяти смержить исходные документы с новыми. Или делать это хотя бы чанками, если весь стейдж не помещается в памяти. Как это на кластере будет, я вообще не представляю. Да, я обеспечу, что все данные будут в пределах одного шарда, соглашусь на временные коллеции для стейджей, но кто и как потом эти временные коллекции будет собирать и делать по ним тот же $out. В общем, есть сомнения, насколько это все быстро может работать

репликация != резервное копирование.

ну и опять же, сложные аналитические запросы очень хорошо ложатся на колонучную модель, т.к. выгружаются только ключевые столбцы данных и по ним делаются рассчеты, а потом собираются полные данные. В АФ есть $project , но судя по модели АФ, когда каждый стейдж -- это независимая копия коллекции данных, все будет только хуже, если сначала ограничить по $project, а потом еще раз собрать данные

если вам нужен $lookup, вам не нужна монга

в общем, мужики сомневаются, что бигдата на монге взлетит)

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

out в map/reduce в кластере будет больной темой

ну, по обычные офлайн запросы аналитиков: найти группу людей, которые за предыдущие 3 месяца заходили на страницу Х, после этого купили не менее 8 товаров категории У, после чего пропали на 9 или более часов, но потом вернулись и кликнули на рекламу Z. Все это с гистограммой по версии браузера и был ли дождь в это время за окном

я не знаю как в последних версиях, но из-за того, что под out делается временная коллекция, кластер на время создания коллекции может стоять в локе. это _очень_ больно

я не знаю как в последних версиях, но из-за того, что под out делается временная коллекция, кластер на время создания коллекции может стоять в локе. это _очень_ больно

ужас )

я понял, зря я на монгу в этом плане хоть как-то смотрел ))

спасибо

если вы думаете что будет волшебная таблетка, то вы ошибаетесь

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

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

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

ну, в целом, я не вижу больших проблем делать лукапы производительнее, делать ауты более умными

ну вы не видите, а я вижу :)

вы хотите реляционную базу в документном хранилище

так не бывает

точнее бывает, но тогда оно работает так, как работает сейчас

я вообще считаю что $lookup они сделали зря

монговцы молодцы. они реализовали все фичи, которые покрыли их модель данных, которая по их мнению покрывает 80% проблем. и теперь решают оставшиеся 20% проблем, типа accidental relations и транзакционность

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