Elasticsearch: индексы переведены в режим только для чтения
При заполнении диска Elasticsearch сначала перестаёт размещать новые части индексов, а затем переводит индексы в режим только для чтения. Снятие блокировки без освобождения места приводит к её возврату через минуты.
Вероятные причины
По порядку: сверху то, что встречается чаще.
-
Диск заполнен выше верхнего порога
Пороги заданы в процентах от раздела. Пройдя верхний, служба защищает данные, запрещая запись.
-
Пороги заданы в процентах на большом разделе
На разделе в несколько терабайт 5% свободного — это десятки гигабайт, которые кажутся достаточными. Служба считает иначе.
-
Старые индексы никто не удаляет
Без политики жизненного цикла индексы копятся, пока не заполнят раздел. Это вопрос эксплуатации, а не настройки порогов.
Диагностика
Команды идут в том порядке, в котором их стоит выполнять: каждая следующая проверяет то, что осталось после предыдущей.
Свободное место на разделе данных.
df -h /var/lib/elasticsearchРаспределение данных и свободное место с точки зрения службы.
curl -s localhost:9200/_cat/allocation?vЗаписи о прохождении порогов.
sudo tail -30 /var/log/elasticsearch/elasticsearch.log | grep -i watermarkРешение
Решение своё для каждой причины. Сначала определите, какая из них ваша, — иначе правки наложатся друг на друга.
- Почему происходит
- Пороги заданы в процентах от раздела. Пройдя верхний, служба защищает данные, запрещая запись.
- Как проверить
-
Посмотрите место и состояние блокировки.
df -h /var/lib/elasticsearch curl -s localhost:9200/_cat/allocation?v 2>/dev/null | head
- Как исправить
-
Освободите место: удалите старые индексы или расширьте раздел. После этого снимите блокировку запросом к службе.
curl -s -XPUT localhost:9200/_all/_settings -H 'Content-Type: application/json' -d '{"index.blocks.read_only_allow_delete":null}'
- Почему происходит
- На разделе в несколько терабайт 5% свободного — это десятки гигабайт, которые кажутся достаточными. Служба считает иначе.
- Как проверить
-
Посмотрите действующие пороги.
curl -s localhost:9200/_cluster/settings?include_defaults=true 2>/dev/null | head -c 400
- Как исправить
- Задайте пороги в абсолютных значениях, а не в процентах: для больших разделов это точнее.
- Почему происходит
- Без политики жизненного цикла индексы копятся, пока не заполнят раздел. Это вопрос эксплуатации, а не настройки порогов.
- Как проверить
-
Посмотрите размеры индексов.
curl -s localhost:9200/_cat/indices?v&s=store.size:desc 2>/dev/null | head
- Как исправить
- Настройте политику жизненного цикла индексов или удаляйте старые по расписанию таймером.
Пример вывода
Диск заполнен, индексы заблокированы для записи. Пример показательный: он собран на тестовой машине специально для этой страницы, а не взят из чужого журнала.
elasticsearch[1200]: [WARN ][o.e.c.r.a.DiskThresholdMonitor] flood stage disk watermark [95%] exceeded on [node-1][/var/lib/elasticsearch] free: 2.1gb[4.2%], all indices on this node will be marked read-only
app[4100]: error: cluster_block_exception: index [logs-2026.09] blocked by: [TOO_MANY_REQUESTS/12/disk usage exceeded flood-stage watermark, index has read-only-allow-delete block]Связанные ошибки
- No space left on device в журнале службы Нет места на устройстве: разбор по свободным блокам, по inode, по журналу systemd и по удалённым, но открытым файлам.
- Elasticsearch: max virtual memory areas vm.max_map_count is too low Elasticsearch отказывается стартовать из-за заниженного vm.max_map_count. Как поднять значение и закрепить его.
- Disk quota exceeded для службы Место на разделе есть, а запись отклоняется: исчерпана дисковая квота пользователя или группы.
- Docker: no space left on device при запуске контейнеров Раздел с /var/lib/docker заполнен образами и слоями. Как посчитать занятое и что можно удалить безопасно.
- Elasticsearch: служба падает из-за размера кучи JVM Размер кучи больше доступной памяти или больше предела службы: падение при старте или под нагрузкой.
- Input/output error в журнале службы Ошибка ввода-вывода: проблемы носителя, отвалившийся сетевой ресурс, повреждённая файловая система. Что проверять срочно.
- MySQL: InnoDB не запускается после аварийного завершения Ошибки InnoDB при старте: повреждение страниц, несовпадение журнала, режим принудительного восстановления.
- MySQL: журнал двоичных изменений заполнил диск Место кончилось из-за binlog: не настроена очистка, отстала репликация, слишком большой срок хранения.
Где встречается чаще всего
Источники
- Документация Elasticsearch: пороги заполнения диска
-
Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
Воспроизведено заполнением раздела данных в тестовой среде.