Re: [infinispan-dev] Use cases for x-datacenter replication
Sitting here at an architectural summit, there is one point of clarification
-- the clients reside on a separate network from the data centers. So it is
possible to lose a data center without losing the clients; they will simply
route to another data center.
In that case, there will be a notion of promotion of a data center as a
primary key owner, which has its own set of implications (i.e. needs to be
more local copies, etc). And that means some sort of "fail back" once the
original data center comes back online after any versioning merge occurs.
(Does this make sense?)
Erik
-----Original Message-----
From: infinispan-dev-bounces(a)lists.jboss.org
[mailto:infinispan-dev-bounces@lists.jboss.org] On Behalf Of Dan Berindei
Sent: Tuesday, February 14, 2012 4:45 AM
To: infinispan -Dev List
Subject: Re: [infinispan-dev] Use cases for x-datacenter replication
On Mon, Feb 13, 2012 at 11:16 PM, Erik Salter <an1310(a)hotmail.com> wrote:
- My comment about a quorum has to do with the physical network being
down
between data centers in a virtual cluster scenario. In my use case, the
clients would only be able to talk to their local data centers anyway. If
I
have appropriate coverage on my local site (and any other data center
I'm
connected to), I don't necessarily want to start a state transfer. Any
deltas can be pushed to the other sites when they come back online.
Erik, bringing up the connection between two datacenters would trigger
a merge, not a join.
So each datacenter will think it is the "old" primary owner of the
data, and the backup site will try to overwrite the data in the
primary site.
In order to handle this case we also need a versioning scheme that
rejects outdated data from the backup datacenters and instead updates
the backups' data with the primary's values. (Of course, to make
things more complicated, in your scenario each datacenter is primary
for one slice of the data and backup for another slice.)
Cheers
Dan
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev