Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
By Ben Slater, Chief Product Officer, Instaclustr.
Moving a live Apache Cassandra deployment to a new location? It’s natural to have some concerns, such as how you can keep Cassandra clusters 100% available throughout the process. But, the fact is that if your application is able to remain online throughout connection setting changes, it can remain fully available during this transition. For extra protection and peace of mind, the following technique also includes a rapid rollback strategy to return to your original configuration, up until the moment the migration is completed.
Here’s a recommended seven-step Cassandra cluster migration order-of-operations that will avoid any downtime:
1. Get Your Existing Environment Ready.
First of all, make sure that your application is using a datacenter-aware load balancing policy, as well as LOCAL_*. Also, check that all of the keyspaces that will be copied over to the new cluster are set to use NetworkTopologyStrategy as their replication strategy. It’s also recommended that all keyspaces use this replication strategy when created, because altering this later can become complicated.
2. Create the New Cluster.
Now, it’s time to create the new cluster that you’ll be migrating to. A few things to be careful about here: Be sure that the new cluster and the original cluster use the same Cassandra version and cluster name. Also, the new datacenter name that you use must be different from the name of the existing datacenter.
3. Join the Clusters Together.
To do this, first make any necessary firewall rule changes to allow the clusters to be joined, remembering that some changes to the source cluster may also be necessary. Then, change the new cluster’s seed nodes—and start them. Once this is done, the new cluster will be a second datacenter in the original cluster.
4. Change the Replication Settings.
Next, in the existing cluster, update the replication settings for the keyspaces that will be copied, so that data will now be replicated with the new datacenter as the destination.
5. Copy the Data to the New Cluster.
When the clusters are joined together, Cassandra will begin to replicate writes to the new cluster. It’s still necessary, however, to copy any existing data over with the nodetool rebuild function. It’s a best practice to perform this function on the new cluster one or two nodes at a time, so as not to place an overwhelming streaming load on the existing cluster.
6. Change Over the Application’s Connection Points.
After all uses of the rebuild function are completed, each of the clusters will contain a complete copy of the data being migrated, which Cassandra will keep in sync automatically. It’s now time to change the initial connection points of your application over to the nodes in the new cluster. Once this is completed, all reads and writes will be served by the new cluster, and subsequently will be replicated in the original cluster. Finally, it’s smart to run a repair function across the cluster, to ensure that all data has been replicated successfully from the original.
7. Shut Down the Original Cluster.
Complete the process with a little post-migration clean up, removing the original cluster. First, change the firewall rules to disconnect the original cluster from the new one. Then, update the replication settings in the new cluster to cease replication of data to the original cluster. Lastly, shut down the original cluster.
And there you have it: Your Apache Cassandra deployment has been fully migrated, with zero downtime, low risk, and in a manner completely seamless and transparent from the perspective of your end users.
About the Author
Ben Slater is Chief Product Officer at Instaclustr, a provider of enterprise-grade, hosted, and fully managed Apache Cassandra open source data infrastructure in the Cloud.
