3:06 p.m.
Hi,
This[1] is the first draft of the cross-site (x-s)[2] replication bela and I came with.
Any feedback is more than welcomed!
Cheers,
Mircea
[1] https://gist.github.com/3059621
[2] we've also thought of using the term 'site' instead of
'datacenter'. Dataceneter is a bit too specific, not as concise and also
inconsistent with the term 'site' we've been using for the
TopologyAwareConsistentHash.
10:49 a.m.
It looks very interesting Mircea.
Do you plan to support update operations on remote backups? May be you
have already some additional design documentation on this feature?
Cheers,
Paolo
On 7/6/12 2:06 PM, Mircea Markus wrote:
Hi,
This[1] is the first draft of the cross-site (x-s)[2] replication bela and I came with.
Any feedback is more than welcomed!
Cheers,
Mircea
[1] https://gist.github.com/3059621
[2] we've also thought of using the term 'site' instead of
'datacenter'. Dataceneter is a bit too specific, not as concise and also
inconsistent with the term 'site' we've been using for the
TopologyAwareConsistentHash.
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
11:03 a.m.
On 07/07/2012 09:49, Paolo Romano wrote:
It looks very interesting Mircea.
Do you plan to support update operations on remote backups? May be you
have already some additional design documentation on this feature?
Thanks Paolo.
We've thought about it but it is out of scope for now. In the initial
version we only allow data to be written on the one (active) site, the
backup acting as a read-only hot standby. Each site can act as active
for a certain dataset(cache) and passive/backup for other dataset which
is active in a remote site.
Back to your concurrent update q: the simplest solution I have in mind
for that is by creating a distributed transaction over two caches: the
local one and the backup cache.
Cheers,
Paolo
On 7/6/12 2:06 PM, Mircea Markus wrote:
> Hi,
>
> This[1] is the first draft of the cross-site (x-s)[2] replication bela and I came
with.
> Any feedback is more than welcomed!
>
> Cheers,
> Mircea
>
> [1] https://gist.github.com/3059621
> [2] we've also thought of using the term 'site' instead of
'datacenter'. Dataceneter is a bit too specific, not as concise and also
inconsistent with the term 'site' we've been using for the
TopologyAwareConsistentHash.
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
7:28 p.m.
Firstly, we should strive to be consistent with how our XML configuration works, so IMO,
boo-moo should be booMoo (I'm talking about backup-strategy here).
Now, I'm confused with the global settings. What backupStrategy should define is how
to communicate with the other site, i.e. if you wanna use a different bind address,
different transport protocol…etc. This is the same that we do with the global transport
settings. We don't define whether backup (or in clustering, replication or
invalidation..etc, is sync or async) is sync or async at this level. This configuration,
sync/async, belongs to the cache level IMO.
Does it make sense to have/define a site without the transport that you're gonna use
to configure with it? You could potentially have N different networks to connect to N
sites. If you assume the default, which default is it?
Line 31, what about this config instead?
<syncBackup name="NYC"/>
You could still have <backup> for when you want to use default mode as per the
cache. So, you'd have: backup, syncBackup, asyncBackup.
And line 25: <backups> instead of <sites>
On Jul 6, 2012, at 3:06 PM, Mircea Markus wrote:
Hi,
This[1] is the first draft of the cross-site (x-s)[2] replication bela and I came with.
Any feedback is more than welcomed!
Cheers,
Mircea
[1] https://gist.github.com/3059621
[2] we've also thought of using the term 'site' instead of
'datacenter'. Dataceneter is a bit too specific, not as concise and also
inconsistent with the term 'site' we've been using for the
TopologyAwareConsistentHash.
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
2:47 p.m.
On 10 Jul 2012, at 18:28, Galder Zamarreño wrote:
Firstly, we should strive to be consistent with how our XML
configuration works, so IMO, boo-moo should be booMoo (I'm talking about
backup-strategy here).
+1
Now, I'm confused with the global settings. What backupStrategy should define is how
to communicate with the other site, i.e. if you wanna use a different bind address,
different transport protocol…etc. This is the same that we do with the global transport
settings. We don't define whether backup (or in clustering, replication or
invalidation..etc, is sync or async) is sync or async at this level. This configuration,
sync/async, belongs to the cache level IMO.
gotcha
Indeed that's why we have the default cache for: all the other caches can inherit the
defaults from there.
Does it make sense to have/define a site without the transport that you're gonna use
to configure with it? You could potentially have N different networks to connect to N
sites. If you assume the default, which default is it?
The actual transport is
configured at jgroups level in RELAY2 and the matching between ISPN and jgroups is made
based on the name of the site.
Line 31, what about this config instead?
<syncBackup name="NYC"/>
You could still have <backup> for when you want to use default mode as per the
cache. So, you'd have: backup, syncBackup, asyncBackup.
That feels a bit like
mixing the attribute with the element, but that's precisely what we do with the
<async> and <sync> under the <clustering> tag.
I guess it's more a matter of taste, but I rather stick with simple backup - any
other oppinions?
And line 25: <backups> instead of <sites>
Thanks for the excellent feedback! I've updated the document and added some more
examples: https://gist.github.com/3059621
9:10 a.m.
On Thu, Jul 12, 2012 at 3:47 PM, Mircea Markus <mircea.markus(a)jboss.com>wrote:
On 10 Jul 2012, at 18:28, Galder Zamarreño wrote:
Firstly, we should strive to be consistent with how our XML configuration
works, so IMO, boo-moo should be booMoo (I'm talking about backup-strategy
here).
+1
Now, I'm confused with the global settings. What backupStrategy should
define is how to communicate with the other site, i.e. if you wanna use a
different bind address, different transport protocol…etc. This is the same
that we do with the global transport settings. We don't define whether
backup (or in clustering, replication or invalidation..etc, is sync or
async) is sync or async at this level. This configuration, sync/async,
belongs to the cache level IMO.
gotcha
Indeed that's why we have the default cache for: all the other caches can
inherit the defaults from there.
Does it make sense to have/define a site without the transport that you're
gonna use to configure with it? You could potentially have N different
networks to connect to N sites. If you assume the default, which default is
it?
The actual transport is configured at jgroups level in RELAY2 and the
matching between ISPN and jgroups is made based on the name of the site.
Line 31, what about this config instead?
<syncBackup name="NYC"/>
You could still have <backup> for when you want to use default mode as per
the cache. So, you'd have: backup, syncBackup, asyncBackup.
That feels a bit like mixing the attribute with the element, but that's
precisely what we do with the <async> and <sync> under the <clustering>
tag.
I guess it's more a matter of taste, but I rather stick with simple backup
- any other oppinions?
And line 25: <backups> instead of <sites>
Thanks for the excellent feedback! I've updated the document and added
some more examples: https://gist.github.com/3059621
I had the impression that you wanted all the sites to use the same ISPN
configuration, is that still true?
After seeing the use of a property to name the local site I thought there
would be only one config, but then below there doesn't seem to be any way
of defining the backup strategy for SFO or NYC.
7:28 p.m.
Resurrecting this thread for a minute (insert "Walking Dead" reference here)
-- there are two configuration operations -- sync and async.
Are these related to transaction replay? For instance, in the case of a
transaction, does a "sync" configuration mean the cluster will replay a 2PC
(or 1PC, in the case of synchronizations) to the other sites? And async
means "fire and forget?"
Plus if I have the following configuration:
<namedCache="cache1">
<backup name="STL" strategy="sync"/>
<backup name="SFO" strategy="async"/>
</namedCache>
<namedCache="cache2">
<backup name="STL" strategy="sync"/>
<backup name="SFO" strategy="async"/>
</namedCache>
<namedCache="cache1">
<backup name="STL" strategy="sync"/>
<backup name="SFO" strategy="async"/>
</namedCache>
<namedCache="cache3">
<backup name="STL" strategy="async"/> <---------
<backup name="SFO" strategy="async"/>
</namedCache>
...what happens if cache1, cache2, and cache3 were started in a transaction
in the PHL site? How would these be replayed on the backup sites? I would
expect that it would be "sync" for STL and "async" for SFO.
Thanks,
Erik
-----Original Message-----
From: infinispan-dev-bounces(a)lists.jboss.org
[mailto:infinispan-dev-bounces@lists.jboss.org] On Behalf Of Vladimir
Blagojevic
Sent: Monday, July 16, 2012 12:17 PM
To: infinispan -Dev List
Cc: Erik Salter (esalter)
Subject: Re: [infinispan-dev] X-S replication configuration
On 12-07-12 8:47 AM, Mircea Markus wrote:
On 10 Jul 2012, at 18:28, Galder Zamarreño wrote:
>
> And line 25: <backups> instead of <sites>
Same here. I would keep sites in global definition and backups in
caches. But either way is good, matter of taste!
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
2:34 p.m.
On 9 Aug 2012, at 18:28, Erik Salter wrote:
Resurrecting this thread for a minute (insert "Walking
Dead" reference here)
-- there are two configuration operations -- sync and async.
Are these related to transaction replay? For instance, in the case of a
transaction, does a "sync" configuration mean the cluster will replay a 2PC
(or 1PC, in the case of synchronizations) to the other sites?
In the first iteration yes. Further on we can think about other ways of optimising this,
e.g. if the 2nd site is passive, then sending only a 1PC should be good enough.
And async
means "fire and forget?"
Initially yes. The plan is to add some store and
fwd capability at a further point, so it would be more like "fire and eventually
deliver".
Plus if I have the following configuration:
<namedCache="cache1">
<backup name="STL" strategy="sync"/>
<backup name="SFO" strategy="async"/>
</namedCache>
<namedCache="cache2">
<backup name="STL" strategy="sync"/>
<backup name="SFO" strategy="async"/>
</namedCache>
<namedCache="cache1">
<backup name="STL" strategy="sync"/>
<backup name="SFO" strategy="async"/>
</namedCache>
cache1 is defined twice, I guess this was a copy-paste thing?
<namedCache="cache3">
<backup name="STL" strategy="async"/> <---------
<backup name="SFO" strategy="async"/>
</namedCache>
...what happens if cache1, cache2, and cache3 were started in a transaction
in the PHL site? How would these be replayed on the backup sites? I would
expect that it would be "sync" for STL and "async" for SFO.
yes.
Thanks,
Erik
-----Original Message-----
From: infinispan-dev-bounces(a)lists.jboss.org
[mailto:infinispan-dev-bounces@lists.jboss.org] On Behalf Of Vladimir
Blagojevic
Sent: Monday, July 16, 2012 12:17 PM
To: infinispan -Dev List
Cc: Erik Salter (esalter)
Subject: Re: [infinispan-dev] X-S replication configuration
On 12-07-12 8:47 AM, Mircea Markus wrote:
> On 10 Jul 2012, at 18:28, Galder Zamarreño wrote:
>>
>> And line 25: <backups> instead of <sites>
Same here. I would keep sites in global definition and backups in
caches. But either way is good, matter of taste!
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
4282
days inactive
4317
days old
infinispan-dev@lists.jboss.org
8 comments
7 participants
participants (7)
-
Dan Berindei -
Erik Salter -
Galder Zamarreño -
Mircea Markus -
Mircea Markus -
Paolo Romano -
Vladimir Blagojevic