lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <>
Subject Re: Solr Architecture discussion
Date Mon, 14 Jun 2010 19:44:11 GMT

: B- A backup of the current index would be created
: C- Re-Indexing will happen on Master-core2 
: D- When Indexing is done, we'll trigger a swap between Master-core1 and
: core2
: But how can B,C, and D. I'll do it manually. Wait! I'm not sure my boss will
: pay for that.

: 1/Can I leverage on some solr mechanisms (that is, by configuration only) in
: order to reach that goal?
: I haven't found how to do it!

your best bet is some external scheduler -- depending on how your build 
process works, you can fairly easily integrate it into external 
publishing tools.

: 2/ Is there any issue while replicating master "swapped" index files? I've
: seen in the literature that there might be some issues.

As long as the "new" version of the index is treuly "newer" then the old 
version, there shouldn't be any problem.

Frankly though: i'm not sure you need core swapping on the master either 
-- it depends largely on how much "churn" will happen each time you do one 
of these full rebuilds.  you could just as easily do incremental 
reindexing on your master, with occasional commits (or even autocommits) 
nad your slaves picking up those new segments -- either gradually, or all 
at once when you do a monolithic commit. 

if you're ok with the slaves pulling over the *entire* index after you do 
the core swap, then you should be fine with the slaves pulling over the 
*entire* index (or maybe just most of it) after a rebuild directly to the 
existing core.

all you really need to do explicitly on the master is trigger a backup 
just before you rebuild the world, and if (and only if) something goes 
terribly wrong, then restore from your backup.


View raw message