Sitecore Lucene: индекс сервера доставки контента не обновляется при публикации
Я создал страницу пользовательского поиска по умолчанию sitecore_web_index
, и все, казалось, работало, пока я не перешел на тестовую среду с отдельными серверами управления контентом и серверами доставки контента. Индекс на сервере CD не обновляется при публикации (сервер CM делает это), если я перестрою индекс с панели управления, я вижу обновления. Поэтому я считаю, что индекс и страница поиска работают правильно.
В индексе используется стратегия onPublishEndAsync
. Руководство по поиску и указанию Sitecore (http://sdn.sitecore.net/upload/sitecore7/70/sitecore_search_and_indexing_guide_sc70-usletter.pdf) в разделе 4.4.2 гласит:
Эта стратегия делает именно то, что подразумевает название. Во время инициализации он подписывается на OnPublishEnd
и запускает инкрементную перестройку индекса. С отдельными серверами CM и CD это событие будет инициировано с помощью объекта EventQueue
, что означает, что объект EventQueue
должен быть чтобы эта стратегия работала в такой среде.
У моего web.config есть <setting name="EnableEventQueues" value="true"/>
Также из руководства по поиску и указателям:
Обработка
Стратегия будет использовать объект EventQueue
из базы данных, в которую она была инициализирована: <param desc="database">web</param>
Это означает, что существует множество критериев для успешного выполнения этой стратегии:
- Эта база данных должна быть указана в разделе
<databases />
конфигурационного файла. - Значение параметра
EnableEventQueues
должно быть равно true. - Таблица
EventQueue
в предварительно сконфигурированной базе данных должна иметь записи, датированные позже индекс времени последнего обновления.
Я не уверен в настройке <param desc="database">web</param>
, потому что цель публикации (и идентификатор базы данных) для CD-сервера pub1
. Я попытался изменить web
на pub1
, но затем ни один из них не обновлялся в публикации (поэтому он изменился на web
).
Недавно система была обновлена с Sitecore 6.5 до 7.2, поэтому есть несколько индексов с использованием API Sitecore.Search
, и эти индексы обновляются в публикации.
Является ли параметр базы данных на EventQueue
неправильным, учитывая множественные цели публикации? Есть ли что-то еще, что мне не хватает, или, возможно, рабочий пример среды CM → CD, с которой я мог бы сравниться?
ТИА
EDIT:
Если бы у меня не было собеседника, сидящего рядом со мной как в пятницу, так и сегодня, кто может подтвердить, я думаю, что сойду с ума. Но теперь сервер CD получает обновления индекса, но сервер CM не получает обновлений. Что бы теперь сервер CM не получал обновления?
Ответы
Ответ 1
Я столкнулся с тем же вопросом прошлой ночью и получил более предсказуемое разрешение, чем создание нового сайта IIS:
Решено было установить отдельное имя экземпляра в ScalabilitySettings.config для каждого CD-сервера вместо того, чтобы полагаться на автоматически сгенерированное имя.
Установка этого значения немедленно устранила проблему и восстановила функциональность обновления индекса при событиях публикации End Remote.
Примечание. Если у вас уже есть имя экземпляра, определенное в вашей конфигурации, вам необходимо изменить его для этого. Я просто увеличиваю InstanceName с датой для принудительного изменения.
Это эффективно устраняет ту же проблему, что и исходный плакат, перейдя на новый сайт IIS, поскольку исправление OP изменило бы автогенерированное имя экземпляра на основе нового имени сайта IIS.
Я считаю, что основная проблема с OP (а также в моем случае) связана с тем, что базы данных EventQueue не синхронизируются с экземплярами компакт-дисков, и ни один из серверов не может определить, что событие было создано/какой контент необходимо обновить в индексе. Изменяя имя экземпляра (используя любой метод), серверы выглядят как новые экземпляры и начинаются с нуля с отслеживанием EventQueue.
Каждый раз, когда я видел подобные проблемы в прошлом, он был связан с основными манипуляциями с базами данных Sitecore. Такие, как реставрация, резервное копирование/восстановление для нового имени базы данных или откаты баз данных из-за проблем с развертыванием. Я считаю, что что-то в вышеупомянутых операциях заставляет EventQueues выйти из синхронизации, и серверы перестают отвечать на ожидаемые события.
Ответ 2
В случае, если кто-то столкнется с этим в будущем, решение, которое сработало для меня, создало новый сайт в диспетчере IIS.
Я отправил билет в службу поддержки Sitecore, но после того, как неделя не получила ответа, я попытался воссоздать среду моего dev на моем тестовом сервере. Я скопировал свои локальные /dev файлы на тестовый CM-сервер, создал новый сайт и AppPool в IIS, указал на недавно скопированные файлы и обновил connectionstrings.config, чтобы указать на базу тестовой среды. Это сработало (публикация обновила веб-индекс CM).
После попытки указать существующий сайт IIS на мои новые файлы и использовать новый AppPool, публикация с этого сайта не будет обновлять веб-индекс CM.
Затем я указал мой новый сайт на уже существующие файлы и уже существующий AppPool, и он все еще работал. Я отключил ранее существовавший сайт IIS, отредактировал привязки на новом сайте, чтобы соответствовать уже существующему, и все работало так, как должно быть.
Я не знаю, что было "неправильно" с уже существующим сайтом (я унаследовал систему, поэтому я не знаю, как она была создана), но сравнивая привязки, базовые настройки и расширенные настройки, они были идеальным сочетанием с функциональным новым сайтом IIS. Хотелось бы, чтобы у меня была настоящая "причина" проблемы, но, по крайней мере, я нашел решение, которое сработало для меня.
Спасибо всем за ответы.
[EDIT] Хотя это решение действительно сработало для меня, пожалуйста, используйте ответ Laver как правильное решение для этой проблемы.
Ответ 3
У меня была эта проблема, и это заставило меня зацепиться несколько месяцев. Я выяснил, что ответ лгал в стратегии восстановления индекса Lucene. Единственный способ, с помощью которого Lucene может пересоздать себя, когда CM и CD находятся в отдельных экземплярах IIS, - это lucene, чтобы наблюдать за таблицей EventQueue и признать, что произошло изменение с элементом, который находится либо в корне, либо в дочернем root, который вы укажете в искателе node. Стратегия, которую вам нужно указать в качестве стратегии восстановления для обеспечения этого поведения, ниже
<strategies hint="list:AddStrategy">
<strategy ref="contentSearch/indexUpdateStrategies/remoteRebuild" />
</strategies>
Ответ 4
Кажется, вы на правильном пути. Я считаю, что вы отключаете рекламу. Насколько я понимаю, вы используете pub1 в качестве базы данных доставки контента (CD). Лучше всего иметь отдельный индекс, определенный для каждой базы данных. Таким образом, вам действительно нужно настроить сервер CD на указатель sitecore_pub1_index, а не файл sitecore_web_index.
На ваших серверах CM и CD должна быть настроена база данных pub1. Пример того, что будет выглядеть, будет таким, как этот Sitecore, включая конфигурацию патча. Лучше всего не изменять файл web.config напрямую, если это возможно, и вместо этого использовать include config patch. В этом примере показана исправленная конфигурация, которая будет находиться в вашем каталоге \App_Config\Include:
<configuration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:patch="http://www.sitecore.net/xmlconfig/">
<sitecore>
<databases>
<database id="pub1" singleInstance="true" type="Sitecore.Data.Database, Sitecore.Kernel">
<param desc="name">$(id)</param>
<icon>Network/16x16/earth.png</icon>
<securityEnabled>true</securityEnabled>
<dataProviders hint="list:AddDataProvider">
<dataProvider ref="dataProviders/main" param1="$(id)">
<disableGroup>publishing</disableGroup>
<prefetch hint="raw:AddPrefetch">
<sc.include file="/App_Config/Prefetch/Common.config"/>
<sc.include file="/App_Config/Prefetch/Webdb.config"/>
</prefetch>
</dataProvider>
</dataProviders>
<proxiesEnabled>false</proxiesEnabled>
<proxyDataProvider ref="proxyDataProviders/main" param1="$(id)"/>
<archives hint="raw:AddArchive">
<archive name="archive"/>
<archive name="recyclebin"/>
</archives>
<cacheSizes hint="setting">
<data>20MB</data>
<items>10MB</items>
<paths>500KB</paths>
<itempaths>10MB</itempaths>
<standardValues>500KB</standardValues>
</cacheSizes>
</database>
</databases>
</sitecore>
</configuration>
Затем вы захотите настроить индекс поиска pub1 на обоих серверах CM и CD. Предполагая, что вы используете lucene, чтобы патч config выглядел следующим образом:
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
<sitecore>
<contentSearch>
<configuration type="Sitecore.ContentSearch.ContentSearchConfiguration, Sitecore.ContentSearch">
<indexes hint="list:AddIndex">
<index id="sitecore_pub1_index" type="Sitecore.ContentSearch.LuceneProvider.LuceneIndex, Sitecore.ContentSearch.LuceneProvider">
<param desc="name">$(id)</param>
<param desc="folder">$(id)</param>
<!-- This initializes index property store. Id has to be set to the index id -->
<param desc="propertyStore" ref="contentSearch/databasePropertyStore" param1="$(id)" />
<configuration ref="contentSearch/indexConfigurations/defaultLuceneIndexConfiguration" />
<strategies hint="list:AddStrategy">
<!-- NOTE: order of these is controls the execution order -->
<strategy ref="contentSearch/indexUpdateStrategies/onPublishEndAsync" />
</strategies>
<commitPolicyExecutor type="Sitecore.ContentSearch.CommitPolicyExecutor, Sitecore.ContentSearch">
<policies hint="list:AddCommitPolicy">
<policy type="Sitecore.ContentSearch.TimeIntervalCommitPolicy, Sitecore.ContentSearch" />
</policies>
</commitPolicyExecutor>
<locations hint="list:AddCrawler">
<crawler type="Sitecore.ContentSearch.SitecoreItemCrawler, Sitecore.ContentSearch">
<Database>pub1</Database>
<Root>/sitecore</Root>
</crawler>
</locations>
</index>
</indexes>
</configuration>
</contentSearch>
</sitecore>
</configuration>
Теперь у вас есть база данных базы данных pub1 и настройка индекса поиска. У вас уже должна быть настройка pub1 в качестве удаленной цели публикации в Sitecore. Вы также указали, что параметр EnableEventQueues настроен как true на обоих серверах CM и CD.
Это все, что вам нужно. OnPublishEndAsync будет следить за таблицей EventQueue в вашей базе данных pub1. Когда вы публикуете в своей публичной публикации pub1, вы должны увидеть записи в файле Sitemap Sitecore *.txt вашего CD-сервера с чем-то похожим на это:
ManagedPoolThread #7 23:21:00 INFO Job started: Index_Update_IndexName=sitecore_pub1_index
ManagedPoolThread #7 23:21:00 INFO Job ended: Index_Update_IndexName=sitecore_pub1_index (units processed: )
Примечание. Обработанные единицы никогда не обновляются точно и обычно пусты. Я предполагаю, что это ошибка Sitecore, но никогда не вырывалась настолько, чтобы определить, почему она не отображается в журналах правильно. Вы можете использовать Luke (опять же, если вы используете Lucene), чтобы проверить, что индекс обновлен, как ожидалось.
Ответ 5
Проверьте ваше событие publish:end:remote
и посмотрите, есть ли там какой-либо обработчик. Если да, попробуйте удалить все обработчики, чтобы убедиться, что они не вызывают каких-либо ошибок.
У меня была аналогичная проблема при переходе с Sitecore с 6 по 7. EventArgs
для удаленной публикации в Sitecore 7 отличается. Новый тип PublishEndRemoteEventArgs
.
Ответ 6
Вот решение, которое мы сделали в нашем приложении. У нас есть настройка базы данных Web и Pub и создана добавленная публикацияStrategy, указывающая ее на pub
<onPublishEndAsyncPub type="Sitecore.ContentSearch.Maintenance.Strategies.OnPublishEndAsynchronousStrategy,
Sitecore.ContentSearch">
<param desc="database">pub</param>
<!-- whether full index rebuild should be triggered if the number of items in Event Queue exceeds
Config.FullRebuildItemCountThreshold -->
<CheckForThreshold>true</CheckForThreshold>
</onPublishEndAsyncPub>
в разделе индекса установите вновь созданную стратегию для публикации индекса
<index id="sitecore_pub_index" type="Sitecore.ContentSearch.SolrProvider.SolrSearchIndex, Sitecore.ContentSearch.SolrProvider">
<param desc="name">$(id)</param>
<param desc="core">itembuckets</param>
<param desc="propertyStore" ref="contentSearch/databasePropertyStore" param1="$(id)" />
<strategies hint="list:AddStrategy">
<strategy ref="contentSearch/indexUpdateStrategies/onPublishEndAsyncPub" />
<!--<strategy ref="contentSearch/indexUpdateStrategies/remoteRebuild" />-->
</strategies>
<locations hint="list:AddCrawler">
<crawler type="Sitecore.ContentSearch.SitecoreItemCrawler, Sitecore.ContentSearch">
<Database>pub</Database>
<Root>/sitecore</Root>
</crawler>
</locations>
</index>
Ответ 7
Если вы используете настройки масштабируемости Sitecore, убедитесь, что это правильно.
Причина, по которой индексирование не запускается на ваших CD-серверах, в основном связано с вашей очередью событий. Одна быстрая проверка, которую вы можете выполнить, - это увидеть, есть ли события в таблице EventQueue базы данных Core, в которой говорится, что публикация завершена.
Кроме того, проверьте Sitecore.ContentSearch.config, поскольку, когда публикация закончится, она вызовет индекс перестройки.
Спасибо