The sticky parts of that solution (off the top of my head) are > assuring that the two masters have all the updates. How do you guarantee that > the updates succeed and the two masters do, indeed, contain the exact same > information?
> There'd have to be logic to insure that when the switch was made, the entire > index was replicated. How would the slave know which segments to replicate > from the master? Especially since the segments would NOT be identical, the > slaves would have to replicate the entire index... > What to do when the first master came back up? Which one should be the "one > true source"? > The whole question of all the slaves knowing what master to ping is actually > pretty ambiguous. What happens if slave 1 pings master1 and there's a > temporary network glitch so it switches to master2. Meanwhile, due to timing, > slave2 thinks master1 is still online. How to detect/track this? When you start to spin these scenarios, you start needing some kind of cluster state accessible to all slaves, and then you start thinking about ZooKeeper and you're swiftly back to SolrCloud. The thinking in traditional Solr M/S situations avoids having two masters, if a master dies you "promote" one of the slaves to be the new master. The tricky bit here is to re-index data from before the time the old master died to the new master. So far, that's been "good enough" for M/S setups, and then SolrCloud came along so I suspect not much effort would be put into something like what you suggest; the effort should be towards hardening SolrCloud... Best, Erick On Tue, Jun 17, 2014 at 6:54 AM, Alessandro Benedetti <[email protected]> wrote: > Hello Arcadius, > why not simple moving to SolrCloud that already addresses fault tolerance > and high availability ? > Simply imagine a configuration of : > 1 shard, factor of replciation 3. > And you have even a better scenario than 2 masters and 1 slave. > > Cheers > > > 2014-06-17 14:43 GMT+01:00 Arcadius Ahouansou <[email protected]>: > >> Hello. >> >> >> SolrCloud has been out for a while now. >> >> However, there are still many installations running Solr4 in the >> traditional master-slave setup. >> >> >> Currently, the Solr Master is the single point of failure of most >> master-slave deployment. >> >> This could be easily addressed by having : >> >> >> a- 2 independents Solr Masters running side-by-side and being fed >> simultaneously, >> >> b- all slaves configured with masterUrl=masterUrl01,masterUrl02 (needs to >> be implemented) >> >> c- by default, masterUrl01 will be used by all slaves. >> >> d- When the slaves catch an exception (like NoRouteToHostException or >> ConnectionTimedOutException etc), they will retry a couple of times before >> switching to using masterUrl02. >> >> >> I suppose you have thought about this issue before. >> >> So I would like to know whether there are issues with such a simple >> solution. >> >> This could also help deploy Solr across 2 different data-centers. >> >> >> Thank you very much. >> >> >> Arcadius. >> >> > > > > -- > -------------------------- > > Benedetti Alessandro > Visiting card : http://about.me/alessandro_benedetti > > "Tyger, tyger burning bright > In the forests of the night, > What immortal hand or eye > Could frame thy fearful symmetry?" > > William Blake - Songs of Experience -1794 England --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
