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, поскольку, когда публикация закончится, она вызовет индекс перестройки.

Спасибо