Versions Compared

Old Version 2

changes.mady.by.user Former user

Saved on

compared with

New Version Current

changes.mady.by.user Rukshani Weerasinha

Saved on

Key

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

This guide takes you through the steps for upgrading product versions from BRS 2.0.0 to BRS 2.1.0. For more information on release versions, see the Release Matrix.

...

The following are the limitations of upgrading:

  • This upgrading process 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 the upgrading process. It is impossible to restore a backup of the previous server and retry the upgrading progress.

Downtime

The downtime is limited to the time taken for switching databases when the migrating environment is connected to the production.

...

Upgrade Procedure

  1. Stop the current

    2. Governance registry server.
    Note

    Before discarding the old GREG instance, please take a backup of the GREG_HOME/solr directory. Solr-based index is required to re-index all the resources once migrated.

    Download WSO2 Governance Registry 4.6.0 from http://wso2.com/products/governance-registry/. 

  2. BRS 2.0.0 server.

  3. Select the relevant script for the upgrade

    from 

    from here

    . Select the migration.sql script corresponding to your database type. E.g., If

     on 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 mysql

    run the execute mysql-migration.sql

    .Note that there

     command in MySQL (you would use Oracle or MSSQL to run the script if that is the database you are using). Running this script will ensure that the database is upgraded with the additional tables and schemas which are required for BRS 2.1.0.

    Info

    There are three migration scripts available: migration-service-provider.sql, migration-identity.sql and migration.sql. However,

     for

    for all Carbon products except WSO2 IS, only the migration.sql script is required to be executed

    .  

    .

  4. Once you run the migration script on the production database, copy the data from your production database to the staging database you created when preparing to upgrade. This becomes the new database for your new version of BRS.
  5. Download WSO2 Business Rules Server 2.1.0 from http://wso2.com/products/business-rules-server/.
  6. To connect the new product version to the
    7. migrated
  7. upgraded (staging) database, configure the following files:
    8.  
  8.   
    1. Configure
    9.  <PRODUCT
    1.  <PRODUCT_HOME>/repository/conf/datasources/master-datasources.xml.
    10.  
    1. See here for more information on how to do this for your database.

    2. Go to the <PRODUCT _HOME>/repository/conf directory and update the datasource references

    11. in 

    1. in user-mgt.

    12. xml, registry.xml and api-manager.xml. 

Migrating the configurations

  1. Open the GREG_HOME/repository/conf/user-mgt.xml file and add the following property to the existing AuthorizationManager configuration as shown below.

    Code Block
    <Property name=“CaseSensitiveAuthorizationRules">true</Property>

  2. In the new product version, open GREG_HOME/repository/conf/registry.xml and change the value of this indexing configuration as shown below.

    Code Block
    <lastAccessTimeLocation>/_system/local/repository/components/org.wso2.carbon.registry/indexing/lastaccesstime460</lastAccessTimeLocation>

  3. 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.

    4. Start the server

    1. xml and registry.xml to match the updated configurations in the master-datasources.xml file which you made in the above step. The following are sample configurations if the datasource is jdbc/WSO2CarbonDB.

      Code Block
      languagexml
      titleregistry.xml
      <dbConfig name="wso2registry">
    <dataSource>jdbc/WSO2CarbonDB</dataSource>
</dbConfig>
      Code Block
      languagexml
      titleuser.mgt.xml
      <UserManager>
  <Realm>
  <Configuration>
  ...
  <Property name="dataSource">jdbc/WSO2CarbonDB</Property>
  </Configuration>
  ...
  </Realm>
</UserManager>

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.