Cassandra Upgrade 2.1 to 3.11

Question

I have a multi(two) DC Apache cassandra cluster with active replication. DC1 is primary(production) and DC2 is DR. I plan to upgrade from 2.1 to 3.11. What is the best way to achieve the upgrade without downtime in the production?

Answer 1

While the versions might be different, the steps found here can mostly be followed.

Upgrade steps for Cassandra 3 -> 4

First, I would start by ensuring that a complete repair has successfully run on the cluster.

Second, I would reach out to the application team(s), and make sure that they are using a version of the driver that can connect to both Cassandra 2 and Cassandra 3. I'd also (just for the duration of the upgrade) have them force a CQL binary protocol connection version of v3. Otherwise, the driver will negotiate to the highest possible version in the cluster, and then fail to reconnect to the old nodes during the upgrade process; possibly leading to application downtime.

Then these steps can be taken, one node at a time:

• Flush memtables to disk (nodetool drain)
• Shut down the node
• Make sure the correct Java version is installed (Java 8 for Cassandra 3.x)
• Install the new version of Cassandra
• Configure the new yaml file (don't just copy the old one in, they do change)
• Configure the new version to point to the old data files
• Start the node and check system.log for errors

Once the entire cluster has been upgraded, run nodetool upgradesstables on one node at a time. Cassandra 3 can read Cassanra 2.1's data files, but not the other way around.

Note that your users are going to be converted to "roles," as Cassandra 3 uses a RBAC security model (Cassandra 2.1 does not). Cassandra 3 will do this conversion for you, and you can delete the original user-based tables:

• system_auth.users
• system_auth.credentials
• system_auth.permissions

Note, the upgrade process can be reversed (back to Cassandra 2.1) at any time, until either of two actions have been taken:

• Deleting the legacy user-based tables.
• Running nodetool upgradesstables.

Once either of those tasks have been completed, there's no going back. At least not easily.

Good luck!

Answer 2

You also have another option to build the destination/target cluster on the desired version (recommended to use the latest 4.1.x version which is 4.1.3 as of this writing) directly and use Zero Downtime Migration (ZDM) utility if you're on a supported Apache Cassandra 2.1.6+ version for your source/origin cluster.

It is also critical that you understand the overall upgrade path by referencing the link shared earlier in the prior answer or this documentation.