Hello Dojo,
We're evaluating Cassandra transition architectures in the context of a legacy DMS cluster to use newer versions of Cassandra (locally to start with, then possibly moving to a Cassandra cluster & OpenSearch).
Due to some specific constraints, DaaS/STaaS won't be an easy option for the short & mid-term.
In the legacy cluster (more than 20 DMAs in different WANs), all the DMAs are running Cassandra from the same host of the DMA, just on a separate drive ("D:") where SSD was not available.
Where each DMA is still provisioned with its own Cassandra DB, could we consider a phased migration (e.g. one DMA at a time) from Cassandra 3.11 to 4.0 (Linux based)?
And can the cluster have some agents only migrated to a local Cassandra or would this be prohibitive in terms of data synchronization?
Also keen to understand if a DMA migration can go from a single host (DMA + Cassandra DB) to a 2 hosts (DMA and a a separate Linux OS machine) in a single shot.
Any steer will be helpful.
Hi Alberto, great questions. In essence,
Q: “In a standalone Cassandra-running DMS, is it possible to have agents pointing to agent-exclusive Linux-hosted Cassandra nodes while others still use their co-hosted (Windows) Cassandra instances?”
A: Yes, that’s possible - each DMA can connect to whichever Cassandra node it’s configured for (whether locally hosted or in a Linux VM), as long as it's running a supported version and the architecture is consistent across the cluster (standalone vs Cassandra Cluster architecture).
Q: “Is there a procedure to move Cassandra db data from Windows to a dedicated Linux host in one step?”
A: There isn’t a direct “lift-and-shift” method because Cassandra data files aren’t guaranteed to be portable between OSes (Windows to Linux) or major versions (from v3.11 on Windows to v4.0/1 on Linux). The recommended approach is to install and configure Cassandra on the new Linux host, then migrate the data using a dedicated export/import tool (ex. DSBulk, sstableloader, other?). This ensures format compatibility and minimizes any risk of data corruption. Our InfraOps team can provide further guidance on the correct procedure and required tools, if you choose to proceed - please don’t hesitate to reach out.
Hope this helps steer your migration planning!
Ciprian
Thanks for the prompt feedback, Ciprian – marking as solved.