Apache Cassandra version upgrades
Version upgrades can be arranged by contacting Instaclustr Support.
Cassandra Versioning
From: http://cassandra.apache.org/doc/latest/cql/changes.html?#versioning
Versions take the form X.Y.Z where X, Y, and Z are integer values representing major, minor, and patch level respectively.
| version | description |
|---|---|
| Major | The major version must be bumped when backward incompatible changes are introduced. This should rarely occur. |
| Minor | Minor version increments occur when new, but backward compatible, functionality is introduced. |
| Patch | The patch version is incremented when bugs are fixed. |
You can find the currently running version number on cluster information page of the Instaclustr console.
Major version upgrades
e.g. 2.x to 3.x
Contact Instaclustr Support to discuss the appropriate upgrade path for your cluster. Whilst it is rare, potentially breaking changes can be introduced between major versions, so we strongly recommend testing the upgrade in a non-production cluster before applying the upgrade to production.
Minor version upgrades
e.g. 3.11.1 to 3.11.2
Minor version upgrades are considered lower risk and include numerous bug fixes. Instaclustr will contact you if we detect that your cluster may be affected by a bug.
Upgrade process
In most cases, cluster upgrades can occur with no downtime. The typical cluster upgrade process looks like this (all steps excluding customer verification are completed by Instaclustr):
- Take a backup of the cluster
- Stop C* on all nodes in one rack and upgrade to target version (approx 5-10 minutes duration)
- Start upgraded C* on all nodes in the rack.
- Customer confirms that application is operational
- Upgrade remaining racks
- Run upgradesstables on all nodes in one rack in parallel and monitor cluster performance (1 day – 1 week+ depending on data size). This operation may have an impact on the nodes (increased CPU), however Instaclustr will be monitoring the cluster closely for the duration. Whilst Cassandra will operate with a mix of old/new sstables, some docs say that running on old SSTables may have an impact on performance so the upgrade isn’t considered complete until this step is taken.
- Repeat upgradesstables for each remaining rack.
- Final customer verification.
Instaclustr support will work closely with you prior to the upgrade to tailor the upgrade process to your specific use case. Where you have a non-production cluster hosted with us, we will conduct the upgrade in the lower environment prior to the production upgrade.
FAQ
How often should I upgrade the version on my cluster?
If you are not currently being affected by any bugs, then it is ok to remain on the same version for extended periods of time. We recommend scheduling a roadmap item in your development backlog to review and upgrade the Cassandra version at least yearly.
Customers on older versions of Cassandra (<2.1) should be aware that the Apache Cassandra project no longer maintains earlier versions, and Instaclustr will also be phasing out support of those versions very soon. If you are on a version older than 2.1 we recommend upgrading as a matter of urgency.
Occasionally, Instaclustr will initiate fleetwide upgrades if we become aware of major bug or security fixes that would benefit all customers.
What version should I upgrade to?
Generally, we recommend upgrading to the latest version. However, Instaclustr closely monitors each Apache Cassandra release and will make available the latest stable version for provisioning.
Keep an eye on our blog for updates about Apache Cassandra releases.
Can we request for the upgrade to happen at a particular time?
Yes, of course. Our support team operates 24/7 so we can accommodate upgrades during quiet periods in all time zones. However, we may request that one of your engineers is available during the upgrade for verification and as a contact point in case of issues.
Please note, we require a minimum of one week notice for weekend upgrades.
Will Instaclustr upgrade my cluster without notice?
No. If we feel it is necessary to upgrade your cluster to resolve major bugs or security vulnerabilities, we will reach out to you to discuss and coordinate the upgrade.
Please note our support policy around upgrades:
Instaclustr ensures our clusters are running a recent, stable version of the core technology (Cassandra, Kafka, etc) and underlying operating system, with the latest version of our monitoring software. We will advise of any upgrade of the version prior to changing the existing configuration. Customers may request that Instaclustr defer an upgrade by up to three months of the proposed date.
Do we need to update the client drivers?
Check version compatibility on your driver github page.
Can you rollback the version upgrade?
Rollback becomes increasingly more difficult at each step of the upgrade process. Cassandra does not have mechanisms for, nor make any guarantees about downgrading versions like it does for upgrading. It is a manual process and should be avoided unless in extreme circumstances.
Before all nodes are upgraded
Roll-back can be performed without cluster downtime. Any new SSTables written out by the new Cassandra version would need to be manually removed, then a repair is required to ensure the consistency of any data written during the transition period.
After all the nodes are running the new version
All data written since upgrade would need to be manually extracted from the SSTables written out by the new version of Cassandra, and would be unavailable until it was re-imported to the cluster.
After running upgradesstables
At this point, the cluster would need to be restored from backup. This is a time-consuming process and may require cluster downtime as well as new data likely being unavailable for a period of time.
If you have any further questions or require detailed planning and advice for your use case, please contact instaclustr support.
By Instaclustr Support