For your cluster to perform correctly, all nodes must have the same configurations. For example, in an ESB cluster, if node 1 does not have a proxy service that the other nodes have, any time the ELB routes a request for that proxy service to node 1, an error will be returned. This inconsistency of status across the nodes breaks the clustering model where all nodes are viewed virtually as a single system.
To prevent this problem, all Carbon-based products use Deployment Synchronizer (DepSync) to ensure the same status is maintained across all nodes in the cluster. It maintains a central repository of the <PRODUCT_HOME>/repository/deployment/server folder, which is where deployment configurations are stored for all Carbon-based products, and uses that repository to synchronize the nodes.
The DepSync is of two types as follows:
| Child pages (Children Display) |
|---|
We recommend to use the registry-based DepSync in small-scale deployments with few artifacts that do not have frequent changesThis section covers the following:
| Child pages (Children Display) |
|---|
| Note |
|---|
Note that only SVN-based Deployment Synchronizer is supported for WSO2 products based on WSO2 Carbon 4.2.0 onwards. 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. |