To upgrade WSO2 Governance Registry, the user store database should be upgraded. Note that there are no registry schema changes between versions. This topic provides instructions on how you can upgrade (the data and configurations) from WSO2 G-Reg 4.5.3 to WSO2 G-Reg 4.6.0.
Preparing to upgrade
The following are the specific prerequisites you must complete before you upgrade WSO2 G-Reg:
- Before you upgrade to the latest version of WSO2 Governance Registry, you create a staging database, which is essentially an empty database. Note that you should NOT connect a new version of WSO2 GREG to an older database that has not been migrated.
- Make backups of the database and the WSO2 product prior to upgrading the database. The backup can be taken by copying the home folder of the product.
- Stop all the WSO2 products that are connected to the database.
If any files/folders are changing in the product pack to which you are upgrading, you need to make a backup of the relevant files/folders prior to changes.
The following are the limitations of upgrading.
- This upgrading process can only be done for the same database types. For example, if you are using MySQL currently and you wish to use Oracle in the new version of GREG, these scripts will not work.
- You cannot roll back the upgrading process. It is impossible to restore a backup of the previous server and retry the upgrading progress.
The downtime is limited to the time taken for switching databases when in the production environment.
Upgrading the database
Stop the current Governance Registry 4.5.3 server.
Before discarding the old GREG instance, make a backup of the
GREG_HOME/solrdirectory. Solr-based index is required to re-index all the resources once migrated.
Take a consistent database dump and create the staging database using that dump. This becomes the new database for your new version of GREG.
Select the relevant script for the upgrade from here and run on the staging database. The script you use will depend on the type of database you are using, for instance, if your database is MySQL you need to run the execute the
mysql-migration.sqlcommand in MySQL (you would use Oracle or MSSQL to run the script if that is the database you are using). Running this script will ensure that the database is upgraded with the additional tables and schemas which are required for GREG 4.6.0.
There are three migration scripts available:
migration.sql. However, for all Carbon products except WSO2 IS, only the
migration.sqlscript is required to be executed.
- Download WSO2 Governance Registry 4.6.0 from http://wso2.com/products/governance-registry/.
- To connect the new product version to the upgraded (staging) database, configure the following files:
<PRODUCT_HOME>/repository/conf/datasources/master-datasources.xml. See here for more information on how to do this for your database.
Go to the
<PRODUCT _HOME>/repository/confdirectory and update the datasource references in
api-manager.xmlto match the updated configurations in the
master-datasources.xmlfile which you made in the above step. The following are sample configurations if the datasource is
- Replace the
GREG_HOME/solrdirectory with the backup you made in step 1. Note that this step is not a must but will make the re-indexing process faster.
Upgrading the configurations
<PRODUCT_HOME>/repository/conf/user-mgt.xmlfile and add the following property to the existing
AuthorizationManagerconfiguration as shown below.
In the new product version, open
<PRODUCT_HOME>/repository/conf/registry.xmland change the value of this indexing configuration as shown below.
Perform any configurations required for the server, e.g., external user stores, clustering, caching, mounting.
Note that configurations should not be copied directly between servers.
Start the server.
The databases should contain the newly added tables, which are namely as follows:
Going into production
The following are recommended tests to run on the staging system.
Create multiple user stores and try adding users to different user stores.
Create multiple tenants and add different user stores to the different tenants. Thereafter, add users to the various user stores.
Once the above tests are run successfully, it is safe to consider that the upgrade is ready for production. However, it is advised to test any features that are being used in production.