Read the following information carefully before you update Exasol to a different version.
Careful planning is the best way to ensure a successful update. Consider the following when planning your update:
Try out the new version on a test system.
If possible, test the update first on a system that closely resembles your production system. For more information, see Test.
Evaluate how critical this update is for your business, and plan to minimize impact.
For example, do not plan to update of Exasol close to or during a business-critical event such as a product release, as the update will always involve some downtime.
Read the Release Notes to understand how the changes in the new version will affect your system.
The release notes describe the changes that are introduced with each new version within the Exasol 8 release cycle. For example, the change log for Exasol 8.18.1 describes the changes between Exasol 8.18.0 and Exasol 8.18.1. To see all changes between your current version and the version you are updating to, you must read the change logs for all the interim releases.
For more information about Exasol releases and versions, see Product Life Cycle.
Include a full backup of data and a backup of BucketFS in your update plan.
A backup will always be required in the following scenarios:
- When migrating from Exasol 7.1 to Exasol 8. This will require that you back up your 7.1 database and restore it to a new Exasol 8 database. For more information, see Migrate from Exasol 7.1 to Exasol 8.
- If the update fails and you have to roll back the update to revert to the previous version. For more information, see Revert.
Define your acceptance criteria for the new Exasol version, then install the new version on a separate test system that is as similar as possible to your production system, and run acceptance tests on the test system. This will help ensure that the production system will perform as expected after the update.
Testing should be based on the full set of changes that were introduced between your previous Exasol version and the version you are updating to. For information about the changes in each new version, see Release Notes.
Testing should ideally cover all your relevant business use cases. The following suggestions can be used as a starting point:
- In your test system, mimic the structure of your production system (users, roles, schema, tables, etc.) as much as possible.
- If the new Exasol version supports a new version of a driver, use the latest supported version of that driver in your tests.
- Test the most frequently used queries from your production system. Which queries that are run frequently can be deduced from the audit logs (see Auditing).
- Run tests that mimic the typical load on your production system.
- Test all your UDFs.
- If the new Exasol version supports a new remote archive for backups, try storing some backups on the new remote volume.
For intormation about how to update to a new Exasol 8 version, see Update Procedure.
For information about how to migrate from Exasol 7.1 to Exasol 8, see Migrate from Exasol 7.1 to Exasol 8.
To prevent a risk of data loss and/or excessive downtime during the update, always update to a test system first before updating your production system. For more information, see Test.
If the update fails or if you experience issues after the update, you can roll back to your old version and restore the data from the backup.
Perform a new cloud deployment using your previous version of Exasol. For more information, see Deploy Exasol on AWS.
Restore the data that you backed up before the update. For more information, see Restore from Backup
Restoring backed up data to the system may result in data loss from the time that you took the backup until the time that you restore it.
Reverting to a previous version of Exasol will take considerably longer than an update, as it consists of a fresh installation of Exasol followed by a restore of your backed up data. Allow for the additional time when planning the update.
If you need assistance with the update, contact Support.