Simply turn off replication during your rebuild-from-scratch. See: http://wiki.apache.org/solr/SolrReplication#HTTP_API the "disabelreplication" command.
The autocommit thing was, I think, in reference to keeping any replication of a partial-rebuild from being replicated. Autocommit is usually a fine thing. So your full-rebuild looks like this 1> disable replication on the master 2> rebuild the index (autocommit on or off, makes little difference as far as replication) 3> enable replication on the master Best Erick On Tue, May 1, 2012 at 8:55 AM, geeky2 <gee...@hotmail.com> wrote: > hello shawn, > > thanks for the reply. > > ok - i did some testing and yes you are correct. > > autocommit is doing the "commit" work in chunks. yes - the slaves are also > going to having everything to nothing, then slowly building back up again, > lagging behind the master. > > ... and yes - this is probably not what we need - as far as a replication > strategy for the slaves. > > you said, you don't use autocommit. if so - then why don't you use / like > autocommit? > > since we have not done this here - there is no established reference point, > from an operations perspective. > > i am looking to formulate some sort of operation strategy, so ANY ideas or > input is really welcome. > > > > it seems to me that we have to account for two operational strategies - > > the first operational mode is a "daily" append to the solr core after the > database tables have been updated. this can probably be done with a simple > delta import. i would think that autocommit could remain on for the master > and replication could also be left on so the slaves picked up the changes > ASAP. this seems like the mode that we would / should be in most of the > time. > > > the second operational mode would be a "build from scratch" mode, where > changes in the schema necessitated a full re-index of the data. given that > our site (powered by solr) must be up all of the time, and that our full > index time on the master (for the moment) is hovering somewhere around 16 > hours - it makes sense that some sort of parallel path - with a cut-over, > must be used. > > in this situation is it possible to have the indexing process going on in > the background - then have one commit at the end - then turn replication on > for the slaves? > > are there disadvantages to this approach? > > also - i really like your suggestion of a "build core" and "live core". is > this approach you use? > > thank you for all of the great input > > > > > then > > > -- > View this message in context: > http://lucene.472066.n3.nabble.com/should-slave-replication-be-turned-off-on-during-master-clean-and-re-index-tp3945531p3952904.html > Sent from the Solr - User mailing list archive at Nabble.com.
