IBM Worklight v5.0.5 > WL server administration > High availability

Upgrade a production cluster


Overview

The client-server protocol supported by the IBM Worklight V5.0 Server is different from the one supported by the IBM Worklight V4.2 Server. An IBM Worklight V5.0 Server cannot service applications that are built on top of IBM Worklight V4.2. Before upgrading a production cluster, choose how to migrate users from V4.2-based to V5.0-based apps.


Migration option 1

  1. Set up two server clusters in production...

    • V5.0 server cluster for V5.0 apps
    • V4.2 server cluster for V4.2 apps

  2. Remote disable the V4.2-compatible apps on the V4.2 server, directing users to download the V5.0-compatible apps.


Migration option 2

  1. Upload both the original V4.2 apps as well as the V5.0 apps to the V5.0 server

  2. Remote disable the V4.2 apps

  3. Configure the reverse proxy to redirect or forward V4.2 requests to the V5.0 server, so that requests from devices running V4.2 apps reach the V5.0 server

Migrating apps from V4.2 to V5.0 includes updating the native IBM Worklight libraries packaged with the applications. If you distribute iOS applications via the Apple app store, certify the new V5.0-compatible version of the apps before making them available for public use by making a v5.0 production server accessible to the Internet via public URL so the apps can be run and certified. This V5.0 server must be exposed through a different public URL than the V4.2 servers, to avoid confusion between the two.


Upgrade production cluster

  1. Install 5.0 server cluster.

  2. Duplicate the 4.2 database and migrate it to 5.0....

      cd Worklight_Home/WorklightServer/databasesi

    ...and run either...

    • upgrade‑Worklight-mysql.sql
    • upgrade‑Worklight‑oracle.sql

  3. Migrate the reports database.

      cd Worklight_Home/WorklightServer/databases

    ...and run either...

    • upgrade‑Worklightreports-mysql.sql
    • upgrade‑Worklightreports-oracle.sql

  4. Install the production customization.

  5. Deploy old-apps so that you can remote disable them.

  6. Deploy new-apps and new-adapters.

    At this point you are having two server clusters: One of 4.2 and another one of 5.0.

  7. If you chose Option 1 above for migrating users from V4.2-based to V5.0-based apps, optionally remote disable the 4.2 apps in the 4.2 server, directing users to the new 5.0-compatible apps.

  8. If you chose Option 2 above for migrating users from V4.2-based to V5.0-based apps, remote disable the old-apps in the 5.0 server and configure the reverse proxy to forward or redirect requests to 4.2 server to the 5.0 server.

    The upgrade procedure is now complete.


Parent High availability




+

Search Tips   |   Advanced Search