› › ›

Настройки путей

Elasticsearch записывает индексированные данные в индексы и потоки данных в каталог data. Логи приложения Elasticsearch, содержащие информацию о состоянии кластера и операциях, записываются в каталог logs.

Для установок на macOS .tar.gz, Linux .tar.gz и Windows .zip по умолчанию data и logs являются подкаталогами $ES_HOME. Однако файлы в $ES_HOME могут быть удалены во время обновления.

В производственной среде настоятельно рекомендуется устанавливать path.data и path.logs в elasticsearch.yml, расположенные вне $ES_HOME. Установки Elasticsearch с помощью Docker, Debian и RPM по умолчанию записывают данные и логи в места, находящиеся вне $ES_HOME.

Поддерживаемые значения path.data и path.logs зависят от платформы:

Установки Linux и macOS поддерживают пути в стиле Unix:

path:
  data: /var/data/elasticsearch
  logs: /var/log/elasticsearch

Установки Windows поддерживают пути DOS с экранированными обратными слешами:

path:
  data: "C:\\Elastic\\Elasticsearch\\data"
  logs: "C:\\Elastic\\Elasticsearch\\logs"

Не изменяйте ничего в каталоге данных и не запускайте процессы, которые могут повлиять на его содержимое. Если что-то, кроме Elasticsearch, изменяет содержимое каталога данных, Elasticsearch может завершиться с ошибкой, сообщив о повреждении или других несоответствиях данных или может показаться, что работает правильно, но при этом незаметно потеряет часть ваших данных. Не пытайтесь создавать резервные копии файловой системы каталога данных; нет никакого поддерживаемого способа восстановить такую резервную копию. Вместо этого используйте Снимок и восстановление для безопасного создания резервных копий. Не запускайте сканеры вирусов в каталоге данных. Сканер вирусов может помешать корректной работе Elasticsearch и может изменить содержимое каталога данных. Каталог данных не содержит исполняемых файлов, поэтому сканер вирусов обнаружит только ложные срабатывания.

Несколько путей к данным

Устаревшее свойство с версии 7.13.0.

При необходимости вы можете указать несколько путей в path.data. Elasticsearch хранит данные узла по всем предоставленным путям, но данные каждого фрагмента хранятся в одном и том же пути.

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

Установки Linux и macOS поддерживают несколько путей в стиле Unix в path.data:

path:
  data:
    - /mnt/elasticsearch_1
    - /mnt/elasticsearch_2
    - /mnt/elasticsearch_3

Установки Windows поддерживают несколько путей DOS в path.data:

path:
  data:
    - "C:\\Elastic\\Elasticsearch_1"
    - "E:\\Elastic\\Elasticsearch_1"
    - "F:\\Elastic\\Elasticsearch_3"

Миграция с нескольких путей к данным

Поддержка нескольких путей к данным устарела в версии 7.13 и будет удалена в будущей версии.

В качестве альтернативы нескольким путям к данным вы можете создать файловую систему, которая охватывает несколько дисков с помощью уровня виртуализации аппаратного обеспечения, такого как RAID, или уровня виртуализации программного обеспечения, такого как Logical Volume Manager (LVM) в Linux или Storage Spaces в Windows. Если вы хотите использовать несколько путей к данным на одном компьютере, необходимо запустить один узел для каждого пути к данным.

Если вы в настоящее время используете несколько путей к данным в кластере высокой доступности, то вы можете мигрировать на настройку, использующую один путь для каждого узла без простоев, используя процесс, похожий на поэтапную перезагрузку: последовательно останавливать каждый узел и заменять его одним или несколькими узлами, каждый из которых настроен на использование одного пути к данным. Более подробно, для каждого узла, который в настоящее время имеет несколько путей к данным, необходимо выполнить следующую процедуру. В принципе, эту миграцию можно выполнить во время поэтапного обновления до 8.0, но мы рекомендуем выполнить миграцию на настройку с одним путем к данным перед началом обновления.

Создайте снимок для защиты данных на случай сбоя.

Необязательно, переместите данные с целевого узла, используя фильтр распределения:

resp = client.cluster.put_settings(
    persistent={
        "cluster.routing.allocation.exclude._name": "target-node-name"
    },
)
print(resp)

response = client.cluster.put_settings(
  body: {
    persistent: {
      'cluster.routing.allocation.exclude._name' => 'target-node-name'
    }
  }
)
puts response

const response = await client.cluster.putSettings({
  persistent: {
    "cluster.routing.allocation.exclude._name": "target-node-name",
  },
});
console.log(response);

PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.exclude._name": "target-node-name"
  }
}

Вы можете использовать API cat allocation для отслеживания прогресса этой миграции данных. Если некоторые фрагменты не мигрируют, API cluster allocation explain поможет вам определить причину.

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

Если применимо, удалите фильтр распределения, примененный на предыдущем шаге.

resp = client.cluster.put_settings(
    persistent={
        "cluster.routing.allocation.exclude._name": None
    },
)
print(resp)

response = client.cluster.put_settings(
  body: {
    persistent: {
      'cluster.routing.allocation.exclude._name' => nil
    }
  }
)
puts response

const response = await client.cluster.putSettings({
  persistent: {
    "cluster.routing.allocation.exclude._name": null,
  },
});
console.log(response);

PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.exclude._name": null
  }
}

Удалите данные, хранящиеся на остановленном узле, удалив содержимое его путей к данным.
Переконфигурируйте хранилище. Например, объедините диски в одну файловую систему с помощью LVM или Storage Spaces. Убедитесь, что в переконфигурированном хранилище достаточно места для данных, которые оно будет содержать.
Переконфигурируйте узел, скорректировав параметр path.data в файле elasticsearch.yml. При необходимости установите дополнительные узлы, каждый из которых имеет свой параметр path.data, указывающий на отдельный путь к данным.
Запустите новые узлы и следуйте остальной части процесса поэтапной перезагрузки для них.
Убедитесь, что состояние кластера равно green, чтобы каждый фрагмент был назначен.

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

Если вы в настоящее время используете несколько путей к данным, но ваш кластер не является высокодоступным, вы можете мигрировать на не устаревшую конфигурацию, создав снимок, создав новый кластер с желаемой конфигурацией и восстановив снимок в нём.

© 2023-2025 Elasticsearch
As of September 2024, Elasticsearch is available under a choice of three licenses: the Server Side Public License (SSPL), the Elastic License, or the AGPLv3 (OSI approved).
Elasticsearch and the Elasticsearch logo are trademarks of Elasticsearch B.V., registered in the U.S. and in other countries.
https://www.elastic.co/guide/en/elasticsearch/reference/8.17/path-settings-overview.html