%24 вроде бы
Если уже с %24 выдаёт ошибку, то в чем тогда может быть проблема?
Anonymous
Anonymous
Roman
mongoose
Если память не изменяет, можно креды передать вторым аргументом в connect
mongoose.connect(url, {user: 'username', pass: 'pssword$'}, callback);
И не придется делать %24
Anonymous
Anonymous
Если память не изменяет, можно креды передать вторым аргументом в connect
mongoose.connect(url, {user: 'username', pass: 'pssword$'}, callback);
И не придется делать %24
В общем, с этой хней я разобрался. Я не помню, нужен ли пароль для кластера(атлас) отдельно ?
Roman
В общем, с этой хней я разобрался. Я не помню, нужен ли пароль для кластера(атлас) отдельно ?
Что Вы имеете ввиду под "отдельно"?
Алишер Абдуллаев
Алишер Абдуллаев
Нужно записать в дефоулт значение того идентификатора выше
Egor
Доброе утро. Есть два сервера в репликасете + арбитр. a.localdomain, b.localdomain. Нужно потушить сервер a.localdomain (тех.работы). Может ли привести к чему-то плохому перенос ип a.localdomain на b.localdomain? Так как крайне нежелательно переписывать апликейшны?
Bandikoot
Bandikoot
подниму новый. или чревато еще и потерями данных?
вам бы в тестовой среде такую последовательность действий отработать сначала. про потерю наверняка не скажу
Bandikoot
подниму новый. или чревато еще и потерями данных?
ну т.е. допустим вы сделаете rs.stepDown, мастер уйдёт на ноду b, это вполне ок. но смена ip почти наверняка всю конфигурацию rs порушит.
а какой коннект вы в аппликухах используете? мб это и вовсе не нужно
Egor
ну т.е. допустим вы сделаете rs.stepDown, мастер уйдёт на ноду b, это вполне ок. но смена ip почти наверняка всю конфигурацию rs порушит.
а какой коннект вы в аппликухах используете? мб это и вовсе не нужно
самый херовый вариант. конект на ноду, не на реплику
Bandikoot
самый херовый вариант. конект на ноду, не на реплику
это печально. при коннекте на реплику драйвер монги вашего яп сам бы разобрался, что мастер переключился. ну, чуть ошибками посыпал бы из-за таймаута и затем разобрался
Egor
это печально. при коннекте на реплику драйвер монги вашего яп сам бы разобрался, что мастер переключился. ну, чуть ошибками посыпал бы из-за таймаута и затем разобрался
ага, скорее всего буду пинать прогеров, чтоб переписали на реплику
Bandikoot
там не mongouri, а что-то специфичное?
Egor
просто реплику сет поднял уже после того как были апп написаны и подключены.
Egor
и праймари не менял
Bandikoot
не в курсе.
имхо, тут тогда чуть правильнее будет вывести вторую ноду из реплика-сета, затем перебросить ip с ноды A и поднять B с новым ip как single instance. какой-то даунтайм будет, но хоть не на живую RS резать и вроде не должно быть побочных эффектов. лучше, конечно, всё равно сперва протестировать
ну и затем собирать RS обратно на основе второй ноды. и коннект в прикладе менять asap
Bandikoot
подниму новый. или чревато еще и потерями данных?
а данные стоит забэкапить сперва, на всякий случай
V
Ребят смотрю я тут курс mongodb m103
и там в общем в разделе replication
этот инженер советует пытаться обходить использование arbiters (хотя я не понял до конца всю локику выборов primary ) может поможете до-понять этот механизм
Ivan
А точно он советует обходить?
Ivan
В том то и прикол что арбитр имеет голос и вместе с ним легче и быстрее выбрать примари
V
https://prnt.sc/mo1ohp
V
avoid arbiters ( и говорит что ипользовать то можно но он говорит что использование их это Частные случаи)
V
даже восклицательный знак поставлен !
V
вот вам еще интерактивчик
V
http://thesecretlivesofdata.com/raft/
https://raft.github.io/
AstraSerg
Может имеется ввиду эта конкретная конфигурация?
V
Может имеется ввиду эта конкретная конфигурация?
цитирую
- if for some reason we cant’t or don’t want to have a data bearing node but still be able to failover beetwen nodes we can add a replicaset member as an arbiter . That said, arbiters do cause significant consistency issues in disctibuted data systems. So WE advise you use them with care. In my personal view the usage of arbiters is a very sensitive and potenially harmful option in many deployments. So I idly discourage the usage of arbiters. Avoid arbiters!
V
и предлагает сразу hidden or delayed ноды использовать
V
слышали о таких?
V
я вот только первый раз
AstraSerg
и предлагает сразу hidden or delayed ноды использовать
Да, конечно. Хидден для бакапов удобно юзать. А на счет арбитров странно. Подождем коммента @dd_bb
V
ну там еще сказали что 50 нод это ограничение и только 7 чтоли могут голосовать
AstraSerg
ну там еще сказали что 50 нод это ограничение и только 7 чтоли могут голосовать
Так и есть https://docs.mongodb.com/manual/core/replica-set-elections/#non-voting-members
V
V
даже выделили таким образом
AstraSerg
Да, очевидно, что моё предположение не верно и это странно.
Nick
V
ну вообще "всегда использовать арбитр" плохой ответ банально изза простейшего контрпримера, когда у вас достаточно ресурсов для трех нод с данными
ну аргумент хорош но кажется не совсем основательный чтобы на столько выделить что использование arbiters в не частых случаях
но я вот все равно не могу понять почему 4 ноды например не могут договориться (без арбитра) а то что они не могут договорится когда один арбитр мне тем более не понятно
Nick
могут договориться, для того чтобы договориться нужно просто большинство. Большинство считается просто ceil((N+1)/2)
дляваших 4 нод это будет 3, .е. вы сможете пережить только падение одной (4-3) ноды. А вот добавление арбитра, котоырй не жрет места позволит уже пережить падение двух нод (5-3), т.к. позволит обеспечить нормальное большинство
V
почему нельзя получить меньшее количество голосов
V
например если 4 ноды почему 2 голоса одной ноде и по одному другой
Nick
сплит брейн
V
а в чем сплит если у одной ноды все равно 2 голоса а у остальных 1
V
да и тем более там ведь не одновременно это происходит
V
сплит брейн
ладно увидел я уже пример raft split brain но я так понял он все равно может сам со временем разрешиться ? у когото были примеры длительный split?
Nick
сплит брейн в общем случае не разрешим
Nick
я может чегото не знаю, но как будет разрешатсья сплит брейн в случае 6 = 3 + 3, где каждые 3 в своем полушарии и с каждыми работают свои клиенты? как кластер решит какая из частей должна продолжить работать?
V
ты имеешь ввиду что в данном случае сложно выбрать мастера так как задержка между сетями будет большая ?
Nick
связи вообще нет
V
аааа
V
ну
Nick
вообещм если бы был способ разрешить проблему сплит брейна, то ее бы не было)
V
получается в данном случае даже мастер не выбирится ?
Nick
да
Nick
да
V
ну в общем все равно получается твой вариант не разрешим до конца если например будет 7 нод например в одном регионе 3 во втором 4 то при потери связи , мастера тоже нельзя выбрать
Nick
вы можете даже приоритеты задать, но это не повлияет на количество голосов, по крайней мере в монге
Nick
можно - там где 4 там большинство
Nick
эта часть кластера продолжить работать после выборов, если вдруг лидер остался в части с 3 нодами
V
получается split brain это больше между сетевая проблема в локальной или доступной сети ему сложно возникнуть ? @yatoba
Nick
легко, вот вам надо обновить монгу, железо, просто чтото померло - обычный сценарий выхода из строя одной ноды
Nick
а не это не про сплит брейн))
Nick
да в локалке как правило все хорошо, если нет чегото заумного в плане маршрутизации, то вообще проблема из разряда мифических
yopp
yopp
Перенастройте с использованием replica set seed list, или если есть возможность вообще в srv запись положить сидлист
yopp
В остальном, ничего страшного произойти не должно. Так как останется большинство, то после степдауна обслуживаемой ноды у вас будет новый праймари. Клиенты переподключатся чтоб обновить cluster view и если у нового парацмари ресурсов как у обслуживаемого, то разницы быть не должно.
В момент переподключения какие-то запросы могут завершится ошибкой.