You're not missing anything that I know of. The best I've been able to come
up with so far is to treat the disparate DCs as separate clusters. Your
ingestion process needs to know enough to send updates to both DCs but
that's the only point of contact.
The problem I see here is not only with inter-DC communications, but ZK.
Let's say ZK1 is in DC1 and ZK2 and ZK3 are in DC2. Now anytime the
connection is lost, DC1 is down since it can't sense a ZK quorum. I know
of one person who put the ZK nodes in three separate DCs to help with that
problem.
But the bottom line is that SolrCloud chatters amongst nodes and you have
no good ways to control it. Either you have to accept the latency between
DCs or use separate clusters as far as I know. I do know there's some JIRAs
about making SolrCloud rack aware which may address this, but I don't
think they're in place yet.
Best
Erick
On Tue, Feb 5, 2013 at 10:17 AM, Michael Tracey mtra...@biblio.com wrote:
Hey all, new to Solr 4.x, and am wondering if there is any way that I
could have a single collection (single or multiple shards) replicated into
two datacenters, where only 1 solr instance in each datacenter communicate.
(for example, 4 servers in one DC, 4 servers in another datacenter and
only one in each DC communicate).
From everything I've seen, all zookeepers and replicas must have access to
all other members. Is there something I'm missing?
Thanks,
M.
