Update Considerations

A new version always comes with new features, improvements, and bug fixes, such as better performance, a new driver, or scalability. However, you should read the following information before you update to a new version. This section covers the considerations before you update to a new Exasol version as well as a possible need to revert to a prior version.

Plan

Things to consider when you plan to update:

  • An ideal way of planning the update is either development environment > test > pre production > production, or from test > production. This could be based on your deployment method.
  • Check the change logs to identify the changes in the new version. You can identify the new changes through the change logs available on the Exasol Downloads portal. The change logs are visible under each version for the Exasol 7.1 release cycle. For example, if you check the change log for Exasol 7.1.5, you will find the new changes introduced in Exasol 7.1.5 from Exasol 7.1.4. If you want to know about changes introduced between your version and the one you are updating to, you must check change logs for all the interim releases.
  • Plan to introduce and test new features sequentially, not concurrently. If there is a problem, it is easier to identify the cause by limiting it to a specific feature instead of a list of new changes.
  • Avoid updating during a crucial release/event time and evaluate how critical this update is for your business.
  • Always plan a backup of the data and BucketFS (see BucketFS). The backed up data will be used in the following scenarios:
    • When you also have OS with the database changes in the new Exasol version. In this scenario, update includes a fresh installation followed by restoring data from your old Exasol version.
    • An update failure. In this scenario, you have to rollback to your old version.

    The time taken in restoring the data is similar to the time taken in backing it up. It depends on the size of the backup.

  • In case the update fails, plan for the need to revert, or rollback, back to the previous version including the time to restore the old system. For more details, see Revert.
  • If possible, try out the new version on the test system that closely resembles your production system. For more details, see Test.

Test

Define acceptance criteria for the new Exasol version and test it accordingly. The goal of this test is to ensure that when you update your production system, your system should run as expected. When the test system has been updated, test out each changed behavior with the new version of Exasol. For example:

  • If the new version supports a new standard of a driver, use the latest version of the drivers for your tests.
  • Try to mimic the structure of your production system in your test system as much as possible. For example, users, roles, schema, tables, and so on.
  • On your test system, test the frequently used queries (from your production system). If you want to know which queries are run frequently, you can find them from the audit logs (see Auditing).
  • Try to run tests that mimic the load similar to your production system.
  • Test all your UDFs with the new version.
  • If the new version supports a new remote archive for backup and it fits into your requirement, try that out by storing some backups to the new remote volume.

Do not limit your actual testing to only the examples above. Your testing should be based on the complete change logs from your old Exasol version to the new version you are updating to, and it should also cover your business use cases.

Update

Always update to a test system so that you can test the new version for all the new changes without affecting your production system.

Do not make hardware changes on the production system at the same time as you are updating the Exasol version, as this can make it very difficult to find the root cause of any performance issues after the update.

Based on your current version, update to a new version of Exasol by following the instructions given in the documentation (see Next Step). The standard methods for update are:

  • Database Update: In this scenario, take a backup of your data and then install the package for the new version through EXAoperation. You may not need the backed-up data for restore in this scenario. However, your backup will still be useful for your regular system backup.
  • Database Update with OS Changes: In this scenario, take a backup of your data, install the new version with all relevant patches, and then restore the backed-up data to the new installation.

Revert

Reverting to a previous version takes considerably longer than an update because it is a completely new installation followed by a restore of your backed-up data.

If your system update fails due to any reason or you come across any issue after you start working with the new version, you can rollback to your old version by doing the following:

  1. Perform a fresh installation of your old Exasol version on your cluster (see Next Step). If you don't have the installation package, download it from the Exasol Downloads portal.
  2. Restore the data you backed up before the update from the older version to the new installation.

Restoring from a backup may result in data loss from the time that you took the backup until the time you restore it.

Contact Support

If you have any question about the update, contact Exasol support.

Next Step

Update

You can update to a new version of Exasol by following instructions given in Update ProcedureUpdate ProcedureUpdate ProcedureUpdate Procedure.

Revert to Prior Version

In case you need to revert to a previous version, follow the instructions given in Installation to reinstall the older version of Exasol.