Комментарии 13
Я так понял, у Вас арбитры располагаются на тех же серверах, где и сами реплика сеты для шардов? Это достаточно плохая практика, так как при обвале одного сервера отвалятся secondary и arbiter для одного из шардов, что приведёт к неработоспообности replica set (primary не увидит большинства членов replica set и уйдёт в secondary). Лучше положить арбитров на третий сервер, раз у Вас их три.
Нет, арбитры располагаются вместе с конфиг серверами и mongos.
Конечно же они отдельно от реплика сетов живут
Конечно же они отдельно от реплика сетов живут
Сразу прошу прощения если вопрос глупый, так как только начинаю изучать mongodb и ее возможности, а вопрос в следующем: какое количество 100% базы у вас получилось? т.е. например в кассандре при replication factory: 3 я понимаю что на 3 серверах хранится 100% базы, и если вылетит 1 сервер то на 2 других останется полная копия базы. Как я понимаю сейчас у вас имеется сейчас 2 шарда по 100% базы у которых имеется связь мастер-слейв или я не правильно понимаю? Спасибо.
Спасибо за статью.
Хорошей практикой является ставить mongos прокси на клиентские машины (Web, App сервер). Таким образом Вы уменьшаете количество хопов на 1 для Вашего клиента. Также я бы рекомендовал использовать порты отличные от стандартных 27017 для шардов, т.к. ненароком какой-нибудь невнимательный разработчик сможет к ним случайно подключиться и убить всю балансировку. Лучше смените их на 27020 и 27021 для каждого шарда и в дополнение поставьте по mongos на каждый из них, чтобы не задавали лишние вопросы (на случай если клиентская машина не имеет mongos).
В дополнение могу сказать что очень рекомендую использовать системы управления конфигурациями для кластеров, экономит время на правку init скриптов, а часто и на конфигурацию самого кластера. Например puppet.
Хорошей практикой является ставить mongos прокси на клиентские машины (Web, App сервер). Таким образом Вы уменьшаете количество хопов на 1 для Вашего клиента. Также я бы рекомендовал использовать порты отличные от стандартных 27017 для шардов, т.к. ненароком какой-нибудь невнимательный разработчик сможет к ним случайно подключиться и убить всю балансировку. Лучше смените их на 27020 и 27021 для каждого шарда и в дополнение поставьте по mongos на каждый из них, чтобы не задавали лишние вопросы (на случай если клиентская машина не имеет mongos).
В дополнение могу сказать что очень рекомендую использовать системы управления конфигурациями для кластеров, экономит время на правку init скриптов, а часто и на конфигурацию самого кластера. Например puppet.
> Для использования в production, каждый шард должен быть набором реплик (replicaSet).
Кто-нибудь может аргументировать вот это условие? Вижу его в официальной документации, но нигде нет подробного объяснения причин.
Иначе что получается.
Имеем жирный сервер с монгой. База медленно и верно грозит заполнить весь раздел, выделенный для нее. В память не влезают даже индексы, а поскольку монга работает только с замапленными данными, дисковая система целиком поглащена постоянным маппингом файов баз в память.
Логично — нужно размазывать данные по серверам, т.е шардить. Пускай для начала хотим разделить данные пополам, т.е 2 шарды. Но ведь у нас условие — каждая шарда должна быть реплика-сетом, т.е представлять из себя мимнимум 2 сервера!
Разместить реплику каждой шарды на сервере другой шарды ход красивый, когда на этих серверах хватает дисков под еще половину базы. И свободной памяти тоже.
Но это противоречит сути шардирования — мы как раз решаем задачу по уменьшению кол-ва данных на сервере, а тут нате вам еще данных? Очевидно не подходит. Значит, под реплики шард нужны отдельные сервера, по мощности не более, чем в 2 раза (ну, такие, условные «2 раза») уступающие боевым.
Итого!
Чтобы разделить данные «пополам», т.е создать 2 шарды, мне надо:
+1 сервер уровня существущего, а лучше мощнее под вторую боевую шарду.
+2 сервера чуть послабее под реплики шард.
+1-2 простеньких сервера под mongos и config.
Т.е хотим сделать шард — покупаем еще 4-5 серверов, да? Без претензий, просто интересно и актуально.
Кто-нибудь может аргументировать вот это условие? Вижу его в официальной документации, но нигде нет подробного объяснения причин.
Иначе что получается.
Имеем жирный сервер с монгой. База медленно и верно грозит заполнить весь раздел, выделенный для нее. В память не влезают даже индексы, а поскольку монга работает только с замапленными данными, дисковая система целиком поглащена постоянным маппингом файов баз в память.
Логично — нужно размазывать данные по серверам, т.е шардить. Пускай для начала хотим разделить данные пополам, т.е 2 шарды. Но ведь у нас условие — каждая шарда должна быть реплика-сетом, т.е представлять из себя мимнимум 2 сервера!
Разместить реплику каждой шарды на сервере другой шарды ход красивый, когда на этих серверах хватает дисков под еще половину базы. И свободной памяти тоже.
Но это противоречит сути шардирования — мы как раз решаем задачу по уменьшению кол-ва данных на сервере, а тут нате вам еще данных? Очевидно не подходит. Значит, под реплики шард нужны отдельные сервера, по мощности не более, чем в 2 раза (ну, такие, условные «2 раза») уступающие боевым.
Итого!
Чтобы разделить данные «пополам», т.е создать 2 шарды, мне надо:
+1 сервер уровня существущего, а лучше мощнее под вторую боевую шарду.
+2 сервера чуть послабее под реплики шард.
+1-2 простеньких сервера под mongos и config.
Т.е хотим сделать шард — покупаем еще 4-5 серверов, да? Без претензий, просто интересно и актуально.
Насколько я понимаю, совет создавать реплики для шардов исходят из того что чем на большее количество шард вы «размазываете» свои данные тем выше вероятность потерять один из серверов. И если это был единственный сервер в шарде то это часть данных пропадет и работаспособность всего кластера будет нарушена.
Арбитр были как раз придуманы для того чтобы можно было все же не три сервера в реплике держать а два. А арбитр по сути еще один член реплики без данных но с правом голоса (типа заглушка-пустышка :) )
Арбитр были как раз придуманы для того чтобы можно было все же не три сервера в реплике держать а два. А арбитр по сути еще один член реплики без данных но с правом голоса (типа заглушка-пустышка :) )
config серверов на данный момент может быть максимум 3.
mongos можно запускать на сервере приложений (там где ваше приложение работает).
Получается что минимально рекомендуемый комплект для очередного шарда — 2 сервера (арбитра можно где-то запустить на стороне, может быть даже собрать их все на один сервер, пусть развлекаются).
mongos можно запускать на сервере приложений (там где ваше приложение работает).
Получается что минимально рекомендуемый комплект для очередного шарда — 2 сервера (арбитра можно где-то запустить на стороне, может быть даже собрать их все на один сервер, пусть развлекаются).
Спасибо.
Смысл арбитров понятен — помощь при голосовании.
Загвоздка еще в том, что при шардировании, видимо, нельзя выполнять бэкап базы снапшотами ФС, т.к. снапшоты разных шард не будут согласованы. Либо на время создания снапшота нужно остановить всю запись во всех шардах, снапшотить, и включать обратно. Вроде возможно, хотя вернет только данные на момент бэкапа, никакого availability… Зато всего 2 мощных сервера надо.
А согласно рекомендациям всё получается как я предположил: для познания радостей шардирования мне надо докупить 3 хороших сервера + 1 простенький под конфиг.
А это хороших тысяч 400-500 р. Просто это стоит учитывать тем, кто любит шардинг в монге, но никогда его не поднимал на более-менее большой базе :)
Смысл арбитров понятен — помощь при голосовании.
Загвоздка еще в том, что при шардировании, видимо, нельзя выполнять бэкап базы снапшотами ФС, т.к. снапшоты разных шард не будут согласованы. Либо на время создания снапшота нужно остановить всю запись во всех шардах, снапшотить, и включать обратно. Вроде возможно, хотя вернет только данные на момент бэкапа, никакого availability… Зато всего 2 мощных сервера надо.
А согласно рекомендациям всё получается как я предположил: для познания радостей шардирования мне надо докупить 3 хороших сервера + 1 простенький под конфиг.
А это хороших тысяч 400-500 р. Просто это стоит учитывать тем, кто любит шардинг в монге, но никогда его не поднимал на более-менее большой базе :)
Да, на шардах можно полностью сделать снапшот только если остановить запись. Иначе будет плюс-минус… Но, допустим, как показывает один из примеров (use case), вы используете шардинг для «архивирования» данных… То есть свежие данные на мощном сервере, «прошлогодние» данные на втором «архивном» более слабом сервере.
Данные на архивном серевере почти не меняются. То есть никакой проблемы с рассогласованностью снапшотов не будет.
Данные на архивном серевере почти не меняются. То есть никакой проблемы с рассогласованностью снапшотов не будет.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
MongoDB Sharded Cluster на Centos 6.5