LINUX.ORG.RU
ФорумAdmin

Elasticsearch мастер-слайв как?

 


0

0

Здравствуйте. Подскажите пожалуйста, нужно реализовать следующую схему: Мастер работает в режиме чтение-запись. Слейв работает в режиме чтения (обновление происходит автоматически с мастера). Т.е. классическая схема для MySQL с репликацией. Возможно настроить тоже самое для эластика, только чтобы слейвы не были жестко привязаны, т.е. можно было их временно отключать друг от друга. Т.е. нужна возможность автономной работы. Любой из слейвов или мастер, может быть недоступен некоторое время.


Вы сейчас описываете «изкоробочную» схему работы эластика, ничего придумывать не нужно - поднимаете нужное кол-во нод в кластере, настраиваете кол-во шард в зависимости от объема данных и реплик по количеству нод в кластере, кто там мастер ноды выберут сами, вы можете обращаться к любой из нод (обычно ставят еще несколько нод без данных, которые могут быть только мастерами, а ноды с данными мастерами быть не могут, потому что data-нод может быть больше, чем мастеров).

micronekodesu ★★ ()
Ответ на: комментарий от micronekodesu

И всё же, схему которую хотелось бы получить, невозможно сделать. Т.к. по Вашим словам мастер нода не может содержать данные. А в классической схеме мастер-слейв у MySQL у мастера есть данные. Шардить данные вообще не нужно, нужна именно реплика. Да и «кто там мастер ноды выберут сами» не совсем хочется.

Правильно ли я понимаю, что для реализации данной схемы, мне необходимо поднять три ноды в режиме data-нода и одну в режиме мастера. На одну ноду направляю запросы чтение-запись, а а другие только запись. А ноду мастер, вообще не трогаю. Всё верно? И какая в этом случае нагрузка будет на мастер ноду, т.е. что она будет делать? Хочется понять какие машины для этого отводить. А ещё что будет, если мастер нода отключится от сети, а data-ноды продолжат работать?

clgs ()
Ответ на: комментарий от clgs

Т.к. по Вашим словам мастер нода не может содержать данные.

Нет, не так поняли (ну точнее я не совсем внятно это написал) - мастер-нода может не содержать данные (и data-нода может никогда не выбираться мастером). Но также одна и та же нода может быть и мастером, и хранить данные одновременно, и по дефолту вообще так и есть. Просто мастер-ноды управляют кластером (создают-удаляют индексы, смотрят какие шарды на каких серверах), так что нет смысла делать их «жирными», но они должны быть стабильными, потому что без мастеров кластер развалится, а в случае падения data-ноды у вас есть реплики.

Да и «кто там мастер ноды выберут сами» не совсем хочется.

Ну, так работает эластик - ноды в кластере договариваются кто будет мастером (из тех кто может им быть), вы можете слать запросы на любую ноду, ноды в кластере знают о существовании друг друга и форвардят клиентские запросы между собой, но управлять индексами будет только один мастер.

Правильно ли я понимаю, что для реализации данной схемы, мне необходимо поднять три ноды в режиме data-нода и одну в режиме мастера.

Для реализации той схемы что вы описали в стартовом сообщении вам достаточно просто развернуть эластик и настроить количество реплик по количеству машин, не задумываясь при этом о том кто мастер а кто нет, кластер сам ваш запрос распределит куда нужно, вы можете обращаться на любую ноду.

Для того чтоб понять какой мощности нужны машины - разверните тестовую ноду «как обычно», шлите туда тестовые данные, потихоньку увеличивая их объем. Для контроля состояния я использую cerebro (позволяет управлять кластером) и prometheus+grafana (рисует графики о том что происходит внутри jvm и кластера). Не зная объема ваших данных и что именно вы с ними будете делать сложно сказать точнее.

micronekodesu ★★ ()
Ответ на: комментарий от micronekodesu

Спасибо за развернутый ответ. Задача в общем простая, есть сайт. Скрипты генерирующие публичную часть находятся на двух серверах, на них же развернут эластик на чтение. И есть ещё один сервер, который выполняет бизнес логику, на нем уже эластик работающий в режиме чтение-запись. Исключать ситуацию когда упадёт какой либо сервер нельзя, поэтому и требуется чтобы при падении любого из серверов, остальные продолжали работу. По объёму сейчас суммарно около 90 миллионов записей весом 130 Гигабайт. Естественно это всё не в одной «таблице» и выборки есть как по ключу, так и по нескольким параметрам.

clgs ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.