Page Comparison

Deployment Synchronizer provides the capability to synchronize deployment artifacts across the nodes of a product cluster.

A product's repository typically contains user-uploaded service archives, modules, service metadata, scheduled tasks etc. These artifacts are typically shared across multiples nodes in a cluster. Therefore, in a clustered environment. It is used to keep the axis2 repository of WSO2 products (, the artifact repository (in WSO2 products, by default, it is <product-home>/repository/deployment/server/) should be in-sync between all the cluster nodes. Since axis2 repository includes user-uploaded service archives, modules, service metadata etc, it's important that all the cluster nodes have the same content.This functionality is facilitated , in order to maintain consistency. This synchronization functionality is provided by the following feature in the WSO2 feature repository:

Name: WSO2 Carbon - Deployment Synchronizer Feature
Identifier: org.wso2.carbon.deployment.synchronizer.feature.group 

 If it is not included in your product by default, you can add by installing the above feature using the instructions given in section, Feature Management.

The In summary, the WSO2 Deployment Synchronizer featurecan be used to synchronize the main repository of a Carbon server with a collection in the registry. This feature is sometimes also referred to as the registry-based repository synchronizer. The deployment synchronizer has a number of has the following use cases:

• Maintaining an up-to-date backup of the Carbon artifact repository.
• Sharing a single Carbon artifact repository among multiple servers (through a shared registry)in a cluster.
  
• Enforcing artifact updates in the registry to be deployed on a server at runtime.

Assume a cluster of Carbon servers that share the configuration registry. With the deployment synchronizer, it is possible to maintain all the nodes in the cluster in sync through the shared registry. One of the nodes can be designated as the master node and it can upload its local repository to the registry using the deployment synchronizer. Other nodes (slave nodes) can then download the same repository from the registry and deploy locally. To support this use case, synchronizer has to be run in auto commit mode in the master node. When in auto commit mode, it will periodically upload the changed artifacts in the local repository to the registry. Similarly, slave nodes should run the synchronizer in the auto checkout mode. If needed, registry eventing can be employed to run the checkout operations so that a checkout will be made only when some artifact has changed in the shared registry.

...

...

Currently, the WSO2 Deployment Synchronizer (DepSync) uses an SVN-based repository for storing shared deployment artifacts. The Subversion repository is used to sync the contents in the sync directory (the axis2 repo directory, <PRODUCT_HOME>/repository/deployment/server, by default). This method is efficient and high-performant. The synchronization process is as follows:

• When changes to the contents of axis2 repo directory are present, the Read-Write nodes commit those to the Subversion repository.
• Then, this node sends a cluster message to all other (slave) nodes specifying the repo is updated.
• When the slave nodes receive the message, they update their axis2 repo directory with what's in the svn repository.

For instructions on configuring the SVN-based Deployment Synchronizer, refer to  Configuring the SVN-Based Deployment Synchronizer.