Особенности использования MongoDB

[Rivethead]

Сложилось впечатление, что вы не тестируя сразу заливали все изменения на продакшен (ну или работали с базой оттуда).

[kazin8]

В чем суть раздела Запасные копии?
Вы просто использовали штатные средства.
Сказано, что использование реплик Вам не подошло, но ведь master-slave — это суть реплики, а бэкапы вы делаете этим способом. Так и не дошло, где тут масштаб трагедии?

[yar3333]

Да, штатными средствами, а если точнее — их комбинацией: master-slave репликации и mongodump-а. Другое дело, что к этому ещё нужно было придти через попытки использования сторонних утилит и мыслей «а не написать ли нам самим утилитку для обработки oplog-а».

[kazin8]

Информация, наверное, полезная. Но разве не этот способ подразумевает сама Монга? Просто на уровне здравого смысла. А остальное — для уникальных ситуаций. Еще не очень понятно, как вы поиск впилили. Вы ищите не по всей коллекции? А если говорить о сфинксе — то там мгновенный поиск, но может просесть на этапе отдачи результатов поиска в саму монгу.

[yar3333]

Что касается поиска — да — пока просто ограничили поиск для некритичных ситуаций по первым N записям. А для критичных — пока думаем (в продакшен этот сервис ещё не запущен).

[StamPit]

Так Вы используете штатную схему master-slave или всё же полноценную репликацию с арбитрами и отложенной репликой? Если первое — почему именно был сделан выбор в этом направлении? Если мне память не изменяет, master-slave и replica set — взаимоисключающие понятия.

[yar3333]

Использовали master-slave, а не полноценную репликацию, потому что она банально проще в настройке + нежелательность попадания production-нагрузки на slave-instance (который у нас backup сервере, который в свою очередь — виртуальная машина).

[bunya]

Под production-нагрузкой имеются в виду запросы на чтение от приложения?
Если да, то в репликации монго запросы к отложенному слейву не попадают по определению.

[AndryX]

Если основная БД упадет, то произойдет арбитраж и трафик будет перенаправлен на другую машину, которая крутиться на VM. Хотя это наверняка лучше, чем не работающее приложение

[bunya]

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

[AndryX]

О, я это в доке пропустил. Можете ссылку дать? Или как называется «отложенный secondary» в ней?

[bunya]

Он так и называется — Delayed

То, что он не сможет стать primary, исходит из обязательного требования установки свойства hidden в true.

[AutomationD]

Это поведение по умолчанию. slaveOk=true делает возможным чтение со слейва. Но это далеко не всегда принесет пользу — скорее всего будет race condition при проверке вашем приложении. (создать запись -> запись создана?): Запись не будет еще реплицирована к этому моменту.

[bunya]

Верно говорите, но slaveOk относится к случаю подключения напрямую к инстансу.
Мы же обсуждаем случай связки «приложение <-> replica set». Т.е. приложение подключается не к конкретному инстансу, а к реплике вцелом.

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

[derPilot]

Было бы неплохо, если бы Вы указали версию (версии?) MongoDB. От этого многое зависит. И окружение.

[yar3333]

Вы правы, указал в конце статьи.

[pokupo]

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

[tac]

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

[lega]

Хинт: чтобы избежать настройки безопасности через сертификаты
Безопасность

Разработчики рекомендуют защищать БД средствами ОС (вместо заведения пользователя).
Я для создания бекапов делал репликационную ноду (без голосования) на «домашнем сервере», которая бекапилась по крону, таким образом у меня есть срезы базы и свежая копия.

[pansa]

Ошибки при обрубании создания индекса — да, проходили. Лечится перезапуском сервиса монги и удалением недоделанного индекса. Нам несколько раз помогало. Но это не рекомендация — это на свой страх и риск!
Бэкап больших баз тоже проходили. Тут либо реплики либо снапшоты ФС (zfs/lvm). Рекомендации есть в родной документации.
Аккуратнее надо с субдами =)

[AutomationD]

Я работаю с Mongo уже года 3 и вот что решил для себя: MongoDB не так хороша в действительно BigData средах. «Простота» горизонтальной масштабируемости несколько преувеличена. Возьмем тот же Elasticsearch, где для добавления новой железки в кластер Вам нужно просто указать имя кластера на новой железке. Что предлагает нам Mongo? Давайте посчитаем, скажем, кластер из 20 физических серверов: Минимум 3 Конфиг ноды, Минимум 10 арбитров на другом железе/vm. При этом, если живем в реальных условиях скорее всего придется поднимать конфиги на том же кластере, а если еще хотим побороть глобальный лок (а мы хотим), то придется делить RAID на несколько томов, что повлечет за собой несколько инстансов mongod на одной машине, что в свою очередь означает строгую последовательность портов дата нод, в которую добавляем конфиг ноды и арбитры для дата шардов на другом железе. В итоге все это выливается в сложную систему, для обслуживания которой каждый раз вчитываемся в документацию чтобы ненароком не добавить реплику в неверный шард =)
У меня лично нет проблем с чтением документации, это сухое сравнение фактического пути достижения по сути одной цели.