Изменения в 7.0

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

См. также Что нового в 7.17 и Справочные материалы по выпуску.

Elasticsearch 7.0 может читать индексы, созданные в версии 6.0 или выше. Узел Elasticsearch 7.0 не будет запускаться в присутствии индексов, созданных в версии Elasticsearch до 6.0.

Эти execution_hint удалены и должны быть заменены на global_ordinals.

Динамическая настройка кластера с именем search.max_buckets теперь имеет значение по умолчанию 10 000 (вместо неограниченного в предыдущей версии). Запросы, которые пытаются вернуть больше, чем ограничение, завершатся с ошибкой.

Опция missing агрегации composite, устаревшая в 6.x, была удалена. Должно быть использовано missing_bucket.

Объект, используемый для обмена состоянием агрегации между скриптами в скриптовой метрической агрегации, теперь является переменной с именем state, доступной в контексте скрипта, а не предоставляется через объект params как params._agg.

Метрическая агрегация была изменена, чтобы потребовать эти два параметра скрипта, чтобы гарантировать, что пользователи явно определяют, как обрабатываются их данные.

Агрегации percentiles и percentile_ranks ранее возвращали NaN в ответе, если они применялись к пустому набору значений. Поскольку NaN не официально поддерживается JSON, он был заменен на null.

Когда агрегации stats и extended_stats собирали нулевые документы (doc_count: 0), их значение было null. Это отличалось от агрегации sum, которая возвращала 0. Агрегации stats и extended_stats теперь согласованы с sum и также возвращают ноль.

Для защиты от ошибок исчерпания памяти количество токенов, которые могут быть произведены с помощью конечной точки _analyze, было ограничено 10000. Это ограничение по умолчанию можно изменить для определенного индекса с помощью настройки индекса index.analyze.max_token_count.

Для выделения текста, индексированного без смещений или векторов терминов, требуется анализ этого текста в памяти в реальном времени во время запроса поиска. Для больших текстов этот анализ может занимать значительное время и память. Для защиты от этого максимальное количество символов, которое будет анализироваться, было ограничено 1000000. Это ограничение по умолчанию можно изменить для определенного индекса с помощью настройки индекса index.highlight.max_analyzed_offset.

delimited_payload_filter устарела и была переименована в delimited_payload в версии 6.2. Использование ее в индексах, созданных до 7.0, приведет к предупреждениям об устаревании. Использование старого имени в новых индексах, созданных в 7.0, приведет к ошибке. Используйте новое имя delimited_payload вместо него.

Фильтр токенов standard был удален, так как он не изменяет поток.

Анализатор standard_html_strip устарел и должен быть заменен комбинацией токенизатора standard и фильтра символов html_strip. Индексы, созданные с использованием этого анализатора, все еще будут доступны в elasticsearch 7.0, но создание новых индексов с его использованием будет невозможно.

Имена фильтров токенов nGram и edgeNGram устарели в предыдущей версии 6.x. Индексы, созданные с использованием этих фильтров токенов, все еще будут доступны в elasticsearch 7.0, но индексирование документов с использованием этих имен фильтров приведет к предупреждению об устаревании. Использование устаревших имен в новых индексах, начиная с версии 7.0.0, будет запрещено и приведет к ошибке при индексировании или анализе документов. Оба имени должны быть заменены на ngram или edge_ngram соответственно.

Для предотвращения создания слишком большого количества терминов индекса, разница между max_gram и min_gram в NGramTokenFilter и NGramTokenizer была ограничена 1. Это ограничение по умолчанию можно изменить с помощью настройки индекса index.max_ngram_diff. Обратите внимание, что если предел превышен, ошибка возникает только для новых индексов. Для существующих индексов до 7.0 регистрируется предупреждение об устаревании.

Для предотвращения создания слишком большого количества токенов, разница между max_shingle_size и min_shingle_size в ShingleTokenFilter была ограничена 3. Это ограничение по умолчанию можно изменить с помощью настройки индекса index.max_shingle_diff. Обратите внимание, что если предел превышен, ошибка возникает только для новых индексов. Для существующих индексов до 7.0 регистрируется предупреждение об устаревании.

Из-за межкластерного поиска с использованием : для разделения имени кластера и индекса, имена кластеров больше не могут содержать :.

Значение по умолчанию для параметра wait_for_active_shards API открытия индекса изменено с 0 на 1, что означает, что команда теперь по умолчанию будет ожидать распределения всех первичных фрагментов открытого индекса.

Эти предпочтения фрагментов удалены в пользу предпочтений _prefer_nodes и _only_nodes.

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

При первом запуске кластера параметр cluster.initial_master_nodes должен быть установлен для выполнения загрузки кластера. Он должен содержать имена узлов, имеющих право быть ведущими в исходном кластере, и должен быть определён на каждом узле, имеющем право быть ведущим в кластере. См. сводку параметров обнаружения для примера, а в документации по загрузке кластера описывается этот параметр более подробно.

Параметр discovery.zen.minimum_master_nodes разрешен, но игнорируется на узлах 7.x.

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

В производственных развертываниях Elasticsearch теперь требуется указать как минимум один из следующих параметров в файле конфигурации elasticsearch.yml:

