Уменьшение кластера Elasticsearch
Elasticsearch должен быть устойчивым к сбоям отдельных узлов. Он достигает этой устойчивости, считая обновления состояния кластера успешными после того, как кворум узлов принял их. Кворум - это тщательно отобранное подмножество основных узлов в кластере.
Кворумы должны тщательно выбираться, чтобы кластер не мог выбрать двух независимых мастеров, которые принимают противоречивые решения, что в конечном итоге приводит к потере данных. узнать подробнее ..
Подготовка Перед уменьшением
- Создайте резервную копию кластера, чтобы что-то восстановить, если что-то go неправильно по линии.
- Проверьте с минимальной конфигурацией мастер-узлов минимальные мастер-узлы в соответствии с
- Остановите все записи в ваш кластер, так как это не будет безопасно для восстановления после сбоя после нашего уменьшения, но не обязательно если все пойдет хорошо.
- Убедитесь, что вы не перегружаете кластер, сделав его слишком маленьким дисковым пространством и памятью, иначе кластер станет доступным только для чтения с Низким водяным знаком диска .
Уменьшите коэффициент репликации индекса до 1, чтобы сэкономить пространство и ускорить перемещение сегментов во время масштабирования, поскольку необходимо создавать и перемещать меньшее количество фрагментов. Кроме того, это экономит много места в дублированных данных.
curl -X PUT "localhost:9200/twitter/_settings?pretty" -H 'Content-Type: application/json' -d'
{
"index" : {
"number_of_replicas" : 1
}
}
'
Изящно перебалансируйте кластер перед началом масштабирования.
Cluster необходимо быть здоровым с зеленым статусом, проверьте с shards и status
Health
curl -X GET "localhost:9200/_cluster/health?pretty"
Ожидаемый результат
{
"cluster_name" : "\"es-data-cluster\"",
"status" : "green",
"timed_out" : false,
"number_of_nodes" : 1,
"number_of_data_nodes" : 1,
"active_primary_shards" : 0,
"active_shards" : 0,
"relocating_shards" : 0,
"initializing_shards" : 0,
"unassigned_shards" : 0,
"delayed_unassigned_shards" : 0,
"number_of_pending_tasks" : 0,
"number_of_in_flight_fetch" : 0,
"task_max_waiting_in_queue_millis" : 0,
"active_shards_percent_as_number" : 100.0
}
Осколки
curl -X GET "localhost:9200/_cat/shards"
Ожидаемый результат
twitter 2 p STARTED 0 0b 172.18.0.2 es-node
twitter 1 p STARTED 0 0b 172.18.0.2 es-node
twitter 0 p STARTED 0 230b 172.18.0.2 es-node
Если состояние кластера равно green, а все сегменты STARTED, тогда вы можете получить go с уменьшением.
Шаги для уменьшения
Удалите один узел данных - кластер будет go в желтом состоянии. Теперь посмотрите журналы кластера
- , проверку
- с
STARTED и UNASSIGNED осколками
Если в журналах указано Marking shards as stale это означает, что осколок больше не доступен для назначения и будет удален. Затем встроенные возможности эластичного поиска начинают перебалансировать Осколки.
curl -X GET "localhost:9200/_cluster/allocation/explain?pretty"
Эта команда предоставит подробное объяснение распределения осколков в кластере.
Подождите, пока зеленый - тогда кластер скопировал утерянные осколки.
Состояние кластера составляет red, поэтому имеется хотя бы один неназначенный первичный осколок. Вы должны сосредоточиться на неназначенном кластере.