Revision as of 15:43, December 16, 2016 by KrisMcG (talk | contribs) (Rollback to 8.5.201.09)
Jump to: navigation, search

Rolling back a migration

Rollback to 8.5.201.29+

Start

  1. Stop Web Services and Applications on the node with command: service gws stop
  2. Depending on how the new version was installed, do one the following:
    • If the new version was installed in the same folder where previous version was located, repeat the installation procedure for previous version.
    • If the new version was installed in a separate folder, update the GWS_HOME variable in the /etc/default/gws file to point on folder where the previous version is located, for example:
      # GWS_HOME
      #   defines the home folder of Genesys Web Service and Applications that is used for looking the JAR-file and configuration files.
      GWS_HOME="/usr/share/gws/8.5.201.29"

End

Rollback to 8.5.201.18

Since this version uses Java 7, you need to rollback your Web Services and Applications version and specify Java 7. The method by which you rollback your Java version depends on the method by which you upgraded the version.

Start

  1. Perform the steps in Rollback to 8.5.201.29+.
  2. To rollback your Java version, do one of the following:
    • Downgrade the default Java on the node; or
    • Update the JAVA variable in /etc/default/gw file to specify the Java 7 version.

End

Rollback to 8.5.201.09

Start

  1. Perform the steps in Rollback to 8.5.201.18.
  2. Stop and disable auto-run Web Services and Applications on the node.
    chkconfig gws disable; service gws stop
  3. If Jetty was installed as a service on the node, re-enable the Jetty service using the following command:
    chkconfig jetty9 enable
  4. Run the previous version of Web Services and Application, do one of the following:
    • If Jetty is installed as a service, use the following command:
      service jetty9 start
    • If Jetty is not installed as a service, run your Jetty initialization script.

End

Recover Cassandra from a snapshot

If the rollback to previous version is not successful, the cause might be database data corruption. In this case, restore the Cassandra database from the snapshot that you took before the migration. Detailed instruction depends on your Cassandra version and can be obtained here:

Comments or questions about this documentation? Contact us for support!