Первые три параметра в этом списке доступны только в версиях 7.0 и выше. Если вы готовитесь к обновлению с более ранней версии, вам необходимо установить discovery.zen.ping.unicast.hosts или discovery.zen.hosts_provider.

Параметр discovery.zen.no_master_block теперь известен как cluster.no_master_block. Любое значение, установленное для discovery.zen.no_master_block, теперь игнорируется. После обновления необходимо удалить этот параметр и, при необходимости, установить cluster.no_master_block соответствующим образом.

По умолчанию подсистема обнаружения сбоев кластера теперь считает узел неисправным, если он не отвечает на 3 последовательных запроса ping, каждый из которых истекает через 10 секунд. Таким образом, узел, не отвечающий более 30 секунд, может быть удален из кластера. Ранее значение таймаута для каждого ping составляло 30 секунд, поэтому узел, не отвечающий, мог оставаться в кластере более 90 секунд.

В более ранних версиях можно было использовать узлы, не имеющие права быть ведущими, во время процесса обнаружения, в качестве узлов-семян или для косвенной передачи слухов о обнаружении между узлами, имеющими право быть ведущими. Кластеры, которые полагались на узлы, не имеющие права быть ведущими, были уязвимыми и не могли автоматически восстанавливаться после некоторых видов сбоев. Теперь обнаружение включает только узлы, имеющие право быть ведущими, в кластере, поэтому невозможно полагаться на узлы, не имеющие права быть ведущими. Вы должны настроить discovery.seed_hosts или другого поставщика узлов-семян для предоставления адресов всех узлов, имеющих право быть ведущими, в вашем кластере.

Ранее информация об исключении некоторых конфигураций ingest, связанных с процессорами ingest, отправлялась клиенту в заголовках HTTP, что не соответствует тому, как исключения передаются в других частях Elasticsearch.

Информация об исключениях конфигурации теперь передается как поле в теле ответа.

Была специальная обработка установки и удаления плагинов ingest-geoip и ingest-user-agent после их преобразования в модули. Эта специальная обработка была выполнена для минимизации прерывания работы пользователей в мажоре, и завершалась с кодом состояния 0, чтобы избежать прерывания автоматизации.

Эта специальная обработка теперь удалена.

Предыдущие версии Elasticsearch по умолчанию создавали пять фрагментов на индекс. Начиная с 7.0.0, значение по умолчанию теперь один фрагмент на индекс.

Из-за поиска между кластерами с использованием : для разделения имени кластера и индекса, имена индексов больше не могут содержать :.

Отрицательные значения интерпретировались как нули в более ранних версиях, но теперь не принимаются.

В предыдущих версиях, выполнение _flush или _force_merge (с flush=true) имело недокументированный побочный эффект обновления индекса, который делал новые документы видимыми для поиска и нереальных GET операций. Отныне эти операции не имеют этого побочного эффекта. Чтобы сделать документы видимыми, требуется явный вызов _refresh, если индекс не обновляется внутренним планировщиком.

Индексы, созданные с версией 7.0.0 и выше, будут иметь автоматически установленное значение index.number_of_routing_shards. Это может изменить то, как документы распределяются по фрагментам, в зависимости от количества фрагментов в индексе. Для сохранения точного распределения, как у индекса до 7.0.0, значение index.number_of_routing_shards должно быть установлено в значение index.number_of_shards во время создания индекса. Примечание: если количество фрагментов маршрутизации равно количеству фрагментов _split, операции не поддерживаются.

Фрагменты, принадлежащие индексу, у которого не настроено явное index.refresh_interval, больше не будут обновляться в фоновом режиме, как только фрагмент станет "неактивным по поиску", т.е. фрагмент не получал запросов на поиск в течение index.search.idle.after секунд (значение по умолчанию 30s). Запросы поиска, обращенные к неактивному по поиску фрагменту, будут "приостановлены" до следующего обновления. Запросы индексирования с wait_for_refresh также вызовут фоновое обновление.

Были удалены следующие ранее устаревшие параметры URL:

Ранее разрыв соединений входящих запросов рассматривался только по байтовому представлению. Повышая значение network.breaker.inflight_requests.overhead с 1 до 2, этот разрыв соединений теперь также учитывает накладные расходы памяти на представление запроса как структурированного объекта.

Родительский разрыв соединений определяет новый параметр indices.breaker.total.use_real_memory, который установлен по умолчанию в true. Это означает, что родительский разрыв соединений будет срабатывать на основе текущего использования кучи памяти, вместо того, чтобы рассматривать только зарезервированную память дочерними разрывами соединений. Когда этот параметр установлен в true, значение ограничения по умолчанию родительского разрыва соединений также меняется с 70% до 95% размера кучи JVM. Прежнее поведение можно восстановить, установив indices.breaker.total.use_real_memory в значение false.

Поскольку значения документов были включены по умолчанию в более ранних версиях Elasticsearch, потребность в fielddata уменьшилась. Поэтому, значение параметра indices.breaker.fielddata.limit по умолчанию было снижено с 60% до 40% размера кучи JVM.

Устарелое значение опции fix для параметра index.shard.check_on_startup не поддерживается.

