Комментарии 16
Сколько лет уже прошло, а кластеринг все равно ручной. Ну почему не пойти по стопам Elastic Search или Cassandra, например… А еще про шардинг не слова, там вообще сложность управления кластером увеличивается до небес.
Мне кажется, или это такое у них бизнес-решения для завлечения в MMS?
Рассказать одной машине о соседях это "ручной"? Боюсь представить какой тогда автоматический.
А представьте когда у вас десятки или сотни нод в кластере. А представьте когда на каждом сервере может быть по несколько инстансов монги (потому что оптимизируем диск под запись). А представьте когда волатильность кластера высокая (ноды приходят и уходят).
Да, верно, можно вспомнить про управление конфигурациями, но оно в данной ситуации выглядит для меня немного в качестве костыля, в то время как в мире других БД с кластеризацией / шардингом все гораздо более автоматизировано из коробки.
Автоматический, например, используя unicast / multicast. Задал имя кластера и все.
Или, например, используя механизмы service discovery, когда задаешь адрес сервиса где содержиться информация о кластере.
Плюс возможность выбирать мастера через кворум, можно сказать, стандарт в распределенных системах. В монге мaster/slave выбирается тоже кворумом после фелов,, но мастера обязаны назначить мы. Таким образом подход "cattle" превращается в "pets".
Это мои реалии. Но все же, давайте попробуем рассудить, может мои представления о кластеризации не реалистичны?
multicast удобная штука, но не всегда доступен.
unicast — заставит вас всё равно мейнтейнить список. в принципе для своего кластера сгенерил json, в котором описана топология.
+ есть ещё набор инструментов для развёртывания разных кластеров буквально кнопками, но он платный на сколько мне известно.
Я бы сказал, что у монги с этим всё не так уж и плохо.
Как выяснилось, у того же постгреса всё намного печальнее. Но там и типа базы другой, можно понять.
Разворачивать приходится все, я выбрал вариант Ansible, но раздражает что нужно решать кто primary. А дальше — съем бекапов (откуда? — как мы узнаем о том, кто primary а кто нет? — нужен тогда always-secondary? ). При включённом шардинге можно использовать mongos на самом сервере съёма бекаров. Работает ок. Но тогда гемор с воссоединением частей кластера ещё выше. короче хочу чтобы было master-master sharding/replication как в Elsstic Search, чтобы можно указать на члена кластерам и все работало само. Ведь, как видно сегодня, это возможно.
По набору инструментов — да, это тот самый MMS о котором я говорил. Это отдельный облачный продукт (не плохой). Но о чем я пытался сказать что это выглядит несколько низковато выносить такие вещи в платные продукты.
Но мы должны изначально задать Primary
Может, мы одно и тоже по-разному понимаем, но:
1. Ничего вы не должны.
2. Берём три сервера (будущая реплика). На любом делаем инициализацию.
3. И можно сразу скормить весь конфиг, не делая rs.addWhatEver().
4. Готово.
Возможно, не стоит делать инициализацию на будущем арбитре. Я, чтобы наверняка работало, подключался только к тем серверам, которые могут стать мастером в будущем. Этого достаточно.
У меня было так N серверов для master/slave + 1 сервер арбитер. Я подключался к первому попавшемуся из N и делал rs.conf, скармливая весь список. Реплика инициализируется и работает.
На каком узле делать?
Можно указать replicaset connection string в виде: rsName://host1:port1,host2:port2… — тогда драйвер сам разберётся. Но мне так делать не приходилось. Я восстановление обычно в роутер произвожу. Опять же с шардированным кластером не всегда так можно.
А про роутер можно по-подробнеее?
Сервера собираются в репликасет. Репликасеты собираются в общий кластер. Роутер — точка входа, балансер, прокся, вроде бы умел функции агрегации и возможно что-то от map reduce. Но тут боюсь соврать. Лучше почитать доки. Они реально неплохие. Можно потратить 6-8 часов и полностью разобраться что там у монги есть.
Установка и настройка MongoDB на Debian, а также ReplicaSet и пара других мелочей