I am not sure of any substantial advantage to the monitor and restart trick over observers. As far as I can tell, it mostly just makes the majority more delicate. The minority still has to send updates through to the other data center.
On Fri, Sep 28, 2012 at 10:57 AM, Camille Fournier <[email protected]>wrote: > If these nodes in the remote DC just need to read, you can do this via > observers in the remote DC. If they need to write as well, you're in a > tough spot. If most of the clients will be in one data center, I would > favor keeping a majority of nodes in that datacenter and forcing the master > to be there (via monitoring and restarting as necessary), so that you can > get votes locally and have mostly faster writes. Otherwise you're just > going to have a slower cluster than is optimal but that's the tradeoff for > supporting two datacenters. > > C > > On Fri, Sep 28, 2012 at 12:13 AM, Ishaaq Chandy <[email protected]> wrote: > > > Hi all, > > We're in the process of understanding the implications of splitting some > of > > the nodes of our system into a different DC. The DC will be situated in a > > different continent to be geographically closer to some of our clients - > > for network latency reasons. > > > > Anyway, we're trying to work out how work with our ZK cluster in this > > scenario. The way I see it we have 2 options: > > > > 1. Leave our existing ZK cluster as is on our primary DC, make the nodes > on > > the new DC make the hop to do comms with it > > 2. Add a couple of new local ZK nodes to the new DC and let all them sort > > out the comms between them and the rest of the ZK cluster back in the > > primary DC > > > > I am leaning towards the latter option but was wondering if any of you > have > > any insights/experiences in this area that might help us make an informed > > decision. > > > > Thanks, > > Ishaaq > > >