Используйте инструмент elasticsearch-shard для удаления поврежденных данных translog.

Поле _all, устаревшее в 6, теперь удалено.

Это поле индексировало составной ключ, образованный из _type и _id. Теперь, так как индексы не могут иметь несколько типов, это поле удалено в пользу _id.

Схема _default_ была устаревшей в 6.0 и теперь больше не допускается в 7.0. Попытка настроить схему _default_ в индексах 7.x приведет к ошибке.

Если шаблон индекса содержит отображение _default_, он не сможет создать новые индексы. Чтобы решить эту проблему, отображение _default_ должно быть удалено из шаблона. Обратите внимание, что в 7.x API получения шаблона get template API по умолчанию не отображает отображение _default_, даже если оно определено в отображении. Чтобы увидеть все отображения в шаблоне, необходимо указать параметр include_type_name:

GET /_template/my_template?include_type_name

Дополнительную информацию о параметре include_type_name и других изменениях API, связанных с типами, см. в Удаление типов отображения.

Поле index_options для числовых полей было устаревшим в 6 и теперь удалено.

Для защиты от ошибок недостатка памяти, количество вложенных json-объектов в одном документе по всем полям ограничено 10000. Это значение по умолчанию можно изменить с помощью настройки индекса index.mapping.nested_objects.limit.

Эта опция бесполезна, так как теперь все индексы имеют не более одного типа.

Близость classic полагалась на коэффициенты координации для оценки качества при наличии стоп-слов в запросе. Эта функция была удалена из Lucene, что означает, что близость classic теперь дает оценки более низкого качества. Рекомендуется переключиться на BM25, которая широко признана лучшей альтернативой.

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

Типы geo_shape теперь по умолчанию используют векторный подход к индексированию, основанный на новом типе поля LatLonShape Lucene. Он индексирует формы как треугольную сетку, вместо того, чтобы декомпонировать их на отдельные ячейки сетки. Для индексирования с использованием устаревшего префиксного дерева параметр tree должен быть явно задан в одном из quadtree или geohash. Обратите внимание, что эти стратегии теперь устарели и будут удалены в будущей версии.

ВАЖНОЕ ПРИМЕЧАНИЕ: Если используется создание индекса по расписанию из шаблонов, отображение geo_shape также должно быть изменено в шаблоне, чтобы явно определить tree на один из geohash или quadtree. Это обеспечит совместимость с ранее созданными индексами.

Следующие параметры типа устарели для типа поля geo_shape: tree, precision, tree_levels, distance_error_pct, points_only и strategy. Они будут удалены в будущей версии.

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

Значение по умолчанию для include_type_name теперь равно false для всех API, которые принимают этот параметр.

Типы были удалены из конфигурации datafeed и больше не являются допустимыми параметрами.

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

Начиная с 7.0, индекс терминов загружается в куче для полей, которые содержат только уникальные значения, такие как поля _id, и вне кучи в противном случае — в большинстве других полей. Это должно уменьшить требования к памяти, но может замедлить запросы поиска, если выполнены оба условия ниже:

Это изменение влияет как на существующие индексы, созданные с Elasticsearch 6.x, так и на новые индексы, созданные с Elasticsearch 7.x.

Адаптивный выбор реплики включен по умолчанию. Если вы хотите вернуться к более старому циклическому алгоритму для запросов поиска, вы можете использовать настройку cluster.routing.use_adaptive_replica_selection:

PUT /_cluster/settings
{
  "persistent": {
    "cluster.routing.use_adaptive_replica_selection": false
  }
}

API поиска возвращает 400 - Bad request, в то время как ранее возвращало 500 - Internal Server Error в следующих случаях неверного запроса:

Установка request_cache:true в запросе, который создает прокрутку (scroll=1m), устарела в 6 и теперь возвращает 400 - Bad request. Запросы прокрутки не предназначены для кэширования.

Включение в запрос прокрутки (scroll=1m) клаузы rescore устарело в 6.5 и теперь возвращает 400 - Bad request. Разрешение rescore в запросах прокрутки нарушило бы сортировку прокрутки. В версии 6.x клауза rescore игнорировалась (для запросов прокрутки), а в версии 5.x она разрешалась.

Следующим алгоритмам расстояния строк были даны дополнительные имена в 6.2, а их существующие имена были объявлены устаревшими. Теперь устаревшие имена были удалены.

Режим popular для Suggesters (term и phrase) теперь использует частоту документов (вместо суммы частоты документов) входных терминов для вычисления порогового значения частоты для предлагаемых кандидатов.

Выполнение запроса Terms Query с большим количеством терминов может ухудшить производительность кластера, так как каждый дополнительный термин требует дополнительных вычислений и памяти. Для защиты от этого максимальное количество терминов, которые могут быть использованы в запросе Terms Query, ограничено 65536. Это значение по умолчанию можно изменить для конкретного индекса с помощью настройки индекса index.max_terms_count.

Выполнение запроса Regexp Query с длинной строкой регулярного выражения может ухудшить производительность поиска. Для защиты от этого максимальная длина регулярного выражения, которая может использоваться в запросе Regexp Query, ограничена 1000. Это значение по умолчанию можно изменить для конкретного индекса с помощью настройки индекса index.max_regex_length.

