What you will learn
Moving a workload to a different cluster is not the same operation as adding a datacenter to the existing ring. This tutorial explains the migration decisions and uses the DSBulk tutorial for the copy procedure.
Before you begin
Use a disposable Cassandra 4.1 lab with three nodes in dc1, distinct node addresses, and a dedicated CQL account. The keyspace is tutorial; its replication factor is 3. Run nodetool on a database node with the deployment’s JMX authentication configured. Record the schema and confirm a restorable backup before changing topology. Hostnames ending in .sample.com identify roles; replace them with your own lab addresses.
1. Choose the isolation boundary
Inventory which services write each table, their consistency levels, retention requirements, and peak load. Move all consumers of a shared writable table together or design a supported synchronization path. Do not assume a table described as a cache can be rebuilt without identifying its system of record.
2. Build the independent destination
Use a distinct cluster name, dedicated nodes, explicit replication, and new application credentials. Size for the workload plus migration overhead. Validate the new ring with read/write tests before loading production-shaped data.
3. Copy at an agreed boundary
Follow the DSBulk migration tutorial. For an offline copy, stop relevant writers, export, load, and reconcile. For an online move, separately define ordering, duplicate handling, deletes, and the final delta boundary.
4. Route a controlled cohort
Change the selected service’s configuration to the new cluster, refresh connection pools, and test the exact partition-key queries. Use a small cohort only if write ownership remains unambiguous. Measure errors, latency, and data freshness.
5. Close the migration
Retain source data through the acceptance period. Remove old credentials and background jobs only after confirming all consumers have moved. Datacenter or node retirement, if later required, is a separate topology change.
Verify the result
The migrated service uses only its intended cluster and returns reconciled values. Verify scheduled jobs, repair, backup, alerting, and restore coverage on the new cluster.
Troubleshooting
Split writes usually indicate stale application instances or background jobs. Repeated target timeouts can be a hot-partition or capacity issue rather than a network problem. Compare driver local-datacenter settings with actual placement.
Recovery and next steps
Before target writes, the source remains a simple fallback. After target writes, reconcile them before routing traffic back. Retire the source only after the retention and acceptance criteria are satisfied.