If you have to stay on master/slave, then the full replication when you do this switch is probably just a price you'll have to pay. The indexes are different so to be on the safe side Solr will replicate the whole thing.
Is it really that much of a problem? As Shawn says, though, much of this would be simpler with SolrCloud. Best, Erick On Fri, Feb 12, 2016 at 1:06 PM, Shawn Heisey <[email protected]> wrote: > On 2/12/2016 11:47 AM, Novin Novin wrote: >> I think I didn't explain it quit properly. So I have situation in which >> data is getting index every 20 seconds or less and I can't loose data while >> indexing. I use searching a lot in website, if I have to restart my solr >> machine because of kernel update or some network problem or some another >> reason (not really in top of my head). It takes a while to restart, while >> it is restarting some body is using website feature which require data to >> be indexed and display results after request completed. In this situation, >> if I loose the data I have to do full index (because I am using solrj it >> takes 3 to 4 hours, so this not ideal). That's why I am doing switching >> between >> master and slave. > > If you switched to SolrCloud, you wouldn't have to worry about switching > masters -- there *are* no masters or slaves. With a proper replicated > setup, any single machine in the cloud can go down, or have maintenance > performed, with no visible impact on SolrJ clients using > CloudSolrClient. When the Solr instance comes back up, it will > automatically resync from the cloud. > > If you're using non-SolrJ clients, you'd just need to put a load > balancer in front of your SolrCloud cluster and there would be no > downtime for failures or maintenance. > > SolrCloud is a little bit more difficult to set up initially, and > requires at least three physical servers, but once it's running, it is > typically *easier* to manage than master/slave. > > Thanks, > Shawn >