Выполнение запросов, использующих автоматическое расширение полей (например, query_string, simple_query_string или multi_match), может вызвать проблемы с производительностью для индексов с большим количеством полей. Для защиты от этого введено ограничение по умолчанию в 1024 поля для запросов, использующих режим «все поля» ("default_field": "*") или другие расширения имён полей (например, "foo*"). При необходимости можно изменить это ограничение с помощью статической настройки кластера indices.query.bool.max_clause_count.

Запросы поиска с дополнительным содержимым после основного объекта больше не будут приниматься конечной точкой _search. Вместо этого будет выброшено исключение при разборе.

Формат полей doc-value изменяется на тот же, что и в 6.x с использованием специального формата use_field_mapping. Это, в основном, изменение для полей даты, которые теперь форматируются в соответствии с форматом, настроенным в отображениях по умолчанию. Это поведение можно изменить, указав format внутри поля doc-value.

Возможность запроса и индексации предложений с включенным контекстом без контекста, устаревшая в 6.x, была удалена. Запросы предложений с включенным контекстом без контекстов должны посетить каждое предложение, что значительно снижает производительность поиска.

Для гео-контекста значение параметра path теперь проверяется по отображению, и контекст принимается только в том случае, если path указывает на поле с типом geo_point.

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

max_score устанавливалось в 0 всякий раз, когда оценки не отслеживались. Вместо этого теперь используется null, что является более подходящим значением для сценария, когда оценки недоступны.

Установка отрицательного boost для запроса или поля, устаревшего в 6x, в этой версии запрещена. Чтобы уменьшить приоритет определенного запроса или поля, можно использовать boost со значением от 0 до 1.

Отрицательные оценки в запросе Function Score устарели в 6.x и не допускаются в этой версии. Если в результате вычислений (например, в функциях script_score или field_value_factor) будет получена отрицательная оценка, будет выброшено исключение.

Контекст filter был удален из средств построения запросов Elasticsearch, различие между запросами и фильтрами теперь определяется в Lucene в зависимости от того, нуждаются ли запросы в доступе к оценке или нет. В результате запросы bool с клаузами should, которым не нужен доступ к оценке, больше не будут устанавливать свой minimum_should_match в 1. Это поведение устарело в предыдущей основной версии.

Общее количество совпадений с запросом поиска теперь возвращается в виде объекта с value и relation. value указывает количество совпадений, а relation указывает, является ли значение точным (eq) или нижней границей (gte):

{
  "hits": {
    "total": {
      "value": 1000,
      "relation": "eq"
    },
    ...
  }
}

Объект total в ответе указывает, что запрос соответствует ровно 1000 документам ("eq"). value всегда точное ("relation": "eq"), когда track_total_hits установлено в значение true в запросе. Вы также можете получить hits.total как число в ответе REST, добавив rest_total_hits_as_int=true в параметр запроса поиска. Этот параметр добавлен для облегчения перехода к новому формату и будет удален в следующей основной версии (8.0).

Если track_total_hits установлено в false в запросе поиска, ответ поиска установит hits.total в null, и объект не будет отображаться в уровне REST. Вы можете добавить rest_total_hits_as_int=true в параметры запроса поиска, чтобы получить старый формат обратно ("total": -1).

По умолчанию запрос поиска точно подсчитает общее количество совпадений до 10,000 документов. Если общее количество совпадений с запросом превышает это значение, ответ укажет, что возвращаемое значение является нижней границей:

{
  "_shards": ...
  "timed_out": false,
  "took": 100,
  "hits": {
    "max_score": 1.0,
    "total": {
      "value": 10000,    
      "relation": "gte"  
    },
    "hits": ...
  }
}

Вы можете принудительно установить точность подсчёта, установив track_total_hits в значение true явно в запросе поиска.

Lucene 8 ввел больше ограничений по сходству, в частности:

Отрицательные параметры weight в function_score больше не допускаются.

Количество автоматически расширенных полей для режима «все поля» ("default_field": "*") для запросов query_string и simple_query_string теперь составляет 1024 поля.

Теперь плагины должны явно указать тип предложения, которое они генерируют.

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

Файл службы systemd /usr/lib/systemd/system/elasticsearch.service ранее отмечался как файл конфигурации в пакетах rpm и deb. Надстройки для службы elasticsearch systemd должны быть внесены в /etc/systemd/system/elasticsearch.service.d/override.conf.

Пакет tar ранее включал файлы в каталоге bin, предназначенные только для Windows. Эти файлы были удалены. Используйте пакет zip вместо этого.

Ubuntu 14.04 достигнет окончания жизненного цикла 30 апреля 2019 года. В связи с этим мы больше не поддерживаем Ubuntu 14.04.

Возможность использования ${prompt.secret} и ${prompt.text} для сбора секретов из CLI при запуске сервера больше не поддерживается. Безопасные настройки заменили необходимость в этих запросах.

См. Настройки хранилища Azure.

См. Настройки клиента Google Cloud Storage.

