If nothing else, the disk underlying the index could have a bad spot... There have been some corrupt index bugs in the past, but they always get a super-high priority for fixing so don't hang around for long.
You can always take periodic backups. Perhaps the slickest way to do that is to set up a slave that does nothing but poll once/day. Since you know that's not changing, you can do simple disk copies of the index and at least minimize your possible outage. Now, all that said you may wan to consider SolrCloud. The advantage there is that each node gets the raw input and very rarely does replication. Failover is as simple in that scenario as killing the bad node and things "just work". Best, Erick On Tue, Dec 2, 2014 at 7:40 AM, Charra, Johannes <johannes.charrahorstm...@haufe-lexware.com> wrote: > Thanks for your response, Erick. > > Do you think it is possible to corrupt an index merely with HTTP requests? > I've been using the aforementioned m/s setup for years now and have never > seen a master failure. > > I'm trying to think of scenarios where this setup (1 master, 4 slaves) might > have a total outage. The master runs on a h/a cluster. > > Regards, > Johannes > > -----Ursprüngliche Nachricht----- > Von: Erick Erickson [mailto:erickerick...@gmail.com] > Gesendet: Dienstag, 2. Dezember 2014 15:54 > An: solr-user@lucene.apache.org > Betreff: Re: Replication of a corrupt master index > > No. The master is the master and will always stay the master unless you > change it. This is one of the reasons I really like to keep the original > source around in case I every have this problem. > > Best, > Erick > > On Tue, Dec 2, 2014 at 2:34 AM, Charra, Johannes > <johannes.charrahorstm...@haufe-lexware.com> wrote: >> >> Hi, >> >> If I have a master/slave setup and the master index gets corrupted, will the >> slaves realize they should not replicate from the master anymore, since the >> master does not have a newer index version? >> >> I'm using Solr version 4.2.1. >> >> Regards, >> Johannes >> >>
