[infinispan-dev] X-datacentre replication: design suggestions

Bela Ban bban at redhat.com
Fri Feb 10 10:47:07 EST 2012


I'm going to comment via this mailing list, and we can later summarize 
and append to the wiki (I don't like discussions on the wiki... :-))...

#1 Virtual cluster

Rehashing:

I believe we'll have to come up with a custom consistent hash that knows 
about the 2 sites, and places all of the data owners into the local 
site. E.g. it would be bad if we create a key K in LON and make the 
primary owner T (in SFO) and the backup owner B in LON !
This should also minimize rehashing across sites, and prefer rehashing 
within sites.

In terms of data access, the idea is that all writes would only go 
through 1 site, e.g. LON being active and SFO being a backup (in which 
reads could happen); my design didn't assume concurrent writes in 
multiple sites (at least not to the same data).

Locking:

Same as above

Configuration:

numOwners would have to be extended, e.g. we could introduce a property 
numPrimarySiteOwners=2 and numBackupSiteOwners=1, TDB


#2 Hot Rod based

Having to connect to potentially all nodes is bad, as customers possibly 
only want to open 1 port for cross-datacenter traffic.

I assume the RemoteCacheStore would have to be enabled in all nodes in a 
given site for this to work ?

How would you handle requests sent during the crash of a HotRod endpoint 
? Would they get queued, similar to 
https://issues.jboss.org/browse/JGRP-1401 ?

How would initial state transfer be done between sites ? E.g. LON has 
been up for 2 days and now we start SFO. Does that mean we will 
effectively have to transfer *all* of the data in LON --> SFO ?


#3 Custom bridge

I like the fact that both sites are configured with possibly different 
numOwners, e.g. LON=2 and SFO=1

This will not work if you need to invoke blocking RPCs between sites: 
the copying of traffic to A is always assumed to be asynchronous. Plus, 
the recipient in SFO wouldn't know the original sender; in the example, 
the sender would always be X.

How do you handle the case where the relay (A or X) crashes and messages 
are sent during that time, before a new relay is elected ?

How do you do state transfer, e.g. bootstrap SFO from LON ? I guess you 
transfer the entire state from LON --> SFO, right ?




SUMMARY:

I would definitely *not* do #2.
I do like #3 and #1, perhaps we need to focus a bit on #3, to see if 
there are other deficiencies we haven't seen yet, as I'm already 
familiar with #1.

Cheers,


On 2/10/12 4:02 PM, Mircea Markus wrote:
> Hi,
>
> I've starte a document[1] that contains 3 possible approaches for implementing the X-datacentre replication functionality.
> This is a highly requested bit of functionality for 5.2 and involves interaction between several components: e.g. state transfer, transactions hotrod, jgroups etc. Can you please take a look and comment?
>
> [1] https://community.jboss.org/wiki/CrossDatacenterReplication-Design


-- 
Bela Ban
Lead JGroups (http://www.jgroups.org)
JBoss / Red Hat


More information about the infinispan-dev mailing list