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

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

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

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

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

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

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

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

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

дешевле для кого? ты работал на сервисах где 10 минут простоя пол з\п?

дешевле для кого? ты работал на сервисах где 10 минут простоя пол з\п?

Давай не будем доходами меняться?

Давай не будем доходами меняться?

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

Речь о том что 3 сервера в реплике это очень хорошо и правильно. Но надо не всегда и не всем.

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

Речь о том что 3 сервера в реплике это очень хорошо и правильно. Но надо не всегда и не всем.

если это прод, то всегда надо

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

Хрыч, ты говоришь безапеляционно и не владея ситуацией. Вот и все.

Хрыч, ты говоришь безапеляционно и не владея ситуацией. Вот и все.

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

То есть с 3 железками в реплике простоев быть не может и в такой бумаге смысла Нет?

То есть с 3 железками в реплике простоев быть не может и в такой бумаге смысла Нет?

при такой конфигурации шансы ниже % на 98

Ниже. Но не 100%

Вот многие с этими 98% согласны мириться. У всего своя цена, Хрыч

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

Вот многие с этими 98% согласны мириться. У всего своя цена, Хрыч

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

а вот при чтении реплика просто могла отвалиться

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

Страшные вещи ты говоришь а выяснилось, почему данные побились?

Страшные вещи ты говоришь а выяснилось, почему данные побились?

8 нод, 10000 сообщений в сек вставка в каждую, не сказал бы что особо разберёшь

то есть при таком кейсе не важно - 2 сервера или 8, все равно данные бились

))) мы в репликасете 5 серверов держим сейчас

Используете чтение с Secondary ?

Используете чтение с Secondary ?

Да, в том числе

Три сервера в разных странах планируется. Касаемо заливки данных подскажите, кто знает. Кто сталкивался с таким кейсом

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

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

Впски взяты у одного хостера, и там по странам , бывало, редко но был инцидент , когда полностью их датаценто отваливается, соотвественно если у меня будет три сервера в одной стране , я могу потерять всю реплику, поэтому и разные страны хотяб две, касаемо шардинга я к сожалению не силён, если есть возможность подскажите как правильно сделать , чтобы было «тру», поэтому и обратился в данную конфу.

Т.е. Имелось ввиду тупо несколько дц

звучит так - директор дебил хочет вложить 50 копеек, нашёл лоха и хочет от него хайлоад

Вы не разобрались в задаче человека и начали его и его окружение оскорблять. Неделя в read-only для осознания что этот чат с профессиональной атмосферой, а не помойка для срачей.

Привет всем, подскажите пожалуйста есть кейс,его решение : есть приложение бекенд которого сейчас смотрит в монгу (бек-nodejs) требуется сделать реплику, тут использую replica set - вопрос если берётся 1 мастер и два дополнительно сервера , преимущество арбитра? Нужен или нет ? После Настройки реплики я в бекенде в ноду через коннектор прописываю подключение к трём базам и он постоянно будет держать коннект. Вопрос про арбитр - нужен или нет, и второй вопрос после создании реплики, я делаю пользователя , делаю экспорт базы на мастер, все остальное реплицируется самостоятельно ? Или какие либо действия надо ? Я новичок в этом сейчас, пересмотрел кучу мануалов, почему и возникла спорная ситуация

Если у вас нечётное число нод то арбитр не нужен. Задача арбитра избежать ситуации brain split, когда кластер потерял связанность и изолированными остались группы одного размера. Например было 4 ноды, в двух дц и между дц упал линк. Так как нод с обоих сторон осталось поровну, они не могут решить кто будет мастером и как следствие failover не сработает.

В вашем случае с одной нодой в одном дц и общим количеством в три штуки — арбитр скорее всего не нужен.

Про переход от stand-alone к replica set не требует ре-импорта. Вам необходимо перезапустить сервер в режиме репликации и дальше инициализировать и настроить реплику. Вот плейбук https://docs.mongodb.com/manual/tutorial/convert-standalone-to-replica-set

Та мысль, которую в очень некорректной форме пытался донести @erzentd, заключается в том, что вам надо учитывать что в монге eventual consistent репликация. Это значит что ваши изменения будут реплицированны «когда-то» (eventually). В монге для работы с этим есть writeConcern: https://docs.mongodb.com/manual/reference/write-concern/

С помощью него вы можете выбрать в какой момент ваше приложение получит подтверждение записи. В вашем случае majority будет скорее всего достаточно.

Без использования сессий (фича из 3.6) нет полной гарантии успешности записи. С сессиями эту гарантию можно реализовать

Если вы не планируете использовать реплики для чтения, а только как failover hot standby, то на этом ваши проблемы почти закончились

Если вы планируете использовать реплики для чтения, то вам ещё надо изучить readConcern и проанализировать как задержки в репликации будут влиять на целостность ваших данных. Основная проблема тут что вы можете читать устаревшие данные. В 3.4 появились инструменты которые могут вам частично решить ценой производительности и эту проблему (linerarizable reads)

Для мониторинга возьмите готовое решение. New relic, mongo cloud monitoring, vividcortex и т.дъ

@dd_bb есть какие-то бест практисы по бекапу монги? База около 400гб сейчас, сделано так: дампится база с одной из реплик, архивируется и заливается дальше в другое хранилище

Так вот архивация (7zip) сейчас отжирает очень много по времени

Если архивации только смущает то есть смысл попробовать pigz или pbzip2 Они жмут по количеству процессоров.

Скорость архивации имел ввиду

Если архивации только смущает то есть смысл попробовать pigz или pbzip2 Они жмут по количеству процессоров.

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

снепшоты файловой системы, если надо бекапить большие объемы. думаю так, но лучше послушать спецов

снепшоты файловой системы, если надо бекапить большие объемы. думаю так, но лучше послушать спецов

ну в общем да) у нас нет возможности снапшотов, поэтому останавливаем балансировку кластера, и делаем копию бэкап нод рсинком

рсинк долгий по сути ему каждый файл считать и скопировать надо будет. но если нода именно под бекап - наверное это не критично

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

» потом останавливается запись в бэкап ноду это как? вы ее просто тушите? или выводите из репликасета конкретного шарда? ...и так одновременно на всех 12ти шардах?

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

да, по сути операция стартует одновременно на 12 серверах

А у вас шард из скольки хостов состоит? 2 + 1 для бекапа ?

А у вас шард из скольки хостов состоит? 2 + 1 для бекапа ?

3+1, бэкап нода скрыта, с priority = 0

Понял, спасибо у меня 2 + арбитр не нравится, но тем не менее.

Понял, спасибо у меня 2 + арбитр не нравится, но тем не менее.

в моей практике мы арбитры не используем.

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

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

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

Понял а довливали данные сразу в шард или в монгос?

Понял а довливали данные сразу в шард или в монгос?

извините, не понял вопроса

» когда удалили часть документов, и их надо было вытащить из бэкапа я так понял, их сдампили из hidden хоста, который под бекап и дальше их влить обратно в монгу надо В сам монгос же вливали?

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

Понял Спасибо!

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

» держать отстающую реплику, да, я именно так и предполагал - реплики под бекап зачастую delayed и делают.

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

Да, понимаю, согласен

@dd_bb спасибо за рекомендации, буду читать маны и пробовать делать/тестить. Вопрос все же если будет больше трёх нод в будущем ? Можно и потом и арбитр прикрутить ? Или с ним стоит сразу заморочиться ? И вопрос как правильнее, чтобы бек писал в базу, и оно реплицировалось на остальных двух нодах( пока что ) или чтобы бекенд лил инфу во все сразу , но в ввиду территориального расположения могут быть задержки, отставания и прочие проблемы, лучше тогда чтобы репликация была, в случае падения мастер- 1 сервер, данные будут писаться на ближайший ? И в случае восстановления работы сервера (мастер) данные как быстро синхронизируются , и куда в этот момент будет бекенд писать данные ?

@dd_bb спасибо за рекомендации, буду читать маны и пробовать делать/тестить. Вопрос все же если будет больше трёх нод в будущем ? Можно и потом и арбитр прикрутить ? Или с ним стоит сразу заморочиться ? И вопрос как правильнее, чтобы бек писал в базу, и оно реплицировалось на остальных двух нодах( пока что ) или чтобы бекенд лил инфу во все сразу , но в ввиду территориального расположения могут быть задержки, отставания и прочие проблемы, лучше тогда чтобы репликация была, в случае падения мастер- 1 сервер, данные будут писаться на ближайший ? И в случае восстановления работы сервера (мастер) данные как быстро синхронизируются , и куда в этот момент будет бекенд писать данные ?

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

Всем привет. Подскажите, можно ли использовать $sample вместе с $near у геопоиска?

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

Ты про этикет не слышал, наверное?

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

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

Господа, на 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

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

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

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