Nodetool tpstats and netstats should give you a hint why it’s not joining
If you don’t care about consistency and you just want it joined in its current form (which is likely strictly incorrect but I get it), “nodetool disablegossip && nodetool enablegossip” in rapid succession (must be less than 30 seconds in between commands) will PROBABLY change it from joining to normal (unclean, unsafe, do this at your own risk). > On Jul 31, 2020, at 11:46 PM, onmstester onmstester > <onmstes...@zoho.com.invalid> wrote: > > > No Secondary index, No SASI, No materialized view > > Sent using Zoho Mail > > > > ---- On Sat, 01 Aug 2020 11:02:54 +0430 Jeff Jirsa <jji...@gmail.com> wrote > ---- > > Are there secondary indices involved? > > On Jul 31, 2020, at 10:51 PM, onmstester onmstester > <onmstes...@zoho.com.invalid> wrote: > > > Hi, > > I'm going to join multiple new nodes to already existed and running cluster. > Each node should stream in >2TB of data, and it took a few days (with 500Mb > streaming) to almost get finished. But it stuck on streaming-in from one > final node, but i can not see any bottleneck on any side (source or > destination node), the only problem is 400 pending compactions on joining > node, which i disabled auto_compaction, but no improvement. > > 1. How can i safely stop streaming/joining the new node and make it UN, then > run repair on the node? > 2. On bootstrap a new node, multiple tables would be streamed-in > simultaneously and i think that this would increase number of compactions in > compare with a scenario that "the joining node first stream-in one table then > switch to another one and etc". Am i right and this would decrease > compactions? If so, is there a config or hack in cassandra to force that? > > > Sent using Zoho Mail > > > > > >
