Migrate from Exasol 7.1
This section explains how to migrate an Exasol 7.1 database to the newest version of Exasol.
Introduction
Because of the differences in architecture that was introduced with Exasol 8 there is no direct update path from Exasol 7.1 to later versions. Instead, you must create a new Exasol deployment and restore a full backup of your existing Exasol 7.1 database on the new (empty) database.
The migration path is different depending on whether you are planning to create the new deployment on your existing hardware, or if you are deploying on new hardware or virtual instances in the cloud. Deploying on existing hardware will require a longer maintenance window, since you need to take your database offline while installing an operating system and Exasol software. You will also have to reinstall Exasol 7.1 and restore from backup in case the migration fails. If you are migrating to new hardware, you can simply put the old cluster online again to resume operations while you troubleshoot.
This section describes the procedures for both of these migration scenarios.
Migrate to deployment on new hosts |
Migrate to deployment on existing hardware |
|
|
To avoid excessive downtime and prevent a risk of accidental data loss, read through the instructions in this section and in Update Considerations carefully before you start the migration procedure.
If your database is running Exasol 7.0, you must update to 7.1 before proceeding. For more information, see Update from Exasol 7.0 to Exasol 7.1.
Maintenance window
The process of migrating your database to Exasol includes a planned maintenance window when the database is not available to users. The downtime begins at the step when you restart the database on a different port and ends when the backup has been successfully restored in Exasol.
The total required downtime is mainly determined by the restore time, since the majority of the backup time will be outside of the maintenance window. A restore operation will usually take approximately the same amount of time as the backup.
Example:
| Operation | Time required for operation | Database downtime required |
|---|---|---|
| Create level 0 backup | 5 hours | 0 |
|
Create level 1 backup |
30 minutes | 0 |
| Create level 2 backup | 30 minutes | 30 minutes |
|
Restore full backup (level 0 + 1 + 2) |
5 hours | 5 hours |
| Total downtime required for backup/restore operations | 5 hours 30 minutes | |
If you are reusing the existing hardware, the time needed to install the OS on the hosts and to install Exasol must also be added to the planned downtime.
You should also factor in the time that will be required for additional operations such as stopping and starting the database, and for reverting to the previous version in case the migration fails. Also consider factors in your system environment that might affect the operation, such as network capacity.
FAQ
Here are some frequently asked questions (and answers) relating to the process of migrating to Exasol. You can find more details in the various sections and articles in this documentation. If you need more information or need help with the migration procedure, create a support case to contact our Support team.
-
What versions of Exasol are available?
-
Exasol can be installed as a Linux application on hardware or on virtual instances in AWS, Azure, and GCP. You can also deploy Exasol as a native cloud application on AWS.
-
Can I use my existing license for Exasol?
-
No. Exasol 7.1 licenses are not valid in Exasol 8 or later because of differences in the license format. For information about how to obtain a valid license for Exasol, create a support case.
-
I have Platinum Support or Cluster Administration Service. Will Exasol still manage the OS patches?
-
No. Exasol is provided as a software package that you can install on a cloud service or on your own hardware, using a Linux distribution of your choice. Exasol services do not cover the management of the operating system.
-
Where can I get the change log from my current version to the latest Exasol version?
-
The release notes for all currently supported Exasol database releases are found in Release Notes - Database.
Each release note only describes the changes that are introduced with that specific release. To see all the changes between your current version of Exasol and the version that you are updating to, you must read the release notes for all the interim releases.
-
How long will the maintenance window be for a migration to Exasol?
-
The downtime will depend on the restore time and, if necessary, the software installation time. To learn more, see Maintenance window and the articles in this section that describe different migration scenarios.
-
Does Exasol 8 come with an administration application like EXAoperation?
-
Exasol 8 comes with several powerful APIs and configuration/installation tools. To learn more, see Administration Tools.
-
Is a Management Server (License Server) still required?
-
No. Exasol does not use a separate server for cluster management. The administrative interfaces are available on all nodes.
In native cloud deployments on AWS you can choose to include an access node (recommended but not mandatory), which will allow you to carry out administrative tasks that require shutting down the database nodes, such as when you want to vertically scale the main cluster (change instance types).
-
Does Exasol have a monitoring Service with Exasol 8?
-
Yes. For more information, see Exasol Monitoring Service FAQ.
