Hi, I believe the way to go is through ZooKeeper[1], not property files or local hacks. We've already started on this route and it makes sense to let ZK do what it is designed for, such as leader election. When a node starts up, it asks ZK what role it should have and fetches corresponding configuration. Then it polls ZK regularly to know if the world has changed. So if a master indexer goes down, ZK will register that as a state change condition, and next time one of the indexer slaves pings ZK, it may be elected as new master, and config in ZK is changed correspondingly, causing all adds to flow to the new master...
Then, when the slaves cannot contact their old master, they ask ZK for an update, and retrieve a new value for master URL. Note also that SolrCloud is implementing load-balancing and sharding as part of the arcitecture so often we can skip dedicated LBs. [1] : http://wiki.apache.org/solr/SolrCloud -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com On 15. des. 2010, at 18.50, Tommaso Teofili wrote: > Hi all, > me, Upayavira and other guys at Sourcesense have collected some Solr > architectural views inside the presentation at [1]. > For sure one can set up an architecture for failover and resiliency on the > "search face" (search slaves with coordinators and distributed search) but > I'd like to ask how would you reach transparent redundancy in Solr on the > "index face". > On slide 13 we put 2 slave backup masters and so if one of the main masters > goes down you can switch slaves' replication on the backup master. > First question if how could it be made automatic? > In a previous thread [2] I talked about a possible solution writing the > master url of slaves in a properties file so when you have to switch you > change that url to the backup master and reload the slave's core but that is > not automatic :-) Any more advanced ideas? > Second question: when main master comes up how can it be automatically > considered as the backup master (since hopefully the backup master has > received some indexing requests in the meantime)? Also consider that its > index should be wiped out and replicated from the new master to ensure index > integrity. > Looking forward for your feedback, > Cheers, > Tommaso > > [1] : http://www.slideshare.net/sourcesense/sharded-solr-setup-with-master > [2] : http://markmail.org/thread/vjj5jovbg6evpmpp
