используя конфигурацию solr master slave с TYPO3?

#solr #typo3

#solr #typo3

Вопрос:

У нас есть несколько сайтов, которые используют solr в качестве внутреннего поиска. Это делается с помощью расширения ext:solr из DKD. Внутри расширения есть установочный скрипт, который предоставляет ядро для нескольких языков.
Это хорошо работает в большинстве систем.

Между тем у нас есть несколько более крупных сайтов, и поскольку есть некоторые специальности, у нас возникают проблемы:

У нас есть сайты, которые регулярно импортируют данные из-за пределов TYPO3. Чтобы обновить индекс solr, нам нужно перестроить полный индекс (ночью). Но по мере того, как сайт становится больше, переиндексация занимает все больше и больше времени. И если возникает ошибка, индекс нарушается на следующий день.

Вы могли бы сказать: нет проблем, просто обновите все записи, но это оставило бы информацию в индексе для записей, которые были удалены тем временем (при импорте нет информации «удалить», за исключением того, что удаленной записи больше нет при импорте. Таким образом, необходимо полное удаление всех записей перед импортом (или специальная маркировка и явное удаление впоследствии).

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

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

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

(Я думаю, что проблема не зависит от конкретной версии TYPO3 или solr, поэтому нет тега версии)

Ответ №1:

вы знаете о нашей концепции чтения и записи, представленной в EXT: Solr 9 https://docs.typo3.org/p/apache-solr-for-typo3/solr/11.0/en-us/Releases/solr-release-9-0.html#support-to-differ-between-read-and-write-connections ? Разве это не подходит для вашего случая? Единственное, что вам нужно, это правильно настроить его при развертывании. Если ваш новый индекс завершен и исправен и не поврежден, вы просто переключаете ядро чтения на чтение из предыдущей записи.

Комментарии:

1. у нас уже была эта идея, но как мы можем переключаться автоматически? конфигурация сервера чтения / записи — это конфигурация, которая хранится в репозитории и развертывается. мы не можем выполнять развертывание каждый раз, когда индекс перестраивается (что следует делать не реже одного раза в день)

2. Я бы предложил использовать ENV. лакомства для приложений vars и factor 12.