Magnolia Synchronization module is used to synchronize a target instance with a source instance. It allows you to activate a large amount 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.

The Synchronization module offers the following benefits:

• The module traverses the node tree and activates only previously activated content. This ensures that content that was never activated is not published in synchronization.
• If content was versioned upon activation (Magnolia default behavior), the module will activate the last known version, thus being able to recover even modified content.
• You can use the module to prepare additional public instances that are identical copies of current instances.

The module has been tested on Magnolia 3.6. and 4.x instances.

• Download
• Installing
• Uninstalling
• Usage scenarios
• Public instance failure
• Public instance blackout
• High load
• Configuration
• Synchronizing
• Examples
• Current status
• Synchronizing the data type root path
• Good to know
• Scheduled synchronization

Download

Download the Synchronization module from Magnolia Store or Nexus repository.

Installing

Synchronization an enterprise module. It is not included in the Enterprise Edition bundle and needs to be downloaded and installed individually. To install the module , see the general module installation instructions.

Uninstalling

See the general module uninstalling instructions and advice.

Usage scenarios

Public instance failure

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:

• Republish everything to both instances. This is a time-consuming process, generates high load, and slows down your site during publishing.
• If you kept a list of the published pages, you know exactly what to activate to get them on both instances. This works well for small deployments with infrequent updates and a single editor.
• Use the Synchronization module. Set the previously broken public instance as a synchronization subscriber and Magnolia will take care of synching the missing content.

Public instance blackout

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 published versions of content, even if the content was modified further, and skip any pages that were not previously published.

High load

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.

• You cannot shut down any of the existing public instances because you need them to deal with the load. This prevents taking a snapshot for cloning.
• You cannot activate all content from the author instance to public instances since this would unnecessarily flush the cache on them and increase load when the servers are already busy.

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.

Configuration

Configure the target instance as a synchronization subscriber. A synchronization subscriber is different from a normal subscriber and is configured in a different place.

1. Sign into AdminCentral on the source instance.
2. Click Configuration.
3. Browse to /modules/synchronization/commands/synchronization/synchronize.
4. In the /subscriber node, set the URL property value to the target instance address.
5. Set the active property to true.

Individual subscriptions are configured in the /subscriber/subscriptions node in exactly the same way as normal subscribers. For more information see Subscribers - Subscriptions.

Synchronizing

Before synchronizing the data workspace, make sure the data type root path ( / ) is activated.

1. Sign into AdminCentral on the source instance.
2. Go to Tools > Synchronization.
3. In the Path box, type the path to the content node you want to activate.
   If you are not sure what the path is, use the JCR Browser in Tools > JCR Browser. By default the JCR browser displays the website workspace. You can configure it to display another workspace in /modules/adminInterface/trees/website-jcr/repository. For more information see Configuring a custom JCR browser.
4. Select the Repository that holds the content. For web pages this is typically website, for documents dms.
5. Optional: Check the Recursive synchronization checkbox if you want to activate all child nodes recursively.
6. Click Start Synchronization.
   Synchronization executes one minute after you click Start Synchronization. The Current Status area displays the progress.
7. To verify the results, sign into AdminCentral on the subscriber instance and check that the content was published correctly.

Examples

Path	Repository	Recursive	Synchronizes
/	website	Yes	All website pages.
/demo-project/about/history	website	No	History page only
/demo-project/about	website	Yes	All pages under About page.
/example	data	No	Data root folder example only.
/example/mydata	data	No	Subfolder mydata only.
/example/mydata	data	Yes	Subfolder mydata and everything under it.
/admin/jsmith	users	No	User jsmith only.
/admin	users	Yes	All admin level users.

Current status

Status message	Synchronization job status
Synchronization is starting.	Your job is in the queue waiting to be executed.
Synchronization is being executed.	Synchronization is currently running.
Synchronization is not scheduled.	Synchronization has completed.

Synchronizing the data type root path

Prerequisite: Data module needs to be installed.

Before synchronizing content in the data workspace, make sure the data type root path ( / ) is activated:

1. Sign into AdminCentral on the source instance.
2. Click Data > JCR Browser.
3. Verify that the root node has a green dot in the Status column.
• Green: Node is activated. Source and target are in sync.
• Yellow: Node was modified after activation. Source and target are not in sync.
• Red: Node is not activated. It does not exist on the target instance.
4. If the root node was modified or never activated (dot is yellow or red), right-click it and select Activate this node.

Good to know

• Only data items are stored in the data workspace (repository). For example, item i1 of type t1 has the following path in the workspace: /t1/e1.
• All other data related things such as types, dialogs and trees are stored in the config workspace with a path such as /modules/data/config/types/t1 or /modules/data/dialogs/t1.
• When synchronizing the data workspace, make sure the type root path is synchronized before starting synchronization. Use the Data module JCR browser to check this.
• Don't try to synchronize mgnl* workspaces
• Don't try to synchronize Store and Expression workspaces.

Scheduled synchronization

To run the synchronization process according to a schedule, use the Scheduler module which is included in all Magnolia Community and Enterprise editions.

The purpose of scheduling is not to synchronize an instance repeatedly. This leads to unnecessary flushing of cache and increases load. The aim is to schedule the sync to occur at a convenient later time such as during low traffic volume.

1. Configure a synchronization subscriber.
2. Click Configuration.
3. Browse to /modules/scheduler/config/jobs.
4. Copy the example demo job node and paste it into the jobs folder. This is the new scheduled job that will launch the synchronize command.
5. Rename the job node so that its name indicates what content is being synchronized, for example sync-news.
6. Set the job node properties:

Property	Description	Example
path	Path to the content	demo-project/news-and-events
recursive	Create a new node recursive. false synchronizes the individual node given in path above. true synchronizes the node and the whole branch under it.	true
repository	Repository where the content resides.	website
active	true activates and false deactivates the job.	true
catalog	Folder where the synchronization command resides. If you configured the subscriber using the instructions above, the command is in the /modules/synchronization/commands/synchronization folder.	synchronization
command	Name of the synchronization command.	synchronize
cron	Schedule. For example 0 0 1 5 11 ? 2010 to run on November 5 at 01:00 am. See CRON expression for more scheduling examples.	0 0 1 5 11 ? 2010
description	Descriptive name	Synchronize news at midnight

Example job configuration: