How it works
The new version is brought up alongside the running one. Once the new version is healthy, traffic switches over to it, and the old version drains in-flight queries before shutting down. Queries are never cut off - those already running finish on the version that started them, and new queries route to the new version once it’s ready. During the upgrade the cluster shows the Updating state; queries continue on the current version throughout.Automatic rollback
If the new version fails its health checks, e6data automatically rolls back to the previous version - you don’t need to intervene. The cluster stays on the version that was working.Triggering an upgrade
Change the cluster’s Version from its Edit screen. You select from a curated set of available releases; the e6data team manages which versions are published and tested. See Create and manage clusters and Runtime versions.You can’t change the version while a cluster is mid-deployment or in a failed state - wait for it to reach a steady state first.
See also
- Create and manage clusters
- Lifecycle states and error codes
- Upgrades and releases - platform-wide version management.