: 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.
-Hoss
