Page Comparison

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

Preparing to

...

 Before starting the upgrade, 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 upgrade is completed, the database server should have the configurations required for a production server.
• Take backups of the database and system prior to upgrading 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 upgrade scripts.
• Since a separate database (staging database) is used for the upgrade instead of the actual production database, the data that is collected in the actual production system while the upgrade is in progress should later be added to the upgraded database using a script. 
• The database administrator should collect the data portion that is added to the production database, while the upgrade 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 migrating, you need to make a backup of the relevant files/folders prior to changes.

  Note
  New product must not be connected to the old database without executing the upgrade script provided in the old database.

Limitations

Following are the limitations of upgrading:

• 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 rollback an upgrade. It is impossible to restore a backup of the previous server and retry the migration progress.

Table of Contents
maxLevel 3 minLevel 3

upgrade

The following are the specific prerequisites you must complete before you upgrade from DSS 3.1.0 to DSS 3.1.1:

• 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
  Note that the upgrade should be done during a period when there is low traffic on the system.

Upgrade Procedure

Follow the instruction below to upgrade the system: 

...

Upgrading the configurations

To  migrate the configurations to the staging database:

...

1. 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.1.1 and connect it to your staging database.
3. Configure the following files for the new production server. 
   
   • Go to the <DSS_HOME>/repository/conf/
   datasources/
   • datasources directory and update the  master-datasources.xml file .
   Refer 
   • See  configuring master-datasources.xml.
   - Go to the <PRODUCT
   • Go to the  <DSS_HOME>/repository/conf
    directory
   •   directory and update datasource references in
   the 
   • the  user-mgt.xml 
   and 
   •  and  registry.xml files.
    Refer 
   •  See configuring user-mgt.xml
    and 
   •   and  configuring registry.xml.
4. Start the server.

Recommended Checkpoints

...

• UM_DOMAIN

• UM_SYSTEM_USER

• UM_SYSTEM_ROLE

• UM_SYSTEM_USER_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.0 (based on your solutions), and update the configuration files in DSS 3.1.1 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.1.1, 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.