Instant updates are a way of adding and removing content from web or filecopy collections between full or incremental updates.
An instant update is initiated in one of the following ways:
- via the admin UI - selecting advanced update and choosing one of the four available start new instant update options (note: web and filecopy collections only).
update.plfrom the command line and specifying an instant update mode.
When the instant update runs new content (generated from one of the add update types) is handled separately to the files associated with the main index. Specifically:
- Data is downloaded to a secondary-data folder (and stored in a MirrorStore, regardless of the storage class specified in the
- Indexes are written to the
live/idxfolder with an index stem of
When content is added to a secondary index a check is made to see if it exists in the current live index and is killed if it found to exist.
An instant delete operation is equivalent to killing the document from the live index.
Instant update phases
Purpose: Add or re-add a site to the index.
Purpose: Remove sites from the index.
Instant document add
Purpose: Add or re-add individual URLs to the index)
Instant document delete
Purpose: Remove individual URLs from the index.
Configuring instant updates
For instant updates to run correctly any workflow commands applied to a normal update need to be configured for the instant update using the equivalent instant update workflow commands applied to the correct instant update phases (as listed above). This means that you will need to add workflow commands for both standard and instant updates.
As a general rule:
- Convert any pre/post_gather commands to pre/post_instant-gather commands and add these to the collection.cfg (leave the existing pre/post commands as these are still needed for normal updates).
- Convert any pre/post_index commands to pre/post_instant-index commands (leave the existing pre/post commands as these are still needed for normal updates).
- Convert any index stems in the added commands to use
- Replace any uses of
$CURRENT_VIEWin the instant update commands with
- Post update (and post swap, pre/post meta depenencies etc) workflow should be run as post instant-index, post delete-prefix and post delete-list commands as instant updates only have the phases listed above (there is no swap, meta dependencies and hence no post-update phase).
# Post index command, runs on normal updates post_index_command=$SEARCH_HOME/bin/padre-gs $SEARCH_HOME/data/$COLLECTION_NAME/$CURRENT_VIEW/idx/index $SEARCH_HOME/conf/$COLLECTION_NAME/gscopes.cfg # Equivalent instant update command post_instant-index_command=$SEARCH_HOME/bin/padre-gs $SEARCH_HOME/data/$COLLECTION_NAME/live/idx/index_secondary $SEARCH_HOME/conf/$COLLECTION_NAME/gscopes.cfg
The following admin UI permission can be used to provide access to instant updates:
An administration interface user must be granted this permission in order to have access to instant updates. This is achieved by editing the user's .ini file (located under
When editing the .ini file the user type must also be set to custom.
# Allow access to instant updating in the admin UI sec.instant.update = yes
Logs and indexes
- High level update messages are written to the standard
- Detailed logs are written to the collection's
- Indexes are written to the collection's
live/secondary-indexfolder while being built (a bit like offline) then moved to the live/idx folder with a stem of
- It is not possible to start and instant update if the collection is already updating.
- Running an instant update will lock the collection from updating (so a standard update, or other instant updates can't be run while an instant update is running).
- Instant updates apply only to web and filecopy collections.