This page takes you through the steps for upgrading from DSS 3.1.1 to DSS 3.2.0. For more information on release versions, see the Release Matrix .Table of Contents maxLevel 3 minLevel 3
...
The following are the specific prerequisites you must complete before you upgrade WSO2 DSSfrom DSS 3.1.1 to DSS 3.2.0:
Before you upgrade to the latest version of WSO2 DSS, you create a staging database, which is essentially an empty database. Note that you should NOT connect a new version of WSO2 DSS to an older database that has not been upgraded. Make a backup of the database and the <DSS_HOME> directory prior to upgrading. The <DSS_HOME> directory can simply be copied to the new database.
Stop all the Carbon servers connected to the database before running the migration scripts.
Note Note that the upgrade should be done during a period when there is low traffic on the system.
Limitations
- This upgrade 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 roll back an upgrade. It is impossible to restore a backup of the previous server and retry the upgrade process.
Downtime
The downtime is limited to the time taken for switching databases when the staging database is promoted to the actual production status.
Upgrading the
...
To upgrade the existing production database:
...
Select the relevant script for the upgrade from here on the production 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 mysql-migration.sql command in MySQL. Running this script will ensure that the database is upgraded with the additional tables and schemas which are required for the new DSS version.
| Info |
|---|
There are three migration scripts available: |
...
configurations
To migrate the configurations to the staging database:
Copy the data from the old database to the staging database you created. This becomes the new database for your new version of WSO2 DSS.
- Download DSS 3.2.0 and connect it to your staging database.
...
To migrate the configurations to the staging database:
- Configure the following files for the new production server. Note that there are no changes in the configuration options available in DSS 3.2.0 compared to the previous version.
- Go to the
<DSS_HOME>/repository/conf/datasources directory and update themaster-datasources.xml file. See configuring master-datasources.xml. - Go to the
<DSS_HOME>/repository/confdirectory and update datasource references in theuser-mgt.xmlandregistry.xml files.See configuring user-mgt.xml and configuring registry.xml.
- Go to the
- Copy the following directories from the old database to the staging database.
- To migrate the super tenant settings, copy the
<DSS_HOME>/repository/deployment/serverdirectory. - If multitenancy is used, copy the
<DSS_HOME>/repository/tenantsdirectory.
- To migrate the super tenant settings, copy the
- Start the server.
Recommended Checkpoints
The databases should contain the newly added tables, which are namely as follows:
...
UM_DOMAIN
...
UM_SYSTEM_USER
...
UM_SYSTEM_ROLE
...
Check for any other configurations that were done for DSS 3.1.1 (based on your solutions), and update the configuration files in DSS 3.2.0 accordingly. For example, external user stores, caching, mounting, etc.
Tip Note that the properties of data services listed below have changed for all 3.x.x versions of WSO2 DSS. Therefore, if you have any .dbs files moved from an older DSS version (DSS 2.x.x version) to DSS 3.2.0, be sure to update these properties as applicable to the DSS 3.x.x versions. The following table shows how the properties have changed between DSS 2.x.x versions to DSS 3.x.x versions.
DSS 2.x.x versions DSS 3.x.x versions org.wso2.ws.dataservice.driver driverClassName org.wso2.ws.dataservice.protocol url org.wso2.ws.dataservice.user username org.wso2.ws.dataservice.password password org.wso2.ws.dataservice.query_timeout queryTimeout org.wso2.ws.dataservice.autocommit autoCommit org.wso2.ws.dataservice.fetch_direction fetchDirection org.wso2.ws.dataservice.fetch_size fetchSize org.wso2.ws.dataservice.max_field_siz maxFieldSize org.wso2.ws.dataservice.max_rows maxRows org.wso2.ws.dataservice.transaction_isolation defaultTransactionIsolation org.wso2.ws.dataservice.initial_size initialSize org.wso2.ws.dataservice.maxpoolsize maxActive org.wso2.ws.dataservice.max_idle maxIdle org.wso2.ws.dataservice.minpoolsize minIdle org.wso2.ws.dataservice.max_wait maxWait org.wso2.ws.dataservice.validation_query validationQuery org.wso2.ws.dataservice.test_on_borrow testOnBorrow org.wso2.ws.dataservice.test_on_return testOnReturn org.wso2.ws.dataservice.test_while_idle testWhileIdle org.wso2.ws.dataservice.time_between_eviction_runs_mills timeBetweenEvictionRunsMillis org.wso2.ws.dataservice.num_test_per_eviction_run numTestsPerEvictionRun org.wso2.ws.dataservice.min_evictable_idle_time_millis minEvictableIdleTimeMillis org.wso2.ws.dataservice.remove_abandoned removeAbandoned org.wso2.ws.dataservice.remove_abandoned_timeout removeAbandonedTimeout org.wso2.ws.dataservice.log_abandoned logAbandoned org.wso2.ws.dataservice.xa_datasource_class dataSourceClassName org.wso2.ws.dataservice.xa_datasource_properties dataSourceProps org.wso2.ws.dataservice.force_stored_proc forceStoredProc org.wso2.ws.dataservice.force_jdbc_batch_requests forceJDBCBatchRequests - Start the server.
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.