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

Hi Mircea I think you're missing an intro section with the use cases we want to handle in 5.2. The requirements for having a backup datacenter that isn't accessed by any clients are pretty different from the requirements for multiple "primary" datacenters that are all handling requests at the same time, so we should have a clear image of what we are trying to achieve.

On Fri, Feb 10, 2012 at 5:47 PM, Bela Ban <bban(a)redhat.com&gt; wrote: > 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. > For some use cases I would think it's essential that the data is replicated in both sites (async, of course). But I second the idea that there must be at least one backup in the same site as the primary owner, or rehashes become really expensive.

> 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).

> I like the idea of designating one site as the "master", but I'm pretty sure we want to handle use cases where there is more than one master.

Perhaps we could incorporate Erik's suggestion on the wiki and allow the selection of a master site both at a cache level and at a key level.