Streaming with vnodes is not always pleasant – rebuild uses streaming (as does bootstrap, repair, and decommission). The rebuild delay you see may or may not be related to that. It could also be that the streams timed out, and you don’t have a stream timeout set. Are you seeing data move? Are the new nodes busy compacting? Secondary indexes themselves may not cause problems, but there are cases where very large indexes (due to very large partitions or unusual cardinalities) may case problems.
The other way is to backup your data, make a new vnode cluster, and load your data in with sstableloader Known issues are that streaming with vnodes creates a lot of small tables and does a lot more work than streaming without vnodes Not necessarily See #2 From: cass savy Reply-To: "user@cassandra.apache.org" Date: Wednesday, December 9, 2015 at 1:26 PM To: "user@cassandra.apache.org" Subject: Switching to Vnodes We want to move our clusters to use Vnodes. I know the docs online say we have to create new DC with vnodes and move to new dC and decommission old one. We use DSE for our c* clusters.C* version is 2.0.14 1. Is there any other way to migrate existing nodes to vnodes? 2. What are the known issues with that approach? 3. We have few secondary indexes in the keyspace, will that cause any issues with moving to vnodes? 4. What are the issues encountered after moving to vnodes in PROD 5. anybody recommend Vnodes for Spark nodes. Approach : Moving to new DC with vnodes enabled: When I tested it for a keyspace which has secondary indexes, rebuilds on Vnode enabled Datacenter takes days and don't know when it completes or even if it will complete. I tried with 256,32,64 tokens per node but no luck. Please advise.
smime.p7s
Description: S/MIME cryptographic signature
