Upgrading WhereScape RED

WhereScape Versions

WhereScape RED has a four-part version number normally shown as xx.xx.xx.xx. An example of this may be 10.1.0.0. The first number represents the major release. The second number represents the metadata repository version. The third and fourth numbers relate to application-specific releases.

From the example above, we see that the current version is version 10 of WhereScapeRED. We are on version 10.1 of the metadata repository.

Metadata Changes

A change from a 10.0 release to a 10.1 release would indicate a change in the metadata tables. All metadata changes are non-destructive. They simply add new columns or new meta tables. In this way, they can be applied without harming an existing metadata repository. The impact of a metadata change is that the associated applications (namely the REDUI and RedCli executables) need to be at the same metadata version. Therefore, a 10.0.0.0 version of RED may not successfully run against a version 10.1 metadata repository.

Application changes

The final two numbers in the version represent application releases. Applications are deemed to be all of the executable images supplied with WhereScapeRED and the stored procedures. Application changes reflect enhancements and bug fixes. A change in the third number indicates a major enhancement in one of the application components and a change in the fourth number is a patch fix.

Upgrading RED

Upgrading WhereScape RED consists of the following steps:

1. Allow any active jobs to complete. Halting active jobs will allow running tasks to complete with no new tasks starting. Aborting active jobs will kill any running tasks and stop running jobs.
2. Stop all schedulers. Windows schedulers can be stopped via Windows Services. To stop a UNIX or Linux scheduler, kill the active scheduler process.
3. Close any WhereScape programs that are running on your machine.
4. Back up your metadata.
5. Install the new version of RED on your machine.
6. Run the RedMetadataValidate.exe found in the installation directory of RED. This function may re-compile existing or create new metadata procedures; metadata tables may be altered, or new tables created.
7. When performing an upgrade of RED:
   • Click OK when prompted to validate metadata tables.
   • Click Yes when prompted to re-create metadata views.
   • Click Yes when prompted to re-compile metadata procedures.
     

     Warning

     If the above steps are not all completed during an upgrade, the metadata may be left in an inconsistent state.

8. Restart all schedulers. Windows schedulers can be restarted via Windows Services. For any UNIX or Linux schedulers, these can be restarted by running the start-up script in the bin directory of each Azkaban Web Server or Executor.
9. Restart any halted or aborted jobs.
   
   

   Note

   1. Metadata tables do not change between minor releases, but metadata procedure often and usually do change.
   2. RED will not let you sign into an old repository version using a newer version of RED.
   3. RED will let you sign into a new repository version using an older version of RED but it will warn you that this may potentially cause issues.
   4. Side by side installations are possible (two versions in two directories on the same machine), but be careful with schedulers. If you install the new version of RED in a new directory, you must update the registry for each service to use the new version of RED.See Azkaban Upgrade troubleshooting section.