Добрый день.
У меня есть задача - бэкапить индексы с одного ES кластера на другой.
Для нее я в данный момент использую reindex API.
Соединение между двумя кластерами нестабильное и может прерываться. Процесс реиндекса каждый раз начинается заново.
Чтобы решить эту проблему, я начал использовать ключи conflicts: "proceed" и op_type: "create".
Насколько я понимаю, это сочетание приведет к тому, в destination будут копироваться только те документы, которых там еще нет.
Нет ли каки-х-то "подводных камней" в данном способе? Что, если исходный индекс, например, будет изменяться в части создания новых документов или сервисного слияния сегментов?
Один из больших и очевидных подводных камней это удаление документов. В случае с reindex в целевом индексе у вас будет больше документов, чем в исходном.
Удаления документов из источника не планируется.
В целом такой подход будет работать - не идеально, т.к много лишних накладных расходов: необходимо будет копировать все данные из одного индекса в другой.
Другой вариант - это использовать snapshot - и snapshot создаются инкрементально, т.е нет нужны копировать целиком весь индекс.
И третий - это Cross Cluster Replication - https://github.com/elastic/elasticsearch/issues/30086 - работы идут активно в этом направлении и пока ещё не завершены. В таком случае синхронизация одного кластера в другой происходит почти в режиме реального времени, поддерживаются и удаления.
То есть, даже если установить параметр op_type: "create", все равно копироваться будут все документы?
Снепшоты не нравятся по причине выделения места под транзитное хранилище.
в случае op_type: "create" данные всё равно будут копироваться, но это не будет приводить к появлению дубликатов (в случае использования op_type: "index" по-умолчанию)
Не понял, уточните пожалуйста, как предполагается задать для op_type два значения: index и create?
В целом я правильно понимаю, что инкрементально удаленный reindex никак не сделать?
Когда вы делаете reindex параметр op_type задан неявно и он равен index, этот подводный камень вы самостоятельно преодолели задав его явно op_type: "create".
Инкрементально удалённый reindex невозможен, по крайней мере сейчас и никаких планов на обозримое будущее нет. Более эффективным и надежным подходом мы считаем CCR.
Извините, что вмешиваюсь - Владимир, а как долго ждать CCR? Очень не хватает такой штуки
Вы абсолютно правы - над ней ломали голову больше 4х лет - но вот-вот уже скоро она будет - точную дату не скажу ибо не все работы ещё закончены - смотрите приведённую meta issue. Точно могу сказать, что это коммерческая (xpack) функциональность.
1 Like
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.