Здравствуйте,
После настройки реплики
MASTER -> SLAVE на
POSTGRES оказалось, что есть необходимость в создании, подобного типа репликации и для
ELASTICSEARCH.
Немного погуглив узнал что
ELASTICSEARCH поддерживает только кластреную мультимастер репликацию (
MASTER - MASTER ELIGIBLE).
Почему мне не подходит способ через создание снэпшотов.
Но для подобия
MASTER -> SLAVE на
POSTGRES можно испльзовать
механизм создания снэпшотов. С переодическим созданием/востановлением снэпшота через крон. Но как я понял для такой схемы необходимо:
- создать снэпшот,
- остановить ELASTICSEARCH на ноде "SLAVE" (и в этот момент он не доступен для клиента)
- востановить снэпшот
- запустить ELASTICSEARCH
Данная схема не подходит, так как необходима постоянная доступность ELASTICSEARCH для приложения.
Значит наиболее подходящим в данном случае будет способ предложеный командой
ELASTIC:
MASTER - MASTER ELIGIBLE
При добавлении новой ноды в кластер
MASTER - MASTER ELIGIBLE - необходимо на всех существующих нодах включая мастер через
ANSIBLE запустить
следующее- добавить в hosts и elasticsearch.yml запись нового хоста
- изменить правила firewall
- перезагрузить сервис elasticsearch
Так же есть вероятность смены IP ноды (специфика проэкта), что требует создание дополнительного плэйбука с теми же тасками.
Такие манипуляции вызывают определенные опасения:
1) Не вызовет ли это
split brain если что-то пойдет "не так" (временная недоступность IP одной из нод)
2)
Краш всего кластера после перезапуска ELASTICSEARCH (временная недоступность IP одной из нод)
1 )Как "предупредить" данные проблемы (см. выше)?
2) Может есть способ более "изящный"? (на мой взгяд у Postgres он более удобен не смотря на единственную точку отказа).
Нашел
туториал, но вопросы те же, плюс добавился дополнительный -
3) Надежен ли tinc, что может вызвать его падение, получится ли настроить его в OPENVZ контейнере? 
Средний
Сложный
Средний
