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

Стоп, вот у меня есть три конфиг-сервера (не важно какой конфигурации) и три мощных сервера под кластер. Я их подготовил, но ещё не задействовал.

Сейчас на одном из них крутится база в single instance.

Там везде по 1 TB.

С шардами понятно - я буду добавлять новые шарды в кластер и данные (чанки) будут разбазариваться между ними по ключу.

А реплика, что делать с репликой? Она же будет бесконечно расти.

Или она тоже размазывается по шардам? Тогда зачем она нужна?

Я пока запускал без реплики, игрался на виртуалках.

Поэтому их нужно два?

Ну желательно...

Ну одного мало же?..

Кластера. Я кажется, оперирую немного другими терминами.

Я просто на практике не применял ещё, но мне очень скоро предстоит.

Вот изучаю, что придётся делать и разворачивать.

А так-то с MongoDB работаю очень давно, просто первый проект с большим набором данных.

Ну т.е. если я добавлю места в shard 1, то должен и добавить в shard 2 и в shard 3.

Я правильно же понимаю?

Я, кажется, что-то понял, в любом случае, большое спасибо за информацию.

На работе все данные с бекенда проекта в монге)

А мы аналитику на ней собираем.

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

Т.к если хоть одна из шард "ляжет", то не работает вся шардированная база

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

и тд

Поэтому каждая шарда должна представлять собой репликасет, т.е дублироваться на 2 разных серверах

Ну из 3 это уже прям если совсем надежность надо

Насчет медленный - не понял

и на разных контенентах, да =)

А то эти плиты, знаете... нет им доверия.

Каналы да. Днс лучше свой

Да ну не про то речь, в общем

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

Т.е 2 шарды в репликасете

Я это имел в виду, когда говорил, что монговский шардинг из коробки дохрена дорогой

Когда сдохнет репликасет или одна реплика?

1 реплика не страшно - секондари становится праймари и погнали

1 шард должен быть в репликасете, т.е быть на 2 физических разных железках

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

7 :)

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

тут всё нормально

Лол

Нет.

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

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

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

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

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

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

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

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

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

бывает

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

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

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

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

что за вопрос

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

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

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

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

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

7 серверов

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

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

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

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

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

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

тьфу

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

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

да хоть на rpi

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

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

не может

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

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

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

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

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

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