Перенос данных с 5.6.2 на 7.7.1 версию (reindex from a remote) и консистентность данных

Добрый день!

Выполняю перенос данных из 5.6.2 на 7.7.1 версию (reindex from a remote) через _reindex api - как описано тут

Все прекрасно переносится - по большей части обошелся лишь удалением типа из маппинга.

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

У вас время создания/обновления в документы добавляется?

Игорь, нет, индексы не time series, поле @timestamp и вообще что-то, напоминающее поле с временем в документе отсутствует.

А записи обновляются или только новые записи создаются?

Только новые создаются.

В идеале, было бы здорово пометить записи, которые были добавлены после начала реиндексации каким-нибудь образом (через pipeline или ваш код индексации) чтобы их можно было легко отфильтровать на входе при повторной реиндексации. В противном случае, надо с будет переиндексировать все с "op_type": "create" и "conflicts": "proceed", чтобы процесс пыталься только создавать новые записи и игнорировать ошибки, если такие записи уже существуют.

То есть примерно нечто подобное:

POST _reindex?wait_for_completion=false
{
  "source": {
    "remote": {
      "host": "http://192.168.50.214:9200",
      "username": "elastic",
      "password": "changeme"
    },
    "index": "favorites_v2"
  },
  "dest": {
    "index": "favorites_v2",
    "op_type": "create",
    "conflicts": "proceed"
  }
}

У меня к сожалению ругается на "conflicts": "proceed"

conflicts должен быть на том же уровне, что и dest, а не внутри. См. документацию.

Спасибо за ответ!

Попробовал так:

POST _reindex?wait_for_completion=false
{
  "source": {
    "remote": {
      "host": "http://192.168.50.214:9200",
      "username": "elastic",
      "password": "changeme"
    },
    "index": "favorites_v2"
  },
  "dest": {
    "index": "favorites_v2",
    "op_type": "create"
  },
  "conflicts": "proceed"
}

К сожалению так вышло даже дольше чем залить данные с нуля :frowning:

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