Блог

Мы используем стек elasticsearch, который использует 3 узла для хранения данных журнала. Наша текущая конфигурация должна иметь индексы с 3 первичными и 1 репликой. (Мы только что ознакомились с этой конфигурацией и довольны производительностью, поэтому решили (пока) не тратить время на оптимизацию)

После отключения узла (предположим, полный диск) я заметил, что elasticsearch автоматически перераспределяет свои фрагменты в оставшиеся экземпляры — как и было объявлено.

Однако это увеличивает использование диска в оставшихся двух экземплярах, что делает его кандидатом на каскадный сбой.

Надежность данных журнала не имеет первостепенного значения. Поэтому я подумываю о перенастройке elasticsearch, чтобы не создавать новую реплику после отключения узла. Вместо этого он мог бы просто баллотироваться только на праймериз. Это означает, что после отключения одного узла мы будем работать без избыточности. Но это кажется лучше, чем каскадный провал. (Это единовременная стоимость)

Альтернативой было бы просто увеличить размер диска. (Это текущие расходы)

Мой вопрос

(Как) я могу настроить elasticsearch так, чтобы он не создавал новые реплики после сбоя первого узла? Или это считается плохой идеей, и канонический способ-просто увеличить емкость диска?

Восстановление баланса обходится дорого

Когда узел покидает кластер, на оставшихся узлах создается некоторая дополнительная нагрузка:

• Продвижение фрагмента реплики в первичный для замены любых первичных элементов, которые были на узле.
• Выделение сегментов реплик для замены отсутствующих реплик (при условии, что узлов достаточно).
• Перераспределение осколков равномерно по оставшимся узлам.

Это может привести к перемещению довольно большого количества данных.

Иногда узел отсутствует только в течение короткого периода времени. Полная перебалансировка в таком случае не оправдана. Чтобы учесть это, когда узел выходит из строя, elasticsearch немедленно перемещает сегмент реплики в основной для каждого основного, который находился на отсутствующем узле, но затем он ждет одну минуту, прежде чем создавать новые реплики, чтобы избежать ненужного копирования.

Только при необходимости восстановите баланс

Продолжительность этой задержки является компромиссом и поэтому может быть настроена. Более длительное ожидание означает меньшую вероятность бесполезного копирования, но также и большую вероятность простоя из-за снижения избыточности.

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

Я узнал об этом из официальной документации elasticsearch.