topic [SOLVED] Can't make replication service work in Alfresco Archive

[SOLVED] Can't make replication service work

fr3dy — Mon, 23 Apr 2012 08:05:55 GMT

Hi. I'm trying to replicate one Alfresco Community 4.0d installation from one site to another, but I'm having problems configuring it (and finding documentation).Both sites have only the default content, except the source node which contains a test site too (it should be replicated on the other).I d

Re: [SOLVED] Can't make replication service work

afaust — Mon, 23 Apr 2012 09:41:55 GMT

Hello,

based on your log output you have configured a replicating content store on the target node as well (your list specifically states this as "source node" only). Please be aware that for content replication between Alfresco instances you do not need any replicating content store. The replicating content store is only relevant for distributing content of one instance on several backend storage systems.

Please adapt your configuration and try again without the replicating stores. When content replication works in general, you should investigate the error from the replicating content store which I assume is caused by something else in your configuration / setup.

Regards
Axel

Re: [SOLVED] Can't make replication service work

fr3dy — Mon, 23 Apr 2012 10:15:11 GMT

I've renamed the file replicating-content-services-context.xml to disable it on both nodes (you were right, I enabled it on both instances).
After restarting services…. IT WORKS! I'm gonna make some tests now.

By the way, is it possible to configure Active-Passive nodes by using replication? I mean, enable transfer from instance 1–>2 and, if instance 1 fails, activate 2–>1 (automatized if possible).

Thanks for your reply!

Re: [SOLVED] Can't make replication service work

afaust — Mon, 23 Apr 2012 10:48:49 GMT

Hello,

technically, something like this would be possible with implementation, but there could be a variety of complications. For one, the version history and versionable policy is only stored on the originating node (say "1") and not transferred to the replication target. The replicated node on "2" is not versionable by default and even if you enabled versioning for it, you would end up with two distinct histories if you reverse the replication direction.

Regards
Axel

Re: [SOLVED] Can't make replication service work

fr3dy — Mon, 23 Apr 2012 11:10:58 GMT

Hello,

technically, something like this would be possible with implementation, but there could be a variety of complications. For one, the version history and versionable policy is only stored on the originating node (say "1") and not transferred to the replication target. The replicated node on "2" is not versionable by default and even if you enabled versioning for it, you would end up with two distinct histories if you reverse the replication direction.

Regards
Axel

So, what are the chances of using a replicated instance as primary one? Should I do something like this?:

1) Replicate from alf1 to alf2

2) If alf1 fails, use alf2 (read-only) while fixing/restoring alf1

3) Once restored, enable alf1 again and continue from step 1)

I guess enabling read-write on alf2 is not a good idea, since it should always be a mirror of the main node (alf1). Could you confirm this and the above?

Thanks a lot for your help

Re: [SOLVED] Can't make replication service work

afaust — Mon, 23 Apr 2012 11:32:42 GMT

Hello,

for the most common scenario of a temporary downtime of alf1 I would advise to follow the points you've listed.
Switching the "primary node" in a replication context should only be used if it fulfills a business use case - not for purely technical reasons. It should at all times be clear which node stores the master and what nodes only manage the mirror nodes - including the additional data that accompanies the master. So as long as you do not have the functionality in place that transfers this additional data, the node on alf2 can and should only ever be a mirror.

Regards
Axel

Re: [SOLVED] Can't make replication service work

fr3dy — Mon, 23 Apr 2012 11:38:10 GMT

Hello,

for the most common scenario of a temporary downtime of alf1 I would advise to follow the points you've listed.
Switching the "primary node" in a replication context should only be used if it fulfills a business use case - not for purely technical reasons. It should at all times be clear which node stores the master and what nodes only manage the mirror nodes - including the additional data that accompanies the master. So as long as you do not have the functionality in place that transfers this additional data, the node on alf2 can and should only ever be a mirror.

Regards
Axel

I'll do that then. Thanks!!!