@MongoDBRussian

Страница 197 из 342
 
Eugene
27.02.2018
05:44:50
Мне сейчас задача все это поднять, не имея опыта в репликах , обратился к вам

 
Max
27.02.2018
05:45:27
?всего 3 сервера?мда
Хрыч, ты дикий зануда неужто нельзя представить, что у людей может быть мало данных?

 
Старый
27.02.2018
05:45:43
Мне сейчас задача все это поднять, не имея опыта в репликах , обратился к вам
звучит так - директор дебил хочет вложить 50 копеек, нашёл лоха и хочет от него хайлоад

 
Max
27.02.2018
05:46:30
Мне сейчас задача все это поднять, не имея опыта в репликах , обратился к вам
возьмите тестовый стенд - хоть вагрантом, хоть докером запустите репликасет из 3х серверов. влейте данные, потыкайте, посмотрите-проверьте после этого растягивайте по миру.

Google
 
Старый
27.02.2018
05:47:06
Мне сейчас задача все это поднять, не имея опыта в репликах , обратился к вам
чел 3 ноды на каждую реплику, это минимум

 
Max
27.02.2018
05:47:20
звучит так - директор дебил хочет вложить 50 копеек, нашёл лоха и хочет от него хайлоад
В мире, где не только розовые пони, зачастую директорат и менеджмент правят бал. Потому или тебе выделываться и продолжать ходить ныть, как все фигово, или решать задачи бизнеса, параллельно оптимизируя и предлагая.

 
Eugene
27.02.2018
05:47:22
звучит так - директор дебил хочет вложить 50 копеек, нашёл лоха и хочет от него хайлоад
Звучит так что приложение на стадии тестирования, и попросил сделать реплику для тестов, я могу три сервера и внутри одной страны. Чтобы научиться это поднимать. Когда нудно и подниму тьму серверов

 
Max
27.02.2018
05:47:33
чел 3 ноды на каждую реплику, это минимум
С какого перепугу?

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

 
Zloy Dobriy
27.02.2018
05:50:29
Звучит так что приложение на стадии тестирования, и попросил сделать реплику для тестов, я могу три сервера и внутри одной страны. Чтобы научиться это поднимать. Когда нудно и подниму тьму серверов
Для тестов можно в нутри локалхоста понять репликусет из 3 или скольки надо

 
Старый
27.02.2018
05:52:23
Для тестов можно в нутри локалхоста понять репликусет из 3 или скольки надо
вот скажи как любям объяснять, что кроме репликейшен фактор 3 ничего использовать нельзя?

 
монга это кассандра это или хбайсе

 
Zloy Dobriy
27.02.2018
05:53:00
Документации не достаточно?

 
Старый
27.02.2018
05:53:55
Документации не достаточно?
не, в доке размыто пишут, я вот выше написал, что в каждой реплике должно быть 3 ноды мин, тут же ниже, не нужно и с 1 всё хорошо

 
Zloy Dobriy
27.02.2018
05:54:02
Если челку не досточно официальной доки, ему ни что уже не поможет

 
Eugene
27.02.2018
05:54:21
Спасибо за информацию,локально три контейнера запустить не проблема и потестить, но уже есть три впски и на них можно проводить тесты.

 
Zloy Dobriy
27.02.2018
05:54:45
не, в доке размыто пишут, я вот выше написал, что в каждой реплике должно быть 3 ноды мин, тут же ниже, не нужно и с 1 всё хорошо
Ну такойе, дядь. Для тестов ок 3ноды

Google
 
Старый
27.02.2018
05:55:16
Ну такойе, дядь. Для тестов ок 3ноды
жаль потом частенько и в прод потом переезжает

 
Max
27.02.2018
05:55:47
вот скажи как любям объяснять, что кроме репликейшен фактор 3 ничего использовать нельзя?
Аргуметируй, Хрыч. Монга говорит, что можно. Бизнес говорит, что можно. ты говоришь, что нет.

 
Zloy Dobriy
27.02.2018
05:56:00
жаль потом частенько и в прод потом переезжает
Ну тож такой е, если одмин допустил, выкатить такое прод, чтож, сам лох

 
Старый
27.02.2018
05:56:13
Ну тож такой е, если одмин допустил, выкатить такое прод, чтож, сам лох
вон выше прочти

 
Zloy Dobriy
27.02.2018
05:57:12
При мелких сетапах, в принципе, оно жизнеспособно

 
Старый
27.02.2018
05:57:57
Аргуметируй, Хрыч. Монга говорит, что можно. Бизнес говорит, что можно. ты говоришь, что нет.
ну вот когда данные будут неконсистентны в такой реплике, и потом по манде пойдут запросы, вот тогда я посмотрю как бизнес поставит тебя раком и во всём обвинит, ты не забывай главное правило бизнеса в снг, бизнес всегда прав и не виноват

 
Max
27.02.2018
05:58:56
ну вот когда данные будут неконсистентны в такой реплике, и потом по манде пойдут запросы, вот тогда я посмотрю как бизнес поставит тебя раком и во всём обвинит, ты не забывай главное правило бизнеса в снг, бизнес всегда прав и не виноват
почему данные будут неконсистентны? Потому что с одной из реплик случилась проблема и потом догоняться надо? Однозначно, это может быть проблемой. чтото ещё?

 
Zloy Dobriy
27.02.2018
06:00:00
почему данные будут неконсистентны? Потому что с одной из реплик случилась проблема и потом догоняться надо? Однозначно, это может быть проблемой. чтото ещё?
Как то не доставляло проблем, тамщнмта

 
Старый
27.02.2018
06:00:22
почему данные будут неконсистентны? Потому что с одной из реплик случилась проблема и потом догоняться надо? Однозначно, это может быть проблемой. чтото ещё?
потому что данные не каждые 3 мс синкаются, потеря данных при таком варианте очень велика, особенно, если расстояние между репликами большое

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

 
Max
27.02.2018
06:03:52
потому что данные не каждые 3 мс синкаются, потеря данных при таком варианте очень велика, особенно, если расстояние между репликами большое
У тебя много условностей. Что если я скажу что потерять данные в монге за час, например, гораздо приемлема (дешевле) чем держать +1 реплику?

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

 
Max
27.02.2018
06:05:44
дешевле для кого? ты работал на сервисах где 10 минут простоя пол з\п?
Давай не будем доходами меняться?

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

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

 
Старый
27.02.2018
06:07:09
потом приходишь в контору и думаешь, а как мне данные то с умерших баз забрать

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

 
Max
27.02.2018
06:08:12
а доходы тут причём:я к тому, что у анс любят хайлоад, круглосутчоную ответственность за сервисы и при этом железа минимум, а такие как ты провоцируют это
Хрыч, ты говоришь безапеляционно и не владея ситуацией. Вот и все.

 
Старый
27.02.2018
06:10:55
Хрыч, ты говоришь безапеляционно и не владея ситуацией. Вот и все.
возможно только 2 варианта, либо rack3, либо бумага о снятии с себя ответственности и что директора осознают все риски, соглашаются с потерей данных и простоем. - других вариантов быть не может

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

