Unknown macro: {next_previous_links}
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Introduction

The following are the product versions and migration scenarios addressed in the guide.
Example:

  • Migrating from IS 4.0.0 to IS 4.5.0/4.6.0.
  • Migrating from Carbon 4.0.0 to Carbon 4.2.0.

For more information on release versions, see the Release Matrix.

Limitations of migration

The following are the limitations of migration

  • This migration can be only done for same database types. For example, if you are using MySQL currently and you need to migrate to Oracle in the new version, then these scripts will not work.
  • You cannot rollback migration. It is possible to restore a backup of the previous server and retry the migration progress.

Downtime

The downtime is limited to the switching time between databases, when the migrating environment is connected to the production.

Preparing to migrate

The following are the recommendations before running the migration:

  • The staging database should run as the production database server. As a result, once completing the migration process the database server should have the configurations required for a production server.
  • Ensure to take DB and system backups prior to migrating the database. The system backup can be taken by backing up the Carbon server home folder.
  • Shut down all the Carbon servers connected to the database before running the migration scripts.
  • Insert the data that is collected in the production system during the time the migration takes place, into the migrated database using a script. The database administrator should collect the data portion that is added to the production database while the migration is taking place. Generally the WSO2 support team will provide help in these types of situations.
  • New product (e.g., IS 4.5.0) must not be connected to the old database (e.g., IS 4.0.0) without executing the migration script.

Common errors

  • New product (e.g., IS 4.5.0) must not be connected to the old database (e.g., IS 4.0.0) without executing the migration script.

Migrating the system

Run the scripts provided on the old database (e.g., IS 4.0.0) before connecting the new production server (e.g., 4.5.0) to the database.

Follow the instruction below to migrate the system:

  1. Stop the current server (e.g., IS 4.0.0).
  2. Run the migration script on the old database (e.g., IS 4.0.0).
  3. Connect the latest production server (i.e., IS 4.5.0) to the database and 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

The following are the 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, once the staging environment is running smoothly. This migration 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 migration is ready for production. However, it is always advised to carryout testings on features that are being used in production.

  • No labels
Unknown macro: {next_previous_links2}