Versions Compared

Old Version 2

changes.mady.by.user Former user

Saved on

compared with

New Version 3

changes.mady.by.user Former user

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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

Table of Contents
maxLevel3
minLevel3

Preparing to

...

upgrade

 Before starting Complete the upgrade, the following prerequisites must be followed on the database.

...

.

  • 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 <AS_HOME> directory can simply be copied to the new database.

  • Stop all the Carbon servers connected to the database before running the upgrade migration 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:

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

Downtime

The downtime is limited to the time taken for switching databases when the migrating environment staging database is connected promoted to the actual production status.

Upgrade Procedure

...

Upgrading the database

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

  1. Stop the current server.
  2. Select the relevant script for the upgrade from here. Select the migration.sql script corresponding to your database type.  E.g., If 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.0 to DSS 3.1.1

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

  1. Connect the latest production server to the database as described below: 
    - Configure - Go
  2. 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.
  3. 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 - Recommended Tests

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.

  • The staging database should be used as the new production database with the new Carbon server. The staging server should have the configurations equivalent to the production server. Map the production domain to the staging environment, when the staging environment is running smoothly. This upgrade should be done during a period when there is low traffic on the system.

  •  

Once the above tests are run successfully, it is safe to consider that the upgrade is ready for production. However However, it is always advised to carryout testing on test any features that are being used in production.