Вследствие изменения настроек Realm, метод getRealmSettings был удален из класса SecurityExtension, а метод settings в классе RealmConfig теперь возвращает глобальные настройки узла. Пользовательские расширения безопасности должны регистрировать свои настройки, реализуя стандартный метод Plugin.getSettings, и могут получать их из RealmConfig.settings() или используя один из методов RealmConfig.getSetting. Каждая настройка домена должна быть определена как AffixSetting, как показано в примере ниже:

Setting.AffixSetting<String> MY_SETTING = Setting.affixKeySetting(
  "xpack.security.authc.realms." + MY_REALM_TYPE + ".", "my_setting",
  key -> Setting.simpleString(key, properties)
);

Метод RealmSettings.simpleString может быть использован в качестве удобства для вышеперечисленного.

Функциональность узла Tribe была удалена в пользу Поиска по нескольким кластерам.

Hipchat устарел и закрыт как сервис. Действие hipchat для наблюдения было удалено.

Elasticsearch сохраняет числовое поле версии для каждого хранимого документа. Это поле увеличивается на единицу при каждом изменении документа. До версии 7.0.0 API позволяло использовать это поле для контроля оптимистичной конкурентности, то есть выполнения операции записи условно на основе текущей версии документа. К сожалению, этот подход ошибочен, так как значение версии не всегда однозначно отражает изменение документа. Если первичный сервер выходит из строя во время обработки операции записи, он может раскрыть версию, которая затем будет повторно использована новым первичным сервером.

Из-за этой проблемы внутренняя версия больше не может быть использована и заменена новым методом на основе номеров последовательности. Чтобы переключиться на новый метод, выполните следующие шаги:

Было удалено несколько дублирующих параметров, устаревших в версии 6.x, из запросов Bulk, Multi Get, Term Vectors и More Like This.

Были удалены следующие параметры с верблюжьим регистром:

Были удалены следующие параметры, начинающиеся с подчеркивания:

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

В предыдущих версиях Elasticsearch информация о пуле потоков, возвращаемая в API информации о узлах, возвращала значения min и max, отражающие минимальное и максимальное количество потоков, которые могли находиться в каждом пуле потоков. Проблема с этим представлением заключается в том, что оно не соответствует параметрам конфигурации, используемым для настройки пулов потоков. Для масштабируемых пулов потоков минимальное количество потоков настраивается параметром core, а максимальное количество потоков настраивается параметром max. Для фиксированных пулов потоков существует только один параметр конфигурации, и этот параметр называется size, отражающий фиксированное количество потоков в пуле. Это несоответствие между API и параметрами конфигурации было исправлено. Теперь API будет сообщать core и max для масштабируемых пулов потоков и size для фиксированных пулов потоков.

Аналогично, в API cat thread pool существующий параметр вывода size был переименован в pool_size, который отражает количество потоков, в настоящее время находящихся в пуле; сокращение для этого значения было изменено с s на psz. Параметр вывода min был переименован в core с сокращением cr, сокращение для max было изменено на mx, а вывод size со сокращением sz был повторно использован для сообщения о настроенном количестве потоков в пуле. Это выравнивает вывод API с значениями конфигурации для пулов потоков. Обратите внимание, что core и max будут заполнены для масштабируемых пулов потоков, а size - для фиксированных пулов потоков.

API Update возвращает 400 - Bad request, если запрос содержит неизвестные параметры (вместо игнорирования в предыдущей версии).

Если вы попытаетесь PUT документ с версионированием (например, PUT /test/_doc/1?version=4), но документ не существует, возвращается загадочное сообщение:

version conflict, current version [-1] is different than the one provided [4]

Теперь, если документа нет, возвращается более полезное сообщение:

document does not exist (expected version [4])

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

Ранее статистика suggest была включена в статистику search. Поддержка метрики suggest в API статистики индексов и узлов сохранилась для обеспечения обратной совместимости. Обратная совместимость с метрикой suggest устарела в 6.3.0 и теперь удалена в 7.0.0.

В прошлом, fields можно было указать либо в качестве параметра, либо в теле запроса. Указание fields в теле запроса, а не в качестве параметра, было устаревшим в 6.4.0 и теперь не поддерживается в 7.0.0.

В версиях Elasticsearch до 6.4.0 настройки индекса при операциях сжатия и разделения не копировались. Начиная с Elasticsearch 7.0.0, по умолчанию такие настройки будут копироваться при подобных операциях. Чтобы пользователям в 6.4.0 было проще перейти к поведению по умолчанию в 7.0.0, был добавлен параметр copy_settings на уровне REST. Поскольку такое поведение будет единственным в 8.0.0, этот параметр устарел в 7.0.0 и будет удален в 8.0.0.

При добавлении хранимых скриптов поддержка их хранения с устаревшим контекстом template или без контекста теперь удалена. Скрипты должны храниться с контекстом script, как указано в документации.

Поведение и коды ответов API получения псевдонимов больше не зависят от того, включены ли функции безопасности. Ранее код 404 - NOT FOUND (IndexNotFoundException) мог возвращаться в случае, если текущий пользователь не был авторизован для любого псевдонима. Вместо этого теперь всегда возвращается пустой ответ со статусом 200 - OK.

Ответ API Put User был изменен в 6.5.0, чтобы добавить поле created вне объекта пользователя, где оно ранее находилось. В 7.0.0 объект пользователя был удален в пользу верхнего уровня created поля.

