History: Rebuild Unified Index

Source of version: 7 (current)

Periodically rebuilding your ((Search and List from Unified Index|Unified Index)) is a best practice.

((Cron Job to Rebuild Search Index)) should merge with current page.

Tiki is applying filters (and partially permissions to view) and in some case reading directly information from the Unified-Index. This allow very good performances and a lot of flexibility. Therefor, it is important to keep a fresh Unified-Index. ((Features)) but also ((plugins)) and ((modules)) will also relies on the freshness of the Unified-Index to display updated content (pages content, items, user informations, etc).

You can see when the index was last fully rebuilt usually by start a rebuild process from he Tiki interface (see below). 

In recent Tiki version the index is stored in the database and you can rebuild (refresh) the Unified-Index with different method. 

!!! From the Tiki interface
It is possible to rebuild the Unified-Index from a browser. However due to possible timeout during long operation it is recommended to do this ONLY on relatively small Tiki (based on the number and the size of your Tiki objects). For medium to high load sites, it is strongly recommended do that operation from the command line (much less limited), see the next paragraph.

* From the admin dashboard, on the main tiki menu click on the item Control Panels, then click on the Search panel. At the top of the page you will find a __Rebuild Index__ button.
* From your URL address bar tiki-admin.php?page=search&rebuild=now

!!! From the command line
The search index can be rebuilt manually from the command line or you can use the Tiki ((Scheduler)) since ((Tiki17))  - see [Scheduler#Rebuild_the_Unified-Index_with_log|Rebuild the Unified Index with log sample] or a ((Cron)) job since ((Tiki9)) to runs the command automatically - see ((Cron Job to Rebuild Search Index)).

Below are the commands that may be used to rebuild the index. Check ((Console)) documentation.
{REMARKSBOX(type=note title=Note)}These commands need to be run as the web server user when using the Lucene implementation, often ''www-data'' or ''nobody'' depending on your server setup, otherwise the web server cannot update and maintain the index. This means prepending the following commands with "''sudo -u www-data ''".{REMARKSBOX}

{REMARKSBOX(type=note title=Note)}''All commands below assume you are already in the Tiki root directory.''{REMARKSBOX}

You can also rebuild it using the unified {DIV(type=span class=inline_syntax)}console.php{DIV} command, with the appropriate parameters. For example:

!!!! Basic command
{CODE()}
php console.php index:rebuild

<-- or -->

php console.php i:r

<-- or add visual verbose, to follow what is going on -->

php console.php i:r -p

{CODE}
{REMARKSBOX(type=note title=Note)}''The syntax "i:r" is equivalent to "index:rebuild".''{REMARKSBOX}

!!!!Multitiki sites
For multitiki sites, you can rebuild with commands like:
{CODE(colors="perl")}
php console.php index:rebuild --site=site1.example.com  
php console.php index:rebuild --site=site2.example.com  
...
{CODE}

!!!! Successful rebuild
If the rebuild is successful a message like the following will be produced (for cron jobs, this can usually be sent to you via email as part of automatically running the command):
{CODE()}
 Started rebuilding index...

Unified search
--------------

Engine: MySQL, version 5.7.34
Indexed
  trackeritem: 210
  tracker: 13
  trackerfield: 104
  article: 67
  file: 285
  file gallery: 20
  comment: 0
  user: 8
  group: 7
  wiki page: 55
  category: 18
Rebuilding index done
Index: index_6291d4b25591f

Execution Statistics
---------------------

Execution time: 16 secs
Current Memory usage: 51.0 MiB
Memory peak usage before indexing: 22.5 MiB
Memory peak usage after indexing: 51.2 MiB
Number of queries: 12383
{CODE}

!!!! Relations Tracker field
If you use the ((Relations Tracker Field)), and are starting from an empty index, you should probably rebuild twice.

!!!! Troubleshooting
If the rebuild is unsuccessful, instead of the above message you may get a message that indicates there has been an internal server error, or it may say "Rebuild in progress." This may be because the rebuild process uses more memory or takes more time than allowed by the server's php settings. Such settings can be changed on the fly as part of the rebuild command - examples of how to do this are shown below. 

!!!!! Not enough memory
__Increase memory limit__
One way to increase memory is to change the {DIV(type=span class=inline_syntax)}memory_limit{DIV} php setting as follows (this example changes the memory limit to 4 gigabytes while the rebuild process is running):
{CODE()}
php -dmemory_limit=4G console.php i:r --log
{CODE}
You could also direct php to use a specific {DIV(type=span class=inline_syntax)}php.ini{DIV} file, where there may be a higher memory limit setting or no limit. In this case you would use the {DIV(type=span class=inline_syntax)}-c{DIV} parameter followed by the path to the {DIV(type=span class=inline_syntax)}php.ini{DIV} file, as in the example below:
{CODE()}
php -c /etc/php5/cli/php.ini console.php i:r --log
{CODE}

!!!!! Timeout error
__Increase maximum execution time__
Getting an internal server error may indicate the rebuild process takes longer than the {DIV(type=span class=inline_syntax)}max_execution_time{DIV} php setting. That can be increased as part of the command as shown below where the max execution time is set to 300 seconds, or 5 minutes. (This command is also increasing the memory limit as described above):
{CODE()}
php -dmemory_limit=4G -dmax_execution_time=300 console.php i:r --log
{CODE}

!!!!! Force rebuild
When the rebuild is unsuccessful with a "Rebuild in progress" message, this usually means that the rebuild failed previously in the middle of the process, leaving a temporary folder called {DIV(type=span class=inline_syntax)}temp/unified-index-new{DIV} on the server. When a new rebuild is started and the program sees this folder, it thinks there is a rebuild already in progress and will stop. You can either delete this folder before rebuilding again or include the {DIV(type=span class=inline_syntax)}--force{DIV} parameter in the rebuild command as follows:
{CODE()}
php -dmemory_limit=4G -dmax_execution_time=300 console.php i:r --force --log
{CODE}

!!!!! Log to review possible problems with content
{CODE()}
php console.php i:r -p --log
{CODE}

!!!!! Several index_ files in the database
Typically happening when using the same database over and over you may end with several indexes in your database.
We provide a developer tool to clean properly this issue.
You need to be the web user and use bash to run the script.
{CODE()}
bash doc/devtools/clear_mysql_search_indexes.bash
{CODE}

You need to rebuild your index after the operation.

!!!! Deprecated Zend_Search_Lucene
With the now deprecated Zend_Search_Lucene, the unified-index is stored in your Tiki directory -+temp/unified-index/+-. While the rebuild is occurring, a directory -+temp/unified-index-new/+- will appear (This is to permit the existing index to be used until the new one is ready). If -+temp/unified-index-new/+- doesn't disappear after the indexing, something must have gone wrong. You can delete it and try the re-indexing again. You may want to run ''sh setup.sh'' to make sure the permissions are OK.

!!! Too many fields
* ((Exclude some fields from the unified index))


-=alias names for this page=-
(alias(IndexRebuild)) | (alias(Index Rebuild))