I've just done a bit of playing here, because I've spent a lot of time reading the SolrReplication wiki page[1], and have often wondered how some features interact.
Unfortunately, if you specify <str name="enable">false</str> in your replication request handler for your master, you cannot re-enable it with a call to /solr/replication?command=enablereplication Therefore, it would seem your best bet is to call /solr/replication?command=disablepolling on all of your slaves prior to upgrading. Then, when you're sure everything is right, call /solr/replication?command=enablepolling on each slave, and you should be good to go. I tried this, watching the request log on my master, and the incoming replication requests did actually stop due to the disablepolling command, so you should be fine with this approach. Does this get you to where you want to be? Upayavira On Wed, 22 Dec 2010 17:10 +0000, "Francis Rhys-Jones" <francis.rhys-jo...@guardian.co.uk> wrote: > Hi, > > I am looking into using a multi core configuration to allow us to > fully rebuild our index while still applying updates. > > I have two cores main-core and rebuild-core. I push the whole dataset > into the rebuild core, during which time I can happily keep pushing > updates into the main-core. Once the rebuild is complete I swap the > cores and delete *:* from the rebuild core. > > This works fine however there are a couple of edge cases: > > On server restart solr needs to remember which core has been swapped > in to be the main core, this can be solved by adding the > persistent=true attribute to the solr config, however this does > require the solr.xml to be writeable. > > While deploying a new version of our application we overwrite the > solr.xml, as the new version could potentially have legitimate changes > to the solr.xml that need to be rolled out, again leaving the cores > out of sync. > > My proposed solution is to have the indexing process do some sanity > checking at the start of each run, and swap in the correct core if > necessary. > > This works however there is the potential for the slaves to start > replicating the empty index before the correct index is swapped in. > > To get round this problem I would like to have replication disabled on > start up. > > Removing replicateAfter=startup has this affect but it would be more > future proof to be able to specify a default for the > replicationEnabled field (see SOLR-1175) in the ReplcationHandler, > stopping replication until I explicitly turn it on. > > The change looks fairly simple. --- Enterprise Search Consultant at Sourcesense UK, Making Sense of Open Source