Устаревшие в 6.x параметры URL теперь удалены. Используйте _source_includes и _source_excludes вместо них.

Запросы MultiSearchRequests, выполняемые через _msearch, теперь проверяют все ключи в разделе metadata. Ранее неизвестные ключи игнорировались, а теперь выбрасывается исключение.

Были удалены устаревшие конечные точки графика (те, у которых /_graph/_explore).

Конечная точка _termvector была устаревшей в версии 2.0 и теперь удалена. Вместо неё следует использовать конечную точку _termvectors (множественное число).

Ограниченные индексы (в настоящее время только .security-6 и .security) — это специальные внутренние индексы, которые требуют установки флага allow_restricted_indices на каждом разрешении индекса, охватывающем их. Если этот флаг false (по умолчанию), разрешение не будет охватывать эти индексы, и действия по отношению к ним не будут авторизованы. Однако API мониторинга были единственным исключением из этого правила. Это исключение отменено, и привилегии мониторинга индексов должны быть предоставлены явно, используя флаг allow_restricted_indices в разрешении (как и любая другая привилегия индекса).

API _cache/clear больше не поддерживает HTTP-глагол GET. Он должен вызываться с помощью POST.

Поля compressed_size / compressed_size_in_bytes были удалены из ответа API состояния кластера. Вычисление размера было дорогостоящим и имело сомнительную ценность, поэтому поле было удалено из ответа.

API помощи при миграции функционально заменён API информации об устаревании, а API миграции обновления не используется для перехода с ES 6.x на 7.x и не должен храниться для исправления индексов, которые не были должным образом обновлены до обновления кластера, как это было в случае с 6.

Информация thread_pool, возвращаемая API узлов и Cat, была стандартизирована для использования той же терминологии, что и в конфигурациях пулов потоков. Это означает, что ответ будет соответствовать конфигурации, а не оставаться одинаковым во всех пулах потоков независимо от типа.

Если кластер был настроен с no_master_block: write и потерял своего мастера, он возвращал код состояния 503 от основного запроса (GET /), даже если были доступны жизнеспособные узлы с только чтением. Сейчас кластер возвращает код 200 в этой ситуации.

Ранее очистка кэша индексов могла выполняться как через GET, так и через POST. Поскольку GET должен поддерживать только операции чтения без изменения состояния, это больше не разрешается. Для очистки кэша можно использовать только POST.

isShardsAcked была заменена на isShardsAcknowledged в CreateIndexResponse, RolloverResponse и CreateIndexClusterStateUpdateResponse.

Метод prepareExecute, который создавал билдер запроса, удалён из API клиента. Вместо этого напрямую создайте билдер для соответствующего запроса.

Варианты Retry.withBackoff, включающие Settings, были удалены, так как Settings больше не требуется.

Метод клиента termVector, устаревший в версии 2.0, был удалён. Вместо этого следует использовать метод termVectors (множественное число).

Конструктор AbstractLifecycleComponent(Settings settings), устаревший в версии 6.7, был удалён. Вместо этого следует использовать конструктор без параметров.

Классы геометрии, используемые для представления гео-значений в SQL, были перемещены из пакета org.elasticsearch.geo.geometry в пакет org.elasticsearch.geometry, и порядок параметров конструктора изменился с lat, lon на lon, lat.

node.name теперь по умолчанию устанавливается в имя хоста во время запуска Elasticsearch. Ранее имя узла по умолчанию состояло из первых восьми символов идентификатора узла. Его всё ещё можно явно настроить в elasticsearch.yml.

Инфраструктура подключения к удалённому кластеру для поиска между кластерами также используется в репликации между кластерами. Это означает, что имена настроек search.remote.*, используемые для конфигурирования поиска между кластерами, скрывают тот факт, что они также применимы к другим ситуациям, где используется соединение с удалённым кластером. Поэтому эти настройки были переименованы с search.remote.* на cluster.remote.*. Для обратной совместимости мы перейдём к использованию search.remote.*, если cluster.remote.* не установлено. Для любых таких настроек, сохранённых в состоянии кластера или заданных при динамическом обновлении настроек, мы автоматически обновим настройку с search.remote.* до cluster.remote.*. Параметры обратной замены будут удалены в версии 8.0.0.

Следующие настройки были удалены:

Новые настройки имеют то же значение, что и удалённые, но компонент имени prefix больше не имеет смысла, поскольку записи аудита журнала — это структурированные JSON-документы и не имеют префиксов. Кроме того, xpack.security.audit.logfile.emit_node_name изменил значение по умолчанию с true на false. Все остальные упомянутые ранее настройки сохранили своё значение по умолчанию false.

Теперь настройки всех сфер безопасности должны включать тип сферы в имени настройки, и явная настройка type была удалена.

Сфера, которая ранее была настроена как:

xpack.security.authc.realms:
  ldap1:
    type: ldap
    order: 1
    url: "ldaps://ldap.example.com/"

Должна быть мигрирована на:

xpack.security.authc.realms:
  ldap.ldap1:
    order: 1
    url: "ldaps://ldap.example.com/"

