Elasticsearch 7.2.0: мастер еще не обнаружен или не выбран, для выбора требуется как минимум X узлов - PullRequest
1 голос
/ 07 апреля 2020

Я пытаюсь автоматизировать процесс горизонтального масштабирования вверх и вниз узлов эластичного поиска в кластере kubernetes.

Изначально я развернул кластер эластичного поиска (3 основных, 3 узла данных и 3 узла загрузки) на кластер Kubernetes. Где cluster.initial_master_nodes было:

cluster.initial_master_nodes:
  - master-a
  - master-b
  - master-c

Затем я выполнил операцию уменьшения масштаба, уменьшив количество мастер-узлов с 3 до 1 (неожиданно, но для целей тестирования). При этом я удалил узлы master-c, master-b и перезапустил узел master-a со следующей настройкой:

cluster.initial_master_nodes:
  - master-a

Поскольку узлы эластичного поиска (т.е. модули) используют постоянный том после перезапуска узла master-a замедляет следующие журналы:

"message": "master not discovered or elected yet, an election requires at least 2 nodes with ids from [TxdOAdryQ8GAeirXQHQL-g, VmtilfRIT6KDVv1R6MHGlw, KAJclUD2SM6rt9PxCGACSA], have discovered [] which is not a quorum; discovery will continue using [] from hosts providers and [{master-a}{VmtilfRIT6KDVv1R6MHGlw}{g29haPBLRha89dZJmclkrg}{10.244.0.95}{10.244.0.95:9300}{ml.machine_memory=12447109120, xpack.installed=true, ml.max_open_jobs=20}] from last-known cluster state; node term 5, last-accepted version 40 in term 5"  }

Похоже, он пытается найти master-b и master-c.

Вопросы:

  • Как переписать настройки кластера, чтобы master-a не выполнял поиск этих удаленных узлов?

Ответы [ 2 ]

2 голосов
/ 07 апреля 2020

Параметр cluster.initial_master_nodes действует только при первом запуске кластера, но чтобы избежать некоторых очень редких угловых случаев, вы никогда не должны изменять его значение после его установки, и обычно вы должны удалить его из файла конфигурации как можно скорее. Из справочного руководства относительно cluster.initial_master_nodes:

Этот параметр не следует использовать при перезапуске кластера или добавлении нового узла в существующий кластер.

Кроме того, Elasticsearch использует протокол выборов на основе кворума и говорит следующее:

Чтобы быть уверенным, что кластер остается доступным, вы не должны останавливаться половина или более узлов в конфигурации голосования одновременно .

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

Справочное руководство также содержит инструкции по удалению узлов, отвечающих требованиям мастера , которые вы не выполняли:

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

Если есть Осталось только два подходящих для мастера узла, и ни один из них не может быть безопасно удален, так как оба необходимы для надежного продвижения. Чтобы удалить один из этих узлов, вы должны сначала сообщить Elasticsearch, что он не должен быть частью конфигурации голосования, и что право голоса должно быть передано другому узлу.

Далее будет описано как безопасно удалить ненужные узлы из конфигурации голосования, используя POST /_cluster/voting_config_exclusions/node_name при уменьшении до одного узла.

1 голос
/ 07 апреля 2020

Состояние кластера , в котором также хранятся главные хранилища конфигурации в папке данных узла Elasticsearch. В вашем случае кажется, что он читает состояние старого кластера (то есть 3 главных узла с их идентификаторами). ).

Не могли бы вы удалить папку данных вашего master-a, чтобы она могла запускаться из состояния чистого кластера и решить вашу проблему.

Также убедитесь, что другие данные и узел приема имеет настройку master.node:false, так как по умолчанию это правда.

...