# 7.3.2 и потеря мастера **URL:** \ **Category:** Вопросы на русском языке\ **Created:** [September 26, 2019, 12:24pm UTC](https://discuss.elastic.co/t/7-3-2/201228 "2019-09-26T12:24:20Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Denis\_Lamanov](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/denis_lamanov/32/13111_2.png) [@Denis\_Lamanov](https://discuss.elastic.co/u/Denis_Lamanov)\ **Post date:** [September 26, 2019, 12:24pm UTC](https://discuss.elastic.co/t/7-3-2/201228/1 "2019-09-26T12:24:20Z")
Наконец-то обновились до 7.3.2 с 6.8.2 Индексы поднялись и при минимальной нагрузке одна нода теряет выбранный мастер и соответственно вылетела из кластера через пару минут присоединившись При этом проблем с железом и сетью нет У нас 7 нод и каждая node.master: true Логи с момента потери: [https://gist.github.com/UkrZilla/71d7da7a83c1755e8ec77a9b54baf861](https://gist.github.com/UkrZilla/71d7da7a83c1755e8ec77a9b54baf861) Ещё в процессе нормальной работы вижу в логах на всех нодах через каждую минуту INFO сообщение: waiting for elected master node... ---
**Author:** ![Denis\_Lamanov](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/denis_lamanov/32/13111_2.png) [@Denis\_Lamanov](https://discuss.elastic.co/u/Denis_Lamanov)\ **Post date:** [September 26, 2019, 12:30pm UTC](https://discuss.elastic.co/t/7-3-2/201228/2 "2019-09-26T12:30:22Z")
В логах выбранного мастера вижу как он периодически удаляет ноду, а потом присоединяет: > ---
**Author:** ![Igor\_Motov](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/igor_motov/32/45193_2.png) [@Igor\_Motov](https://discuss.elastic.co/u/Igor_Motov)\ **Post date:** [September 26, 2019, 1:36pm UTC](https://discuss.elastic.co/t/7-3-2/201228/3 "2019-09-26T13:36:26Z")
Свапимся опять? ---
**Author:** ![Denis\_Lamanov](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/denis_lamanov/32/13111_2.png) [@Denis\_Lamanov](https://discuss.elastic.co/u/Denis_Lamanov)\ **Post date:** [September 26, 2019, 1:38pm UTC](https://discuss.elastic.co/t/7-3-2/201228/4 "2019-09-26T13:38:40Z")
Вы про swapping? Нет. Памяти свободной сейчас 90% ---
**Author:** ![Igor\_Motov](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/igor_motov/32/45193_2.png) [@Igor\_Motov](https://discuss.elastic.co/u/Igor_Motov)\ **Post date:** [September 26, 2019, 1:47pm UTC](https://discuss.elastic.co/t/7-3-2/201228/5 "2019-09-26T13:47:11Z")
Надо разобраться, почему вот это происходит. ```auto [2019-09-26T11:54:31,820][INFO][o.e.m.j.JvmGcMonitorService] [node-00] [gc][3308] overhead, spent [273ms] collecting in the last [1s] [2019-09-26T11:54:53,827][INFO][o.e.m.j.JvmGcMonitorService] [node-00] [gc][3330] overhead, spent [259ms] collecting in the last [1s] [2019-09-26T11:54:54,828][INFO][o.e.m.j.JvmGcMonitorService] [node-00] [gc][3331] overhead, spent [362ms] collecting in the last [1s] ``` Такое обычно бывает, когда процесс elasticsearch уходит в swap, либо когда процессор дросселируется виртуальной машиной или когда у java кучи не хватает. 30% времени в GC - это не здоровая ситуация. ---
**Author:** ![Denis\_Lamanov](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/denis_lamanov/32/13111_2.png) [@Denis\_Lamanov](https://discuss.elastic.co/u/Denis_Lamanov)\ **Post date:** [September 26, 2019, 1:49pm UTC](https://discuss.elastic.co/t/7-3-2/201228/6 "2019-09-26T13:49:01Z")
Кстати, при обновлении я удалил Java 11 и использую бандлед 12 которая идёт в поставке с 7.3.2 Может попробовать вернуть 11? ---
**Author:** ![Denis\_Lamanov](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/denis_lamanov/32/13111_2.png) [@Denis\_Lamanov](https://discuss.elastic.co/u/Denis_Lamanov)\ **Post date:** [September 26, 2019, 2:11pm UTC](https://discuss.elastic.co/t/7-3-2/201228/7 "2019-09-26T14:11:27Z")
Ещё у нас каждая дата нода является и мастером. Есть виртуалка которая не дата и не мастер, для чтения дашбоардов. Виртуалка стабильна. Может сделать мастером только виртуалку и тогда проблемы дата нод не будут влиять на выборы? ---
**Author:** ![Igor\_Motov](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/igor_motov/32/45193_2.png) [@Igor\_Motov](https://discuss.elastic.co/u/Igor_Motov)\ **Post date:** [September 26, 2019, 2:33pm UTC](https://discuss.elastic.co/t/7-3-2/201228/8 "2019-09-26T14:33:29Z")
Надо разобраться почему ваша виртуалка не дает процессу java нормально работать, все остальное - временные решения. ---
**Author:** ![Denis\_Lamanov](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/denis_lamanov/32/13111_2.png) [@Denis\_Lamanov](https://discuss.elastic.co/u/Denis_Lamanov)\ **Post date:** [September 26, 2019, 4:22pm UTC](https://discuss.elastic.co/t/7-3-2/201228/9 "2019-09-26T16:22:05Z")
Так, похоже проблема найдена: во всех случаях удаления ноды от мастера была причина: `reason: ApplyCommitRequest` Насколько я понял по форуму это повреждённый индекс или transaction log. После установки 7.3 я увидел старые индексы за март, которые 6.8 не показывал. Удалив их всё нормализовалось и ноды перестали отлетать. Объясняет ли это проблему в GC? ---
**Author:** ![Igor\_Motov](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/igor_motov/32/45193_2.png) [@Igor\_Motov](https://discuss.elastic.co/u/Igor_Motov)\ **Post date:** [September 26, 2019, 6:21pm UTC](https://discuss.elastic.co/t/7-3-2/201228/10 "2019-09-26T18:21:53Z")
Вы, скорее всего, прочитали про [flush](https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules-translog.html), он же Lucene commit. ApplyCommitRequest - это часть процесса [публикации состояния кластера](https://www.elastic.co/guide/en/elasticsearch/reference/7.3/cluster-state-publishing.html) на все ноды. В результате длинных пауз в результате блокировки во время сборки мусора, ноды не подтверждали во время новое состояние кластера, что и вызывало сбои. Индексы, которые появились - это так называемые dangling indices. Они могли вызывать дополнительную нагрузку на кластер. Если у вас сообщения про GC после этого исчезли - то все нормально, если они все еще появляются - то ваше спокойствие временное и проблемы вернутся как только вы увеличите нагрузку на кластер. ---
**Author:** ![Denis\_Lamanov](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/denis_lamanov/32/13111_2.png) [@Denis\_Lamanov](https://discuss.elastic.co/u/Denis_Lamanov)\ **Post date:** [September 29, 2019, 5:40pm UTC](https://discuss.elastic.co/t/7-3-2/201228/11 "2019-09-29T17:40:38Z")
Всё нормализовалось. Больше такого не наблюдали ---
**Author:** ![Denis\_Lamanov](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/denis_lamanov/32/13111_2.png) [@Denis\_Lamanov](https://discuss.elastic.co/u/Denis_Lamanov)\ **Post date:** [October 11, 2019, 6:31pm UTC](https://discuss.elastic.co/t/7-3-2/201228/12 "2019-10-11T18:31:25Z")
Обновились на 7.4. В плане производительности стало лучше. Но мастер всё таки раз в 2-3 дня отваливается. При этом никакой резкой нагрузки, всплеска или видимых причин не видно. Вот что в этот момент в логах дата нод которые с ролью мастера, но не были в этот момент мастером: > В этот момент в логах избранного мастера: > Что можете посоветовать? На версиях до 7-ки такого не было ---
**Author:** ![Denis\_Lamanov](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/denis_lamanov/32/13111_2.png) [@Denis\_Lamanov](https://discuss.elastic.co/u/Denis_Lamanov)\ **Post date:** [October 12, 2019, 4:09pm UTC](https://discuss.elastic.co/t/7-3-2/201228/13 "2019-10-12T16:09:24Z")
Судя по логам т.к. у нас не SSD диски, то обновление мета-информации о каждоом индексе(которых у нас больше чем 1000 на ноду) на диске иногда превышает `cluster.publish.timeout` ([Rolling upgrade problem from 6.8 to 7.1.1](https://discuss.elastic.co/t/rolling-upgrade-problem-from-6-8-to-7-1-1/186571/14)) Собственно этот механизм, судя по документации, ввели в 7-ке [https://www.elastic.co/guide/en/elasticsearch/reference/7.4/cluster-state-publishing.html](https://www.elastic.co/guide/en/elasticsearch/reference/7.4/cluster-state-publishing.html) ---
**Author:** ![Igor\_Motov](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/igor_motov/32/45193_2.png) [@Igor\_Motov](https://discuss.elastic.co/u/Igor_Motov)\ **Post date:** [October 13, 2019, 9:47am UTC](https://discuss.elastic.co/t/7-3-2/201228/14 "2019-10-13T09:47:32Z")
> [@Igor\_Motov](#): > > Если у вас сообщения про GC после этого исчезли - то все нормально, если они все еще появляются - то ваше спокойствие временное и проблемы вернутся У вас ноду залипают не только на state publishing, но и не очень легких запросов вроде `internal:coordination/fault_detection/follower_check`. Другими словами, некоторые ноды перестают отвечать на любые запросы по 15-40 секунд. Отсюда и все проблемы. Почему это происходит, я сказать затрудняюсь. Может VM глючит, может сеть. Когда такие проблемы происходит, вы можете попробовать на машину залогиниться и посмотреть - а машина то сама отзывается, или все остальное тоже тормозит. ---
**Author:** ![Denis\_Lamanov](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/denis_lamanov/32/13111_2.png) [@Denis\_Lamanov](https://discuss.elastic.co/u/Denis_Lamanov)\ **Post date:** [October 13, 2019, 9:51am UTC](https://discuss.elastic.co/t/7-3-2/201228/15 "2019-10-13T09:51:48Z")
Да, логинился в это время на проблемную ноду - ничего не тормозит. Всё в нормальном режиме: сеть не пропадала, диск и процессор не нагружены Пока что подкрутил так: `cluster.join.timeout: 180s` `cluster.publish.timeout: 180s` `cluster.follower_lag.timeout: 180s` Но ещё заметил, что бывает часто когда нода отваливается от мастера и в вечном цикле подключается и сразу же отключается пока не перезагрузишь её ---
**Author:** ![Denis\_Lamanov](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/denis_lamanov/32/13111_2.png) [@Denis\_Lamanov](https://discuss.elastic.co/u/Denis_Lamanov)\ **Post date:** [October 15, 2019, 7:56am UTC](https://discuss.elastic.co/t/7-3-2/201228/16 "2019-10-15T07:56:10Z")
Действительно, одна нода отваливается по `internal:coordination/fault_detection/follower_check` Какие можно включить trace в логировании чтобы посмотреть более детально? Параллельно смотрим на железо, но предварительно там всё хорошо и сеть не пропадает в это время ---
**Author:** ![Igor\_Motov](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/igor_motov/32/45193_2.png) [@Igor\_Motov](https://discuss.elastic.co/u/Igor_Motov)\ **Post date:** [October 15, 2019, 8:11am UTC](https://discuss.elastic.co/t/7-3-2/201228/17 "2019-10-15T08:11:11Z")
У Вас для этого кластера мониторинг настроен? ---
**Author:** ![Denis\_Lamanov](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/denis_lamanov/32/13111_2.png) [@Denis\_Lamanov](https://discuss.elastic.co/u/Denis_Lamanov)\ **Post date:** [October 15, 2019, 8:13am UTC](https://discuss.elastic.co/t/7-3-2/201228/18 "2019-10-15T08:13:08Z")
Мониторинг через Zabbix и ещё снимаем раз в минуту статистику по Heap Size и Open descriptors ---
**Author:** ![Denis\_Lamanov](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/denis_lamanov/32/13111_2.png) [@Denis\_Lamanov](https://discuss.elastic.co/u/Denis_Lamanov)\ **Post date:** [October 15, 2019, 8:16am UTC](https://discuss.elastic.co/t/7-3-2/201228/19 "2019-10-15T08:16:19Z")
Интересно, что после того как мастер отключил ноду по таймауту, то чуть позже приходят запоздалые ответы на респонсы (лог с мастера): `[2019-10-15T06:40:51,152][INFO][o.e.c.s.MasterService] [node-01] node-left[{node-00}{A9AdXLb5QA-ZMcicCn26OQ}{zkM7E5SdSmG6MdvxLMPiRQ}{10.1.3.110}{10.1.3.110:9300}{dilm}{ml.machine_memory=134928560128, ml.max_open_jobs=20, xpack.installed=true} followers check retry count exceeded], term: 24, version: 110637, reason: removed {{node-00}{A9AdXLb5QA-ZMcicCn26OQ}{zkM7E5SdSmG6MdvxLMPiRQ}{10.1.3.110}{10.1.3.110:9300}{dilm}{ml.machine_memory=134928560128, ml.max_open_jobs=20, xpack.installed=true},} [2019-10-15T06:40:53,929][WARN][o.e.t.TransportService] [node-01] Received response for a request that has timed out, sent [38172ms] ago, timed out [28069ms] ago, action [internal:coordination/fault_detection/follower_check], node [{node-00}{A9AdXLb5QA-ZMcicCn26OQ}{zkM7E5SdSmG6MdvxLMPiRQ}{10.1.3.110}{10.1.3.110:9300}{dilm}{ml.machine_memory=134928560128, ml.max_open_jobs=20, xpack.installed=true}], id [8400909] [2019-10-15T06:40:53,997][WARN][o.e.t.TransportService] [node-01] Received response for a request that has timed out, sent [27268ms] ago, timed out [17312ms] ago, action [internal:coordination/fault_detection/follower_check], node [{node-00}{A9AdXLb5QA-ZMcicCn26OQ}{zkM7E5SdSmG6MdvxLMPiRQ}{10.1.3.110}{10.1.3.110:9300}{dilm}{ml.machine_memory=134928560128, ml.max_open_jobs=20, xpack.installed=true}], id [8403538] [2019-10-15T06:40:54,000][WARN][o.e.t.TransportService] [node-01] Received response for a request that has timed out, sent [16311ms] ago, timed out [6340ms] ago, action [internal:coordination/fault_detection/follower_check], node [{node-00}{A9AdXLb5QA-ZMcicCn26OQ}{zkM7E5SdSmG6MdvxLMPiRQ}{10.1.3.110}{10.1.3.110:9300}{dilm}{ml.machine_memory=134928560128, ml.max_open_jobs=20, xpack.installed=true}], id [8405154]` ---
**Author:** ![Denis\_Lamanov](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/denis_lamanov/32/13111_2.png) [@Denis\_Lamanov](https://discuss.elastic.co/u/Denis_Lamanov)\ **Post date:** [October 15, 2019, 8:20am UTC](https://discuss.elastic.co/t/7-3-2/201228/20 "2019-10-15T08:20:05Z")
Вот история Heap Size по нодам(инцидент произошел в 6:40) ![image](https://us1.discourse-cdn.com/elastic/original/3X/a/2/a2b31f353f72e8663fb2e900d411a2fc10adbcd9.png) [Next page](https://discuss.elastic.co/t/7-3-2/201228.md?page=2)