Magnolia 4.5 reached end of life on June 30, 2016. This branch is no longer supported, see End-of-life policy.
The Synchronization module is used to synchronize a target instance with a source instance. It allows you to activate large amounts of content selectively. Only previously activated content is transferred to the target instance. You can use the module to create new public instances without shutting down your existing instances or impacting their ability to serve content.
Synchronization module benefits:
Synchronization an enterprise module. It is included in the add-ons folder of the Enterprise Edition bundle. To install the module , see the general module installation instructions.
See the general module uninstalling instructions and advice.
Imagine that you have two public Magnolia instances. Due to hardware failure one of them is out of operation for a few days. As you try to publish content during the outage, Transactional Activation tells you that the content cannot be activated because one of the public instances is down.
Since you really need to publish new content to the remaining public instance, you make a conscious decision to switch off the subscriber that suffered the hardware failure. Now you can publish the content while waiting for the failed hardware to be replaced.
A few days later hardware on the failed public instance has been replaced and the server is up again. You re-enable the subscriber so that all new content is activated to both public instances. But you still have a problem what to do with all the content that was published while the instance was down. Your options are:
All public instances are corrupted, broken or compromised. No instances exist to serve content. A small site can deal with this by creating a new public instance and publishing all content to it. This is difficult in large deployments that have many editors, where content has already been modified since the blackout took effect, and where some pages are not yet ready to be published across the site. Use the Synchronization module to activate any previously activated versions of content, even if the content was modified further, and skip any pages that were not previously activated.
You have a sudden high load on your site, also known as Slashdot effect. You need to add a new public instance to deal with the load.
The solution is to create a new empty public instance and use the Synchronization module to publish content only to that instance while the existing public instances keep serving content.
The Synchronization module is configured in
Synchronization is controlled by the
BaseActivationCommand) registered in
syndicator: Registers the syndicator class.
SilentXASSyndicatorperforms synchronization of content without update to metadata
subscriber: Synchronization configurations (see below).
Target instances are configured as synchronization subscribers. A synchronization subscriber is different from a normal subscriber and configured in a different place.
A number of example synchronization subscriber configurations are provided in
subscriptions. Individual synchronization subscriptions are configured in in exactly the same way as normal subscriptions.
To configure a synchronization subscriber, copy and adapt an example configuration.
fromURI: Path on the author instance from which the content is activated.
repository: Name of the workspace.
toURI: Target instance path.
active: Set to
true to enable the synchronization subscriber.
The Synchronization tool allows you to manually synchronize content between author and a single public instance. The operation is performed asynchronously. You can access the tool at Tools > Synchronization.
To perform a manual synchronization:
All website pages.
All pages under
All admin level users.
Before synchronizing the
data workspace, make sure the data type root path ( / ) is activated.
You can schedule synchronization jobs using the Scheduler module. The purpose of scheduling is not to synchronize an instance repeatedly, because this leads to unnecessary flushing of the cache and increases load. The aim is to schedule the sync to occur at a convenient later time such as during low traffic volume.
/modules/scheduler/config/jobs/demo node and edit its properties.
<job name>: Name of the job,
sync-newsin our example.
params: Parameters passes to the command.
SynchronizationCommandexpects/allows the following parameters
path: Path to the content, for example
recursive: Set to
trueto synchronize the node and subnodes.
repository: Workspace where the content resides, for example
active: Set to
trueto enable the job.
catalog: Name of the catalog where the command resides. The
synchronizecommand resides in the
command: Name of the command definition node,
cron: Schedule that indicates the execution time, written as a CRON expression. In our example
0 0 1 5 2 ? 2014will run the job on February 5 at 01:00 am.
description: Job description.
Test the synchronize command un-scheduled first. If it runs correctly, schedule it to publish to a new public instance after one minute (CRON expression:
0 * * * * ?). If this works correctly too, point the subscriber configuration to the out-of-sync target instance and modify the CRON schedule as required.