On 8/1/2011 12:42 PM, Paul Libbrecht wrote:
Otherwise i need to backup the whole index and try to reindex
overnight when
cms users are sleeping.
With some work you can do this using an extra solr that just pulls everything,
then swaps the indexes (that needs a bit of downtime), then re-indexes the
things changed during the night.
I feel this should be a standard feature of SOLR...
It sort of is, in the sense that you can do it with replication, with no
downtime. (Although you'll need enough disk and RAM in the slave to warm
the replicated index while still serving queries from the older index,
for no downtime).
Reindex to a seperate solr (or seperate core), then have the actual
production core set up as a slave, and have it replicate from master
when the re-indexing is done. You can have your relevant conf files
(schema or solrconfig) set up to replicate too, so you get those new
ones in production exactly when you get the new indexes they go with.
The replication features isn't exactly set up for this, so it gets a bit
confusing. I set up the 'slave' with NO polling. It still needs to be
set up with config saying it's a slave though. And it still needs to
have a 'master' URL in there, even though you can also supply/over-ride
the master URL with a manual replicate command, if there's no master URL
at all, Solr will refuse to start up. So I config the master URL, but
without any polling for changes. Then I manually issue an HTTP replicate
command to slave only when I have a rebuilt index in master I want to
swap in. It seems to be working.