Любые специфичные для сферы безопасные настройки, которые были сохранены в хранилище ключей Elasticsearch (например, пароли для привязки LDAP или пароли для SSL-ключей), должны быть обновлены аналогичным образом.

По умолчанию параметры TLS/SSL, которые начинались с xpack.ssl, были удалены. Удаление этих параметров по умолчанию также отключает возможность компонента использовать конфигурацию по умолчанию при использовании TLS. Теперь каждый компонент (домен, транспорт, http, http-клиент и т. д.) должен быть настроен со своими настройками TLS, если он используется.

Версия TLS 1.0 теперь по умолчанию отключена, так как она имеет известные проблемы безопасности.известные проблемы безопасности. Теперь по умолчанию используются протоколы TLSv1.3 (если поддерживается), TLSv1.2 и TLSv1.1.

Вы можете включить TLS v1.0, настроив соответствующую ssl.supported_protocols настройку, чтобы она включала "TLSv1". В зависимости от вашей локальной конфигурации и используемых на вашей сети протоколов TLS, вам может потребоваться включить поддержку TLS v1.0 в одном или во всех следующих местах:

Ниже приведён пример, который включает TLS v1.0 для входящих HTTP-соединений:

xpack.security.http.ssl.supported_protocols: [ "TLSv1.3", "TLSv1.2", "TLSv1.1", "TLSv1" ]

На пробных лицензиях xpack.security.enabled по умолчанию равно false.

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

Это поведение было удалено, поэтому безопасность включается только если:

Следующие настройки были удалены в пользу безопасных вариантов. Безопасные настройки должны быть определены внутри хранилища ключей каждого узла кластера, то есть их не следует указывать через API настроек кластера.

Все настройки в пространстве имён xpack.security.audit.index были удалены. Кроме того, была удалена настройка xpack.security.audit.outputs.

Эти настройки активировали и настраивали тип вывода индекса аудита. Этот тип вывода был удалён, потому что он был ненадежным в определённых сценариях, что могло привести к пропусканию событий аудита, в то время как операции в системе продолжались в обычном режиме. Рекомендуемая замена — использование типа вывода аудита logfile и использование других компонентов Elastic Stack для обработки индексирования.

Формат ECS теперь является значением по умолчанию. Настройка ecs для процессора пользовательского агента Ingest теперь по умолчанию равна true.

Настройка action.master.force_local была не документированной настройкой, используемой внутренне узлом трибы для принудительного чтения локального состояния кластера (вместо перенаправления на мастер, которого у узлов трибы не было). Поскольку узел трибы был удалён, эта настройка тоже была удалена.

Теперь ограничение фрагментов по всему кластеру принудительно выполняется и не является необязательным. Ограничение всё ещё можно настраивать по желанию с помощью API настроек кластера.

Ранее http.max_content_length сбрасывалось до 100mb, если настройка была больше чем Integer.MAX_VALUE. Эта мягкость была удалена.

У полей типа long и date были методы getDate() и getDates() (для многозначных полей), чтобы получить объект с методами для работы с датами для текущего значения документа. В 5.3.0 поля date были изменены, чтобы напрямую предоставлять этот же объект даты при вызове doc["myfield"].value, а методы-получатели для объектов даты были устаревшими. Эти методы теперь удалены. Вместо этого используйте .value для полей date или явно разобрать поля long в объект даты с помощью Instance.ofEpochMillis(doc["myfield"].value).

doc['field'].value выбросит исключение, если у документа отсутствует значение для поля field.

Чтобы проверить, отсутствует ли значение у документа, можно использовать doc['field'].size() == 0.

Неправильно сформированные скрипты, будь то в шаблонах поиска, каналах обработки данных или запросах поиска, возвращают 400 - Bad request, в то время как ранее они возвращали 500 - Internal Server Error. Это также относится к хранимым скриптам.

Метод ScriptDocValues#getValues() устарел в 6.6 и будет удалён в 7.0. Используйте doc["foo"] вместо doc["foo"].values.

Подробная информация о статистике снимков предоставляется новым структурированным способом:

Все методы API, принимающие заголовки как аргумент Header varargs, устаревшие с 6.4, были удалены в пользу недавно введённых методов, которые принимают вместо этого аргумент RequestOptions. Если вы не указываете заголовки, например, client.index(indexRequest) становится client.index(indexRequest, RequestOptions.DEFAULT). Если вы указываете заголовки, например, client.index(indexRequest, new Header("name" "value")) становится client.index(indexRequest, RequestOptions.DEFAULT.toBuilder().addHeader("name", "value").build());

API кластера состояния здоровья по умолчанию использует уровень shards для упрощения миграции с клиента транспорта, который не поддерживает параметр level и всегда возвращает информацию, включая сведения об индексах и фрагментах. Значение по умолчанию уровня согласовано со значением по умолчанию Elasticsearch: cluster.

RestClient и RestClientBuilder больше не поддерживают настройку maxRetryTimeout. Настройка была удалена, так как её механизм подсчёта не был точным и вызывал проблемы, принося при этом мало пользы.

В версии 6.4.0 были объявлены устаревшими варианты performRequest и performRequestAsync, которые не принимают объекты Request в пользу вариантов, которые принимают объекты Request, так как эти методы могут быть расширены без нарушения обратной совместимости.

