Elasticsearch reindex api - не в состоянии скопировать все документы - PullRequest
Новая
       8

Elasticsearch reindex api - не в состоянии скопировать все документы

1 голос
/ 13 марта 2020

Я настроил целевой индекс new_dest_index перед выполнением действия _reindex, включая настройку сопоставлений, подсчетов осколков, реплик и т. Д. c.

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

Может кто-нибудь помочь, а также Есть ли более эффективные способы копирования из одного индекса в другой? 

POST _reindex
{
  "source": {
    "index": "source_index"
  },
  "dest": {
    "index": "new_dest_index"
  }
}

Ответы [ 2 ]

1 голос
/ 13 марта 2020

Я думаю, что это лучший способ для копирования из одного индекса в другой.

Процесс reindex, если я правильно помню, копирует 10000 единиц каждый раз из одного индекса в другой. Вы не видите все документы в целевом индексе, потому что задачи еще не завершены (в лучшем случае).

Вы всегда можете перечислить reindex задач с помощью _cat / tasks like: 

GET _cat/tasks?v

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

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

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

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

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

Надеюсь, это полезно! :)

0 голосов
/ 14 марта 2020

Кевин уже показал случай, когда задача переиндексации еще не завершена, я отвечаю на случай, когда процесс переиндексации завершен.

Обратите внимание, что _reindex API может вызвать проблемы с данными, которые являются новыми обновленными (недавно вставленными) + обновлено) на source_index, что происходит сразу после срабатывания _reindex, не применяется к new_dest_index.

Например, прежде чем запустить _reindex, вы добавляете документ: 

PUT source_index/doc/3
{
  "id": 3,
  "searchable_name": "version1"
}
//responses
{
  "_index": "source_index",
  "_type": "doc",
  "_id": "3",
  "_version": 1,
  "result": "created",
  "_shards": {
    "total": 2,
    "successful": 2,
    "failed": 0
  },
  "created": true
}

И затем вы запускаете _reindex API, после запуска _reindex вы обновляете документ: 

PUT source_index/doc/3
{
  "id": 3,
  "searchable_name": "version2"
}
//responses
{
  "_index": "source_index",
  "_type": "doc",
  "_id": "3",
  "_version": 2,
  "result": "updated",
  "_shards": {
    "total": 2,
    "successful": 2,
    "failed": 0
  },
  "created": false
}

Но после завершения _reindex вы проверяете версию документа в new_dest_index: 

{
  "_index": "new_dest_index",
  "_type": "doc",
  "_id": "3",
  "_version": 1,
  "found": true,
  "_source": {
    "id": 3,
    "searchable_name": "version1"
  }
}

Те же проблемы могут возникать для документов, вставленных после триггера _reindex One Решение этой проблемы заключается в том, что когда вы в первый раз переиндексируете и сохраните версию source_index с использованием настройки version_type= external для new_dest_index, после того, как вы сделаете c вашу запись в new_dest_index, вы можете снова переиндексировать с source_index в new_dest_index для переиндексации отсутствующего нового обновления после запуска _reindex. Вы можете проверить эти настройки в документах здесь .

...