How to rebuild a Lucene custom index on a Sitecore content delivery server?

Question

The Lucene user index on my Sitecore 6.2 content delivery server seems incorrect. Therefore, I think I need to rebuild all 3 of my custom indexes. How can I do it? Do I just need to use the general Index Viewer module? Now I have it installed on my CD server, but for some reason it does not work. When I select my index in the Index Viewer, nothing happens. Therefore, I cannot rebuild the index this way. Can I just delete index files from the hard drive? If so, how quickly will Lucene rebuild them?

Answer 1

In the end, I contacted Sitecore support, and they pointed me to a common source module called Sitecore Support Toolbox - http://marketplace.sitecore.net/en/Modules/Sitecore_Support_Toolbox.aspx . Once I installed this, I was able to easily rebuild my indexes.

Answer 2

Since Sitecore 6.6 is updating 3 or 4 (don’t remember which one was), you can rebuild your custom indexes from the Sitecore control panel .

In all previous versions, you need to rebuild it from the code or using custom modules for Sitecore . Deleting index files will not work.

The easiest code to restore a custom Sitecore Lucene Index :

Sitecore.Search.SearchManager.GetIndex("your_index_name").Rebuild() 

The Sitecore Lucene Search and Index Search blog post can help you if rebuilding the index doesn't solve your problem.

Answer 3

As noted above, earlier versions of Sitecore 6.x required custom indexes to be rebuilt using IndexViewer or some kind of custom code. I believe that in version 6.5 a control panel was created> Database> Search perestroika indices, including custom indexes, so IndexViewer is no longer needed (but should work).

To your specific question, although on my CD servers I have a rebuild script that can be called directly to rebuild search indexes. I forgot where I found this script (I believe it was something posted by Alex Sheba in Sitecore). You can find the details of this script at https://gist.github.com/Refactored/6776801

However, I believe that you have another problem that needs to be resolved. If your CD servers do not detect changes and therefore are not updated, you have a configuration problem. I will start with this article in troubleshooting index issues: http://sitecoreblog.alexshyba.com/2011/04/search-index-troubleshooting.html

Answer 4

In one of my projects, I came across the same requirement. Here is my solution:

• Create a configuration content item with a template that has only one field, for example, " Restructuring Index ", the default value is "1", an example of the path of the item could be: " / sitecore / content / mysite / config / index rebuild flag
• Create an IndexRebuilder class with the Run method. In the Run method, select the " index rebuild index " checkbox (from the Context database) and rebuild the index on the server if the value of the Restore index field is "1". After successful recovery, update the item field value to "0".

• Configure a designated agent that points to the IndexRebuilder class. For instance,

  <agent type = "MyAssembly.IndexRebuilder, MyAssembly" method = "Run" interval = "00:00:00" />

  Please note that the interval “00:00:00” by default disables the agent on the content management server. The build and deployment process must include this value to say “00:05:00,” which allows the agent to run every 5 minutes.

From there, to rebuild the index on the content delivery server, simply publish the " index rebuild flag " element from the main database to the content delivery database (network), and the index on the content delivery server should start recovery in 5 minutes.

Answer 5

Clicking on the Index Viewer doesn’t happen, it usually indicates specific Index Viewer package files that have not been deployed to your CD server. The simplest fix for this — if you have / sitecore running on a CD server — is simply to reinstall the package directly on the CD server. After that, IndexViewer will work.

If your CD-server does not have / sitecore (Sitecore recommends deleting this or at least blocking access to it) - this becomes more problematic. I would recommend installing the / webservice page or the like by executing the code suggested by Maras above - this way you can always initiate index recovery when you need it.