This guide takes you through the steps for upgrading product versions from BRS 2.0.0 to BRS 2.1.0. For more information on release versions, see the Release Matrix.
Preparing to upgrade
Before starting the upgrading process, the following prerequisites must be followed on the database.
- A separate staging database should run as the production database server. As a result, once the upgrading process is completed, the database server should have the configurations required for a production server.
- Take backups of the database and system prior to migrating the database. The system backup can be taken by copying the Carbon server home folder.
- Shut down all the Carbon servers connected to the database before running the migration scripts.
- Since a separate database (staging database) is used for the migration instead of the actual production database, the data that is collected in the actual production system while the upgrading is in progress should later be added to the migrated database using a script.
- The database administrator should collect the data portion that is added to the production database, while the upgrading is in progress. Generally, the WSO2 support team will provide help in these types of situations.
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.
Note New product (e.g., IS 4.5.0) must not be connected to the old database (e.g., IS 4.0.0) without executing the migration script provided in the old database.
Limitations
The following are the limitations of upgrading:
- This upgrading process can only be done for some database types. For example, if you are using MySQL currently and you need to migrate to Oracle in the new version, these scripts will not work.
- You cannot rollback the upgrading process. It is impossible to restore a backup of the previous server and retry the upgrading progress.
Downtime
The downtime is limited to the time taken for switching databases when the migrating environment is connected to the production.
Upgrading the database
Stop the current Governance registry server.
Note Before discarding the old GREG instance, please take a backup of the
GREG_HOME/solr
directory. Solr-based index is required to re-index all the resources once migrated.- Download WSO2 Governance Registry 4.6.0 from http://wso2.com/products/governance-registry/.
- Select the relevant script for the upgrade from here. Select the
migration.sql
script corresponding to your database type. E.g., If your database is MySQL, you need to executemysql-migration.sql.
Note that there are three migration scripts available:migration-service-provider.sql
,migration-identity.sql
andmigration.sql
. However, for all Carbon products except WSO2 IS, only themigration.sql
script is required to be executed. - To connect the new product version to the migrated database, configure the following files:
- Configure
<PRODUCT_HOME>/repository/conf/datasources/master-datasources.xml
. - Go to the
<PRODUCT
_HOME>/repository/conf
directory and update datasource references inuser-mgt.xml
,registry.xml
andapi-manager.xml.
- Configure
Migrating the configurations
Open the
GREG_HOME/repository/conf/user-mgt.xml
file and add the following property to the existingAuthorizationManager
configuration as shown below.Code Block <Property name=“CaseSensitiveAuthorizationRules">true</Property>
In the new product version, open
GREG_HOME/repository/conf/registry.xml
and change the value of this indexing configuration as shown below.Code Block <lastAccessTimeLocation>/_system/local/repository/components/org.wso2.carbon.registry/indexing/lastaccesstime460</lastAccessTimeLocation>
Perform any configurations required for the server, e.g., external user stores, clustering, caching, mounting.
Note Note that configurations should not be copied directly between servers.
Start the server.