Page Comparison

This page takes you through the steps for upgrading the product version from DSS 3.1.1 to DSS 3.2.0. For more information on release versions, see the  Release Matrix .

Preparing to upgrade

Complete The following are the following prerequisites.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 should create a staging database. When you upgrade the database, you will be copying the data from the production database to the staging database. Once this data migration is completed, you will install the latest version of WSO2 DSS and point it to the staging database, which then becomes the production database
  

  Note
  You should NOT connect a new version of WSO2 DSS to an older database that has not been migrated.

  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 , which is essentially an empty 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.

...

Upgrading the

...

configurations

To To  migrate from the existing production database configurations to the new database ( staging database):

1. Stop the current server.
2. Select the relevant migration script from here. Select the migration.sql script corresponding to your database type. For example, if your database is MySQL, you need to execute mysql-migration.sql. Note that there are three migration scripts available: migration-service-provider.sql, migration-identity.sql and migration.sql. However,  for all Carbon products except WSO2 IS, only the migration.sql script is required to be executed.
3. Download and run the migration.sql script.

Upgrading from DSS 3.1.1 to DSS 3.2.0

To  connect the latest production server to the new database and to migrate the configurations:

1. Download

   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.

2. Download DSS 3.2.0 and connect it to your staging database.
3. 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 and connect it compared to the staging database you created when upgrading the database.
   Connect the latest production server to the database as described below:
   Configure theprevious version.
   
   • Go to the <DSS_HOME>/repository/conf/datasources/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  See configuring user-mgt.xml and   and  configuring registry.xml.
4. Since a separate database (staging database) is used for the upgrade, the data that is collected in the actual production system while the upgrade is in progress should be added to the upgraded database using a script.
5. 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

...

1. 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.
     

2. 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

3. Start the server.