В версии 6.4.0 была объявлена устаревшей функция setHosts в пользу функции setNodes, так как она поддерживает метаданные хоста, используемые NodeSelector.

Минимальная версия компилятора для клиента REST низкого уровня была увеличена до JDK 8.

Elasticsearch теперь будет генерировать дополнительные файлы журналов в формате JSON. Они будут храниться в файлах с расширением *.json. Следующие файлы теперь должны присутствовать в каталоге журналов: * ${cluster_name}_server.json * ${cluster_name}_deprecation.json * ${cluster_name}_index_search_slowlog.json * ${cluster_name}_index_indexing_slowlog.json * ${cluster_name}.log * ${cluster_name}_deprecation.log * ${cluster_name}_index_search_slowlog.log * ${cluster_name}_index_indexing_slowlog.log * ${cluster_name}_audit.json * gc.log

Примечание: Вы можете настроить, какие из этих файлов записывать, изменив log4j2.properties.

Файлы журналов с расширением .log, использующие старый формат шаблона, теперь считаются устаревшими, и вместо них следует использовать новый формат файлов журналов JSON с расширением .json. Примечание: журналы GC, записываемые в файл gc.log, не будут изменены.

Все журналы консоли Docker теперь находятся в формате JSON. Вы можете различать потоки журналов по полю type.

Elasticsearch больше не создаёт текстовый файл аудита ${cluster_name}_access.log. Файлы ${cluster_name}_audit.log также больше не существуют; они заменены файлами ${cluster_name}_audit.json. При включённой аудиторской проверке события аудита хранятся в этих специализированных файлах журналов JSON на каждом узле.

Переназначение существующего узла путём изменения node.master или node.data на false может оставить незадействованные метаданные и данные на диске, к которым узел больше не будет иметь доступа. Помимо хранения недоступных данных, это может привести к ситуациям, когда висящие индексы импортируются, даже если узел не может разместить фрагменты, что приведёт к красному состоянию здоровья кластера. Чтобы избежать этого,

Следует учитывать, что такие изменения ролей, выполненные до обновления до версии 7.0, могут помешать запуску узла в версии 7.0.

Начиная с Java 8, существует специализированный пакет java.time, который превосходит библиотеку Joda-Time, которая до сих пор использовалась в Elasticsearch. Одно из основных преимуществ — возможность хранить даты с разрешением выше миллисекунд для большей точности. Также это позволит нам в будущем удалить зависимость от Joda-Time.

Код отображений, агрегаций и поиска переключился с Joda-Time на java time.

С выпуском Elasticsearch 6.7 был представлен слой обратной совместимости, который проверял, используете ли вы форматировщик на основе Joda-Time, который поддерживается по-разному в java time. Выводилось сообщение в журнал, и вы могли создать соответствующий форматировщик java time с префиксом 8.

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

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

Use of 'Y' (year-of-era) will change to 'y' in the next major version of
Elasticsearch. Prefix your date format with '8' to use the new specifier.

Поэтому вместо использования YYYY.MM.dd, вы должны использовать 8yyyy.MM.dd.

Более подробную информацию об имеющихся строках форматирования вы можете найти в документации DateTimeFormatter.

Форматировщики epoch_millis и epoch_second больше не поддерживают научную запись.

Если вы используете форматировщик столетия эры в дате (C), он больше не будет поддерживаться.

Символ форматирования года эры является Y в Joda-Time, но строчной буквой y в java time.

Символ форматирования недели, основанного на годе, является строчной буквой x в Joda-Time, но заглавной буквой Y в java time.

Часовые пояса должны указываться как объекты часовых поясов на основе java time. Это означает, что вместо использования org.joda.time.DateTimeZone требуется использование java.time.ZoneId.

Примеры возможных вариантов использования — QueryStringQueryBuilder, RangeQueryBuilder или DateHistogramAggregationBuilder, каждый из них позволяет указать необязательный часовой пояс для этой части запроса поиска.

Корзины агрегаций, основанные на датах, в ответах раньше имели тип JodaTime. В связи с миграцией на java-time корзины теперь имеют тип ZonedDateTime. Поскольку клиент возвращает здесь неопределённые объекты, вы можете столкнуться с исключениями class cast только во время выполнения кода, а не во время компиляции. Убедитесь, что вы обеспечили соответствующее покрытие тестами для этого в своём коде.

При запуске Elasticsearch 7 с Java 8 вы больше не можете правильно обработать часовой пояс GMT0. Причина заключается в ошибке в JDK, которая не была исправлена для JDK8. Подробнее можно прочитать в официальном отчёте об ошибке. Эта ошибка исправлена в JDK9 и более поздних версиях.

Если даты используются в скриптах, был добавлен слой обратной совместимости, эмулирующий методы Joda-Time, но также выводит сообщение об устаревании для использования методов java time.

Следующие методы будут удалены в будущих версиях Elasticsearch и должны быть заменены.

С переходом на java time поддержка отрицательных временных меток эпохи была удалена. Для дат до 1970 года используйте формат даты, содержащий год.

Подробное руководство по миграции см. в руководстве по миграции на java time.