Overview
WSO2 governance registry can be introduced as a product which provides you with a rich set of functionalities to accomplish your registry and repository related needs. Including WSO2 Greg, each and every carbon based product uses the registry kernel which offers basic registry and repository functionalities to store data and configurations associated with each product. For example, it's being often used to store various resource entities such as carbon datasource configurations, WSDLs, Schemas, endpoints, etc under various environments such as standalone environments, clustered environments etc in numerous occasions.
Delving further into the functionality of the registry kernel, its storage space can be divided into three main partitions namely,
1. Local registry
2. Configuration registry
3. Governance registry
Out of those three aforementioned types of partitions, local registry is often used to store configurations and data that are local to a particular instance of a carbon product. Also this particular registry space is not shared among any other nodes by its nature. In contrast, the configuration registry can be used to share configurations common to multiple nodes of the same product. For example, if you consider a cluster of WSO2 Data Service Server nodes storing dbs files or any other configuration data in their configuration registry space, those data can be shared across all the nodes in the WSO2 Data Service Server cluster. Unlike both local registry and configuration registry, the governance registry can be used to store configurations and data that need to be shared across many nodes of different carbon products.
Back to the topic..
Having had a brief, yet comprehensive overview about the registry kernal, let's get ourselves back to the main subject of this blog post which is exporting registry contents of one carbon node to another using the check-in client introduced by WSO2 Governance Registry.
As explained earlier, you may come across this requirement of migrating or exporting data and configurations stored in the registry of one carbon product to another. One way of achieving this would be to get a database dump and restore it in the carbon node that exists in the other end of the migration process which is a pretty much tedious task. To address this problem, WSO2 Governance Registry introduces this mechanism called registry check-in client which provides you with means to get a registry dump and restore it in another carbon node easily. Although this mechanism is only shipped with WSO2 Governance Registry by default, it's quite possible to adopt it into other carbon products as well. The rest of the content of this blog post would bring you the steps that are necessary in making use of the registry check-in client in other carbon products (For example, WSO2 Data Services Server).
Step 1:
Download WSO2 Governance Registry distribution and locate the checkin-client.sh in its GREG_HOME/bin directory.
Step 2:
Change the working directory to DSS_HOME/bin and place the checkin-client.sh there.
Step 3:
Execute "ant" command inside DSS_HOME/bin directory which would create the DSS_HOME/repository/lib directory (if it does not already exist) and copy some required dependency jars to that particular directory.
Step 4:
Change the working directory to GREG_HOME/repository/lib and locate checkin-client-x.x.x.jar (x.x.x represents the version of the product being used)
Step 5:
Change the working directory back to DSS_HOME/repository/lib and place checkin-client-x.x.x.jar there.
Step 6:
Restart WSO2 Data Service Server instance.
Step 7:
Change the working directory to DSS_HOME/bin in the command line and run the checkout command "checkin-client.sh co https://hostname:9443/registry/ -u admin -p admin -f registry_checkout". This will create a registry dump file of the root collection, called "registry_checkout" inside DSS_HOME/bin directory. (Modify the paths and the hostname to match your environment)
Step 8:
To check in the data to a different DSS node (or any other carbon node), execute the following command. "./checkin-client.sh ci https://hostname:9443/registry/ -u admin -p admin -f $DSS_HOME/bin/registry_checkout". (Modify the paths and hostname to match your environment)
Further information on various ways of obtaining a registry dump of a particular collection can be located at [1].
References:
No comments:
Post a Comment