Migrate from Cassandra 3.x to 4.x
This scenario is about migrating (upgrading) an existing Cassandra 3.x to Cassandra 4.x. Migration will be done on a node-by-node basis so that there will always be some nodes available to service client requests.Next: Preparing for Migration
Preparing For Migration
It is important to verify that all the nodes are ready before beginning a migration.
- All nodes must be running
- All nodes need to have at least 50% disk space free
- All errors need to be handled
- Gossip needs to be operating properly
- Backups and repairs must be disabled
Zero Downtime Upgrades
Upgrade one node at a time to allow clients to access the cluster during the process.
- Operations at consistency level ALL must be temporarily reconfigured at a lower consistency level or they will fail
- No DDL operations can be running during the upgrade (e.g. CREATE TABLE)
- No DCL operations can be running during the upgrade (e.g. GRANT)
Resume normal operations after upgrading all nodes.
How The Migration Works
Cassandra 4.x nodes can read Cassandra 3.x SSTable files so there is no need to upgrade the data files directly. The migration process is:
- Flush memtables to disk
- Shut down the 3.x node
- Make sure the correct Java version is installed
- Install Cassandra 4.x
- Configure the 4.x node to point to the old data files
- Start the 4.x node
- Check the logs for errors
- Test the upgrade in a non-production environment first
- Update client drivers if necessary
- Run a full (application) regression test
- Converting nodes one at a time may be time consuming in large clusters
Want to get some hands-on experience? Give our interactive lab a try! You can do it all from your browser, it only takes a few minutes and you don’t have to install anything.
Learn more about Migrating to Cassandra 4.x