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 . Table of Contents maxLevel 3 minLevel 3
Preparing to upgrade
Complete The following are the following prerequisites.specific prerequisites you must complete before you upgrade WSO2 DSS:
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
YouNote 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
migratedupgraded.
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 database
To migrate from upgrade the existing production database to the new database (staging database):
...
- Stop the current server.
Select the relevant
migrationscript for the upgrade from here
. Select themigration.sql
script corresponding to your database type. For exampleon 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
execute mysqlrun the
. Note that thereexecute 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.
forInfo There are three migration scripts available:
migration-service-provider.sql
,migration-identity.sql
andmigration.sql
. However,
Download andfor all Carbon products except WSO2 IS, only the
migration.sql
script is required to be executed.Once you run
thethe migration
.sql scriptscript on the
old database.
Upgrading from DSS 3.1.1 to DSS 3.2.0
production database, copy the data 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
theyour staging database
you created when upgrading the database.
Connect the latest production server to the database as described below:
Configure.
Upgrading the configurations
To migrate the configurations to the staging database:
- 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
. See configuring master-datasources.xml. - Go to the
<DSS
_HOME>/repository/conf
directory and update datasource references in theuser-mgt.xml
andregistry.xml files
.
See See configuring user-mgt.xml and and configuring registry.xml.
- Go to the
- 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 scriptCopy 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.
- 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
UM_SYSTEM_USER_ROLE
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.