Comments 21
Сложилось впечатление, что вы не тестируя сразу заливали все изменения на продакшен (ну или работали с базой оттуда).
В чем суть раздела Запасные копии?
Вы просто использовали штатные средства.
Сказано, что использование реплик Вам не подошло, но ведь master-slave — это суть реплики, а бэкапы вы делаете этим способом. Так и не дошло, где тут масштаб трагедии?
Вы просто использовали штатные средства.
Сказано, что использование реплик Вам не подошло, но ведь master-slave — это суть реплики, а бэкапы вы делаете этим способом. Так и не дошло, где тут масштаб трагедии?
Да, штатными средствами, а если точнее — их комбинацией: master-slave репликации и mongodump-а. Другое дело, что к этому ещё нужно было придти через попытки использования сторонних утилит и мыслей «а не написать ли нам самим утилитку для обработки oplog-а».
Информация, наверное, полезная. Но разве не этот способ подразумевает сама Монга? Просто на уровне здравого смысла. А остальное — для уникальных ситуаций. Еще не очень понятно, как вы поиск впилили. Вы ищите не по всей коллекции? А если говорить о сфинксе — то там мгновенный поиск, но может просесть на этапе отдачи результатов поиска в саму монгу.
Так Вы используете штатную схему master-slave или всё же полноценную репликацию с арбитрами и отложенной репликой? Если первое — почему именно был сделан выбор в этом направлении? Если мне память не изменяет, master-slave и replica set — взаимоисключающие понятия.
Использовали master-slave, а не полноценную репликацию, потому что она банально проще в настройке + нежелательность попадания production-нагрузки на slave-instance (который у нас backup сервере, который в свою очередь — виртуальная машина).
Под production-нагрузкой имеются в виду запросы на чтение от приложения?
Если да, то в репликации монго запросы к отложенному слейву не попадают по определению.
Если да, то в репликации монго запросы к отложенному слейву не попадают по определению.
Если основная БД упадет, то произойдет арбитраж и трафик будет перенаправлен на другую машину, которая крутиться на VM. Хотя это наверняка лучше, чем не работающее приложение
Это поведение по умолчанию. slaveOk=true делает возможным чтение со слейва. Но это далеко не всегда принесет пользу — скорее всего будет race condition при проверке вашем приложении. (создать запись -> запись создана?): Запись не будет еще реплицирована к этому моменту.
Верно говорите, но slaveOk относится к случаю подключения напрямую к инстансу.
Мы же обсуждаем случай связки «приложение <-> replica set». Т.е. приложение подключается не к конкретному инстансу, а к реплике вцелом.
А вообще, мы обсуждаем, как бы не допустить запросов на секондари, потому что он — отложенный
Мы же обсуждаем случай связки «приложение <-> replica set». Т.е. приложение подключается не к конкретному инстансу, а к реплике вцелом.
А вообще, мы обсуждаем, как бы не допустить запросов на секондари, потому что он — отложенный
Было бы неплохо, если бы Вы указали версию (версии?) MongoDB. От этого многое зависит. И окружение.
Пристально смотрю на MongoBD, mySQL уже в печенках, гибкости реляционной бд явно не хватает для универсальных приложений, буду пробовать, спасибо за информацию.
Ничего лучше реляционных баз нет, и монго далеко не исключение — так побаловаться если…
Хинт: чтобы избежать настройки безопасности через сертификатыРазработчики рекомендуют защищать БД средствами ОС (вместо заведения пользователя).
Безопасность
Я для создания бекапов делал репликационную ноду (без голосования) на «домашнем сервере», которая бекапилась по крону, таким образом у меня есть срезы базы и свежая копия.
Ошибки при обрубании создания индекса — да, проходили. Лечится перезапуском сервиса монги и удалением недоделанного индекса. Нам несколько раз помогало. Но это не рекомендация — это на свой страх и риск!
Бэкап больших баз тоже проходили. Тут либо реплики либо снапшоты ФС (zfs/lvm). Рекомендации есть в родной документации.
Аккуратнее надо с субдами =)
Бэкап больших баз тоже проходили. Тут либо реплики либо снапшоты ФС (zfs/lvm). Рекомендации есть в родной документации.
Аккуратнее надо с субдами =)
Я работаю с Mongo уже года 3 и вот что решил для себя: MongoDB не так хороша в действительно BigData средах. «Простота» горизонтальной масштабируемости несколько преувеличена. Возьмем тот же Elasticsearch, где для добавления новой железки в кластер Вам нужно просто указать имя кластера на новой железке. Что предлагает нам Mongo? Давайте посчитаем, скажем, кластер из 20 физических серверов: Минимум 3 Конфиг ноды, Минимум 10 арбитров на другом железе/vm. При этом, если живем в реальных условиях скорее всего придется поднимать конфиги на том же кластере, а если еще хотим побороть глобальный лок (а мы хотим), то придется делить RAID на несколько томов, что повлечет за собой несколько инстансов mongod на одной машине, что в свою очередь означает строгую последовательность портов дата нод, в которую добавляем конфиг ноды и арбитры для дата шардов на другом железе. В итоге все это выливается в сложную систему, для обслуживания которой каждый раз вчитываемся в документацию чтобы ненароком не добавить реплику в неверный шард =)
У меня лично нет проблем с чтением документации, это сухое сравнение фактического пути достижения по сути одной цели.
У меня лично нет проблем с чтением документации, это сухое сравнение фактического пути достижения по сути одной цели.
Sign up to leave a comment.
Особенности использования MongoDB