Elasticsearch, Не удалось получить блокировку node, это следующее место для записи

Ответ 1

У меня был потерянный процесс Java, связанный с Elasticsearch. Убийство решило проблему с блокировкой.

ps aux | grep 'java'
kill -9 <PID>

Ответ 2

Я получил такое же сообщение об ошибке, но все было прекрасно настроено, и все права были правильно назначены.

Оказывается, у меня был "потерянный" процесс elasticsearch, который не был убит обычной командой остановки.

Мне пришлось вручную убить процесс, а затем снова возобновить работу elasticsearch.

Ответ 3

причина - другой экземпляр работает!
сначала найдите идентификатор бегущей резинки.

ps aux | grep 'elastic'

затем уничтожьте с помощью kill -9 <PID_OF_RUNNING_ELASTIC>.
Были ответы на удаление файла node.lock, но это не помогло, так как исполняемый экземпляр снова сделает это!

Ответ 4

В моей ситуации у меня были неправильные разрешения для папки ES dir. Установка правильного владельца разрешила его.

# change owner
chown -R elasticsearch:elasticsearch /data/elasticsearch/

# to validate
ls /data/elasticsearch/ -la
# prints    
# drwxr-xr-x 2 elasticsearch elasticsearch 4096 Apr 30 14:54 CLUSTER_NAME

Ответ 5

У вас уже запущен ES. Чтобы доказать этот тип:

curl 'localhost: 9200/_cat/indices? v'

Если вы хотите запустить другой экземпляр в том же поле, вы можете установить node.max_local_storage_nodes в elasticsearch.yml значение, большее 1.

Ответ 6

Попробуйте следующее: 1. найти порт 9200, например: lsof -i:9200  Это покажет вам, какие процессы используют порт 9200. 2. убить пид (ы), например Повторите kill -9 pid для каждого PID, который был показан на шаге 1 на выходе lsof. 3. перезапустите эластичный поиск, например, elasticsearch

Ответ 7

После того, как я обновил docker-образ эластичного поиска с версии 5.6.x до 6.3.y, контейнер больше не запускается из-за вышеупомянутой ошибки

Не удалось получить блокировку узла

В моем случае основной причиной ошибки было отсутствие прав доступа к файлам

Папка данных, используемая эластичным поиском, была смонтирована из хост-системы в контейнер (объявлен в docker-compose.yml):

    volumes:
      - /var/docker_folders/common/experimental-upgrade:/usr/share/elasticsearch/data

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

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

Может быть, кто-нибудь мог бы уточнить соответствующие права для установки смонтированной папки в Docker-контейнере?

Ответ 8

У меня был другой ElasticSearch, работающий на той же машине.

Команда для проверки: netstat -nlp | grep 9200 (9200 - Elastic Port) Результат: tcp 0 0: 9210: * LISTEN 27462/java

Убить процесс, убить -9 27462 27462 - PID экземпляра ElasticSearch

Начните упругий поиск, и он может запуститься сейчас.

Ответ 9

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

Ответ 10

Чтобы добавить к вышеупомянутым ответам, могут быть некоторые другие сценарии, в которых вы можете получить ошибку. Фактически я сделал обновление с 5.5 до 6.3 для эластичного поиска. Я использовал настройку докера составления с именованными томами для каталогов данных. Я должен был сделать docker volume prune, чтобы удалить устаревшие. После этого я больше не сталкивался с проблемой.

Ответ 11

Для меня ошибка была простой: я создал новый каталог данных /mnt/elkdata и изменил владельца на пользователя эластичного пользователя. Затем я скопировал файлы и снова забыл поменять владельца.

После этого и перезапуска упругого узла все заработало.

Ответ 12

Как и многие другие, отвечающие здесь, это было вызвано неправильными разрешениями для каталога (не принадлежащего пользователюasticsearch). В нашем случае это было вызвано удалением Elasticsearch и его переустановкой (через yum, используя официальные репозитории).

На данный момент репозитории не удаляют каталог nodes при удалении, но они удаляют пользователя/группу elasticsearch, которой он принадлежит. Затем, когда Elasticsearch переустанавливается, создается новый, другой пользователь/группа elasticsearch, оставляя старый каталог nodes все еще присутствующим, но принадлежащий старому UID/GID. Это вступает в конфликт и вызывает ошибку.

Решением является рекурсивный chown, упомянутый @oleksii.