Versions Compared

Key

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

This page takes you through the steps for upgrading from SS 1.0.3 version to SS 1.1.0. For more information on release versions, see the Release Matrix

...

  • Before you upgrade to the latest version of WSO2 SS, you create a staging database, which is essentially an empty database. Note that you should NOT connect a new version of WSO2 SS to an older database that has not been upgraded. 

  • Make a backup of the database and the <SS_HOME> directory prior to upgrading. The <SS_HOME> directory can simply be copied to the new databasedirectory.

  • 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 typesif the database type is the same. 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.

...

  1. Configure the following files for the new production server. See the instructions for changing the default RSS configuration for details on how to update these files.
    • Go to the <SSthe <SS_HOME>/repository/conf/datasources directory datasources directory and update the  master-datasources.xml file  file .
    • Go to the  <SS_HOME>/repository/conf  directory and update datasource references in the  user-mgt.xml  and  registry.xml files.
    • Go to the <SS_HOME>/repository/conf  directory and update the persistence.xml and rss-config.xml files.
  2. Perform any configurations required for the server, e.g., external user stores, clustering, caching, mounting. 

    Note

    Note that configurations should not be copied directly between servers. 

     

  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

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.