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 >
