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

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

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

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

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

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

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

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

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

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

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

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