Изменения в 7.4

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

См. также Что нового в 7.17 и Заметки о релизе.

TokenizerFactory теперь имеет метод name(), который необходимо реализовать. Большинство реализаций TokenizerFactory, предоставляемых плагинами, будут расширять AbstractTokenizerFactory, который теперь принимает параметр name в своём конструкторе.

Если документ не содержит значения для векторного поля (dense_vector или sparse_vector), над которым выполняется векторная функция, будет выброшено исключение.

Ранее векторные функции, такие как cosineSimilarity, представляли вектор запроса как список значений типа double. Теперь векторные функции используют float, что соответствует тому, как хранятся векторы документов.

Начиная с версии 7.4 плагин repository-s3 по умолчанию не использует устаревший шаблон доступа по пути. В версиях 7.0, 7.1, 7.2 и 7.3 плагин repository-s3 всегда использовал шаблон доступа по пути. Это изменение является критическим для развертываний, поддерживающих только шаблон доступа по пути, но распознаваемых SDK AWS как поддерживающих шаблон доступа по DNS. Если ваше развертывание поддерживает только шаблон доступа по пути и затронуто этим изменением, необходимо настроить настройку клиента S3 path_style_access на true. Это критическое изменение было вызвано объявлением AWS о том, что шаблон доступа по пути устарел и будет недоступен для ведер, созданных после 30 сентября 2020 года. Объявление AWS.

Начиная с версии 7.4, знак «плюс» (+) в URL будет закодирован как %2B всеми функциями REST API. Предыдущие версии обрабатывали знак «плюс» как один пробел. Если ваше приложение требует обработки знака «плюс» как одного пробела, вы можете вернуться к старому поведению, установив системную переменную es.rest.url_plus_as_space в значение true. Обратите внимание, что это поведение устарело, и установка этой системной переменной в значение true больше не будет поддерживаться в версии 8.

После запуска каждого фрагмента избранный мастер-узел должен выполнить перераспределение, чтобы найти другие фрагменты, которые можно было бы распределить. В частности, при создании индекса именно эта задача распределяет реплики после запуска основных фрагментов. В версиях до 7.4 эта задача выполнялась с приоритетом URGENT, но начиная с версии 7.4 её приоритет снижен до NORMAL. В хорошо настроенном кластере это уменьшает объем работы мастера, но означает, что кластер с мастером, перегруженным другими задачами с приоритетом HIGH или URGENT, может дольше распределять все реплики.

Кроме того, до версии 7.4 API GET _cluster_health?wait_for_no_initializing_shards и GET _cluster/health?wait_for_no_relocating_shards возвращали результат только после завершения всех ожидающих перераспределений, но начиная с версии 7.4, если вы хотите дождаться полного завершения процесса перераспределения, при вызове этих API необходимо добавить параметр запроса wait_for_events=languid.

Если у узла превышен порог заполнения диска, Elasticsearch добавляет блокировку index.blocks.read_only_allow_delete ко всем своим индексам, чтобы предотвратить дальнейшие записи как крайнее средство предотвращения полного исчерпания дискового пространства узла. В более ранних версиях эта блокировка оставалась до её ручного удаления, что вызывало путаницу у пользователей, у которых в настоящее время достаточно места на диске, и которые не знают, что они почти исчерпали его в какой-то момент в прошлом. Начиная с 7.4, блокировка автоматически снимается, когда узел опускается ниже верхнего порога вновь, при предположении, что верхний порог находится на некотором расстоянии ниже порога заполнения, и, следовательно, проблема с дисковым пространством действительно решена. Поскольку эта блокировка может быть автоматически снята, вы больше не можете полагаться на ручное добавление этой блокировки для предотвращения записей в индекс. Вместо этого следует использовать блокировку index.blocks.read_only. Это поведение можно отключить, установив системную переменную es.disk.auto_release_flood_stage_block в значение false.

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

Для обеспечения правильной организации всех настроек в пространстве имён, настройка pidfile устарела и будет удалена в версии 8.0.0. Используйте вместо неё node.pidfile.

Для обеспечения правильной организации всех настроек в пространстве имён, настройка processors устарела и будет удалена в версии 8.0.0. Используйте вместо неё node.processors.

Формат ответа API Get transform statistics существенно отличается от предыдущих версий:

Пример нового формата см. в Примеры.

Поле progress_percent типа целого числа вверху статистики задания аналитики фреймов данных заменено полем progress, которое представляет собой массив объектов. Каждый объект содержит имя фазы phase и прогресс progress_percent одной фазы анализа. Например:

{
  "id" : "my_job",
  "state" : "analyzing",
  "progress" : [
    {
      "phase" : "reindexing",
      "progress_percent" : 100
    },
    {
      "phase" : "loading_data",
      "progress_percent" : 100
    },
    {
      "phase" : "analyzing",
      "progress_percent" : 47
    },
    {
      "phase" : "writing_results",
      "progress_percent" : 0
    }
  ]
}