Google
 
Старый
27.02.2018
06:12:51
То есть с 3 железками в реплике простоев быть не может и в такой бумаге смысла Нет?
при такой конфигурации шансы ниже % на 98

 
Max
27.02.2018
06:15:34
Ниже. Но не 100%

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

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

 
Старый
27.02.2018
06:21:50
Вот многие с этими 98% согласны мириться. У всего своя цена, Хрыч
при такой теме хотя бы нет проблем с битыми данными, а вот при первом типе у меня была тема, когда в базе почему то оказывались битые данные, причём что монге что кассандре было похрен на это ровно до чтения.....

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

 
Max
27.02.2018
06:51:21
при такой теме хотя бы нет проблем с битыми данными, а вот при первом типе у меня была тема, когда в базе почему то оказывались битые данные, причём что монге что кассандре было похрен на это ровно до чтения.....
Страшные вещи ты говоришь а выяснилось, почему данные побились?

 
Старый
27.02.2018
06:52:11
Страшные вещи ты говоришь а выяснилось, почему данные побились?
8 нод, 10000 сообщений в сек вставка в каждую, не сказал бы что особо разберёшь

 
Max
27.02.2018
06:53:26
то есть при таком кейсе не важно - 2 сервера или 8, все равно данные бились

 
Artem
27.02.2018
06:54:46
))) мы в репликасете 5 серверов держим сейчас

 
Max
27.02.2018
06:56:05
Используете чтение с Secondary ?

 
Artem
27.02.2018
06:58:52
Используете чтение с Secondary ?
Да, в том числе

 
Nick
27.02.2018
08:29:01
Три сервера в разных странах планируется. Касаемо заливки данных подскажите, кто знает. Кто сталкивался с таким кейсом
а в чем необходимость держать в разных странах? и почему в вопросе фигурирует реплика а не шардинг?

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

 
Nick
27.02.2018
09:46:20
Т.е. Имелось ввиду тупо несколько дц

 
yopp
27.02.2018
09:53:46
звучит так - директор дебил хочет вложить 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/

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

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

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

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

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

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

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

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

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

 
Viktor
27.02.2018
11:38:29
Если архивации только смущает то есть смысл попробовать pigz или pbzip2 Они жмут по количеству процессоров.
Пока только скорость архивации да, но на перспективу тоже стоит подумать заранее

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

 
Artem
27.02.2018
11:41:13
снепшоты файловой системы, если надо бекапить большие объемы. думаю так, но лучше послушать спецов
ну в общем да) у нас нет возможности снапшотов, поэтому останавливаем балансировку кластера, и делаем копию бэкап нод рсинком

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

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

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

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

 
Artem
27.02.2018
11:46:50
да, по сути операция стартует одновременно на 12 серверах

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

 
Artem
27.02.2018
11:50:08
А у вас шард из скольки хостов состоит? 2 + 1 для бекапа ?
3+1, бэкап нода скрыта, с priority = 0

 
Max
27.02.2018
11:50:58
Понял, спасибо у меня 2 + арбитр не нравится, но тем не менее.

Google
 
Artem
27.02.2018
11:53:07
Понял, спасибо у меня 2 + арбитр не нравится, но тем не менее.
в моей практике мы арбитры не используем.

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

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

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

 
Max
27.02.2018
12:01:00
Понял а довливали данные сразу в шард или в монгос?

 
Artem
27.02.2018
12:01:42
Понял а довливали данные сразу в шард или в монгос?
извините, не понял вопроса

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

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

 
Max
27.02.2018
12:04:46
Понял Спасибо!

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

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

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

 
Max
27.02.2018
12:22:24
Да, понимаю, согласен

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

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

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

 
Dima
28.02.2018
19:23:16
Подскажите пару моментов с подключением монго?

Страница 197 из 342