Note: I am doing this clone to same Kubernetes cluster but different namespace.
As part of my attempt to clone Cassandra Cluster, I will make the clone of volume from original cluster mount into the new Cluster node(pod). But during the initialization , the new cluster node tries to load the peers info from the SYSTEM table in the database. But this peers info is from original cluster and is not valid in my usecase. Also since both original and new cassandra clusters are on same k8s cluster, the new cluster node pod can still reach the old cluster nodes and this messes up both cassandra clusters.
Is there a way to not initialize the peers from SYSTEM.peers for the first time launch?
I’d test this carefully before implementing in production, but the instructions here outline a method to purge the gossip state from a system and might be a good starting point. (Especially this part: sudo rm -r /var/lib/cassandra/data/system/peers/*, I don’t think the rest is very relevant to you).
The important thing here is going to be ensuring that the token ranges match between the old and new clusters, so I’d keep a careful eye on nodetool describering as the cluster comes up, ensuring that the data has been assigned to the equivalent nodes (in terms of token ranges) in the new cluster.
It does sound like you’re doing things ‘the hard way’ here, what are you trying to achieve by cloning the DB? Are you creating a dev environment, taking a backup, gaming out a DR scenario?