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: [email protected] [mailto:[email protected]] 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 <[email protected]> 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 [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
