Registry-based Deployment Synchronizer

Registry-based Deployment Synchronizer does not work for WSO2 products based on Carbon 4.2.0 onwards. This was depreciated for newer products since the Registry-based Deployment Synchronizer maintains artifacts in the database, which leads to performance issues. When the number of artifacts increases, the number of database calls to check the difference for Dep Sync to work becomes an overhead and therefore there is a severe performance hit.

Deployment Synchronizer or Dep-Sync is used to synchronize artifacts within nodes in a cluster. This topic provides instructions on how to set up the registry-based deployment synchronizer to sync artifacts within two WSO2 ESB nodes. There are other synchronization methods available in WSO2 servers such as Subversion (SVN)-based deployment synchronizer, but they need third-party software and are a bit hard to configure compared to registry-based deployment synchronizer.

Registry-based deployment synchronizer uses a common registry space to store the deployment artifacts. In this mechanism, the recommended clustering pattern is to have one READ-WRITE product node and the rest are READ-ONLY. Once you deploy an artifact from the READ-WRITE node, the artifacts will be stored in the relevant collection in the configuration registry. The other nodes of the cluster will use the registry checkin-checkout client and checkout the deployment artifacts to their file system. Then with the hot deployment functionality, the artifacts will get deployed in the cluster nodes.

Before doing the actual registry-based deployment synchronizer configurations, we first need to mount ESB's /_system/config collection to a single database. To get a clear idea on registry mounting read this.

You cannot use an embedded H2 database for this since H2 allows one connection at a time in its embedded mode. In this example, we use MySQL to do the registry mounting.

Configuring the manager node

You configure DepSync in the <PRODUCT_HOME>/repository/conf/carbon.xml file on the manager node by making the following changes in the <DeploymentSynchronizer> tag:

<DeploymentSynchronizer>  
    <Enabled>true</Enabled>
    <AutoCommit>true</AutoCommit>
    <AutoCheckout>true</AutoCheckout>
    <RepositoryType>registry</RepositoryType>
</DeploymentSynchronizer>

The above must be uncommented in the carbon.xml file.
Here <Enabled> is set to true to indicate that the registry-based deployment synchronizer is enabled.
The <AutoCommit> tag is set to true to indicate that this node can commit the changes to registry.
The <AutoCheckout> tag is set to true to indicate that this node is needed to checkout since this is the only node which makes changes to the configurations. You would also set <AutoCheckout> to true if there is more than one manager node.

Configuring the worker node

You configure DepSync in the <PRODUCT_HOME>/repository/conf/carbon.xml file on the worker node by making the following changes in the <DeploymentSynchronizer> tag:

<DeploymentSynchronizer>  
    <Enabled>true</Enabled>
    <AutoCommit>false</AutoCommit>
    <AutoCheckout>true</AutoCheckout>
    <RepositoryType>registry</RepositoryType>
</DeploymentSynchronizer>

Here <Enabled> is set to true to indicate that the registry-based deployment synchronizer is enabled.
The <AutoCommit> tag is set to false to indicate that this node cannot commit the changes to registry.
The <AutoCheckout> tag is set to true to indicate that this node needed to checkout since this node needed to sync up with the manager node.