Не надо запутывать

репликасет состоит из 2 реплик на разных физ машинах. Одна дохнет, вторая берет инициативу

Еще раз, в этот момент шард становится уязвим, потому что осталась одна реплика

Скорость чтения упала 2 раза и база сдохла - разные вещи чуть

Да с чего вы взяли что скорость чтения изменится?

Когда у вас в рейд5 дохнет диск и идет восстановление- у вас тоже деградация будет

Нет.

Читать я с любой реплики могу

Еще раз, в этот момент шард становится уязвим, потому что осталась одна реплика

Вот это опасно

Поэтому 3

Читать я с любой реплики могу

Нет. Чтение в шарде задаётся выбором read preference

по-умолчанию у тебя primary

Поэтому 3

Опасно, но не так, как когда 1 =)

по-умолчанию у тебя primary

Ну, у меня по умному

Опасно, но не так, как когда 1 =)

Так уже один

Второй сдох

Так уже один

Подразумевается, что это ЧП и вы бежите восстанавливать сервер

У меня была ситуация, когда дохли 2 сервера с интервалом 15минут

по-умолчанию у тебя primary

Кто ж по умолчанию это делает:)

бывает

но не всегда можно сделать 3ю защиту каждой железки

Подразумевается, что это ЧП и вы бежите восстанавливать сервер

Сколько на это времени нужно?

Кто ж по умолчанию это делает:)

все, потому что чтение с secondary имеет ряд побочных эффектов

и не всегда это допустимо

Сколько на это времени нужно?

Если вы живете в Москве - то одно, если вы на северном полюсе и ближайший магазин за 5000км , то другое

но не всегда можно сделать 3ю защиту каждой железки

Поэтому вспоминаем про медленный last resort

что за вопрос

Сколько на это времени нужно?

время провижинга + время initial sync + время на догонку оплога

если есть бекап из oplogwindow то просто время на догонку оплога

Господа, ну это уже все детали, которых вагон

речь шла о минимальной конфигурации

Если вы живете в Москве - то одно, если вы на северном полюсе и ближайший магазин за 5000км , то другое

Ну, бывает разное. Заказчик продолбал мониторинг. Кончились инстансы в aws.

речь шла о минимальной конфигурации

7 серверов

речь шла о минимальной конфигурации

Минимальная для каких условий простоя?

3 конфига + 3 арбитра, 2 + 2 на шард

Вы что, для арбитра выделяете железный сервер???

Для ресерч можно и с журналом жить

я завидую вашему бюджету

Вы что, для арбитра выделяете железный сервер???

на конфиг серверах

Вы что, для арбитра выделяете железный сервер???

У меня вот уже давно нет железных

а рельный HA с нормальным бекапом

тьфу

короче реальный HA с резервированием это на каждый шард по 5 участников

короче реальный HA с резервированием это на каждый шард по 5 участников

Ну норм

3 реплики, 1 hidden member для бекапов, 1 арбитр

Арбитр на t2.nano жить можно, мне кажется

да хоть на rpi

да хоть на rpi

Угу

на самом деле арбитр может жить на любой реплике

главное чтоб математика была такая, что всегда нечётное количество участников останется

3 реплики, 1 hidden member для бекапов, 1 арбитр

Мне вот кажется hidden может быть третьей репликой

не может

Если только ты не хочешь с трёх читать

тогда HA страдает

тогда HA страдает

А какая модель угрозы?

потому что если у нас read preference: secondary отказ одного secondary приводит к отказу в обслужвании

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

hidden member не используется для выполнения запросов

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

Достаточное для нужного throughput + 1

вы сильно приувеличиваете влияние количества secondary на ёмкость кластера :)

Достаточное для нужного throughput + 1

Не считая hidden

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

вы сильно приувеличиваете влияние количества secondary на ёмкость кластера :)

Оно почти линейно увеличивает количество конкурентных чтений. Мы проверяли

А можно узнать, почему в репликасете из 3 серверов отказ 1 ведет к отказу в обслуживании?

А можно узнать, почему в репликасете из 3 серверов отказ 1 ведет к отказу в обслуживании?

я же там написал про "read preference: secondary"

а

сорри

и не из 3 , а из 2 :)

был P+S, P сдох, остался S который стал P и запросы с rp: s пошли по пизде

ERROR: S client not available

не, стоп.

Ну да, типа не осталось secondary, умираем

я же там написал про "read preference: secondary"

Вообще, это один из нерекомендуемых read preferences

Из двух понятно

Вообще, это один из нерекомендуемых read preferences

я бы сказал что это один из рекомендуемых, когда нужно читать с secondary

потому что secondaryPreferred имеет другие эффекты

Вы в дебри залезли =)

был у нас P+S, в P едет 30к qps/i, в S едет 10k qps/r

S упал, на P внезапно приезжает 10k qps/r и P тоже уезжает

S упал, на P внезапно приезжает 10k qps/r и P тоже уезжает

Натянуто

пффф

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

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

я бы сказал что это один из рекомендуемых, когда нужно читать с secondary

Монговцы его категорически не рекомендуют

инфа 100%

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

Монговцы его категорически не рекомендуют

монговцы вообще чтение с seconday не рекомендуют, в принципе

монговцы вообще чтение с seconday не рекомендуют, в принципе

Нет, secondary proffered вполне ок

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

когда у тебя кеш на запись и на чтение абсолютно разные

Нет, secondary proffered вполне ок

не ок

Именно по причине, что указана выше

нет

перечитайте документацию и асю почитайте

у чтения с secondary главная проблема в replication lag

вам никто не гарантирует актуальных данных

перечитайте документацию и асю почитайте

дай какой нибудь линк, а то у меня на работе есть любители этой хуйни, дам им почитать

Они на курсах явно говорят не используйте secondary only, кроме случаев когда вы точно знаете зачем)

и это не зависит от secondary или secondaryPreferred

вам никто не гарантирует актуальных данных

Причем тут актуальность?

Они на курсах явно говорят не используйте secondary only, кроме случаев когда вы точно знаете зачем)

А это касается всего. Просто нубов от совсем выстрелов в ногу надо оградить

вам никто не гарантирует актуальных данных

Кэп

Актуальность будет только при чтении с primary