Aside from the latency, how would you deal with the Zookeeper quorum? Say DC1 had ZK1 and ZK2, and DC2 had ZK3.
Now anytime any server in DC2 can't talk to DC1, there is no Zookeeper quorum. So if DC1 goes down, having nodes in DC2 doesn't do you any good since theres no ZK quorum. I guess things would continue along if DC2 went down, but that's equivalent to depending on DC1 being up all the time...... At least that's my understanding, but things I don't know about ZK are legion....... Best Erick On Tue, Jan 22, 2013 at 5:11 PM, Markus Jelsma <markus.jel...@openindex.io> wrote: > Hi, > > Regarding availability; since SolrCloud is not DC-aware at this moment we > 'solve' the problem by simply operating multiple identical clusters in > different DCs and send updates to them all. This works quite well but it > requires some manual intervention if a DC is down due to a prolonged DOS > attack or netwerk of power failure. > > I don't think it's a very good idea to change clusterstate.json because Solr > will modify it when for example a node goes down. Your preconfigured state > doesn't exist anymore. It's also a bad idea because distributed queries are > going to be sent to remote locations, adding a lot of latency. Again, because > it's not DC aware. > > Any good solution to this problem should be in Solr itself. > > Cheers, > > > -----Original message----- >> From:Timothy Potter <thelabd...@gmail.com> >> Sent: Tue 22-Jan-2013 22:46 >> To: solr-user@lucene.apache.org >> Subject: Manually assigning shard leader and replicas during initial setup >> on EC2 >> >> Hi, >> >> I'm wanting to split my existing Solr 4 cluster into 2 different >> availability zones in EC2, as in have my initial leaders in one zone and >> their replicas in another AZ. My thinking here is if one zone goes down, my >> cluster stays online. This is the recommendation of Amazon EC2 docs. >> >> My thinking here is to just cook up a clusterstate.json file to manually >> set my desired shard / replica assignments to specific nodes. After which I >> can update the clusterstate.json file in Zk and then bring the nodes >> online. >> >> The other thing to mention is that I have existing indexes that need to be >> preserved as I don't want to re-index. For this I'm planning to just move >> data directories where they need to be based on my changes to >> clusterstate.json >> >> Does this sound reasonable? Any pitfalls I should look out for? >> >> Thanks. >> Tim >>
