Upgrading from a Previous Release

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 .

Preparing to upgrade

The following are the specific prerequisites you must complete before you upgrade from 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.
Stop all the Carbon servers connected to the database.

Note that the upgrade should be done during a period when there is low traffic on the system.

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 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.
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 the master-datasources.xml file . See configuring master-datasources.xml.
- Go to the <DSS_HOME>/repository/conf directory and update datasource references in the user-mgt.xml and registry.xml files. See configuring user-mgt.xml and configuring registry.xml.
Copy the following directories from the old database to the staging database.
- To migrate the super tenant settings, copy the <DSS_HOME>/repository/deployment/server directory.
- If multitenancy is used, copy the <DSS_HOME>/repository/tenants directory.

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.

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.