You can replace the node directly why to add a node and decommission the another node. Just replace the node with the new node and your topology remains the same so no need to run the cleanup .
On Fri, May 5, 2023 at 10:26 AM Jaydeep Chovatia <chovatia.jayd...@gmail.com> wrote: > We use STCS, and our experience with *cleanup* is that it takes a long > time to run in a 100-node cluster. We would like to replace one node every > day for various purposes in our fleet. > > If we run *cleanup* after each node replacement, then it might take, say, > 15 days to complete, and that hinders our node replacement frequency. > > Do you see any other options? > > Jaydeep > > On Thu, May 4, 2023 at 9:47 PM Jeff Jirsa <jji...@gmail.com> wrote: > >> You should 100% trigger cleanup each time or you’ll almost certainly >> resurrect data sooner or later >> >> If you’re using leveled compaction it’s especially cheap. Stcs and twcs >> are worse, but if you’re really scaling that often, I’d be considering lcs >> and running cleanup just before or just after each scaling >> >> On May 4, 2023, at 9:25 PM, Jaydeep Chovatia <chovatia.jayd...@gmail.com> >> wrote: >> >> >> Thanks, Jeff! >> But in our environment we replace nodes quite often for various >> optimization purposes, etc. say, almost 1 node per day (node *addition* >> followed by node *decommission*, which of course changes the topology), >> and we have a cluster of size 100 nodes with 300GB per node. If we have to >> run cleanup on 100 nodes after every replacement, then it could take >> forever. >> What is the recommendation until we get this fixed in Cassandra itself as >> part of compaction (w/o externally triggering *cleanup*)? >> >> Jaydeep >> >> On Thu, May 4, 2023 at 8:14 PM Jeff Jirsa <jji...@gmail.com> wrote: >> >>> Cleanup is fast and cheap and basically a no-op if you haven’t changed >>> the ring >>> >>> After cassandra has transactional cluster metadata to make ring changes >>> strongly consistent, cassandra should do this in every compaction. But >>> until then it’s left for operators to run when they’re sure the state of >>> the ring is correct . >>> >>> >>> >>> On May 4, 2023, at 7:41 PM, Jaydeep Chovatia <chovatia.jayd...@gmail.com> >>> wrote: >>> >>> >>> Isn't this considered a kind of *bug* in Cassandra because as we know >>> *cleanup* is a lengthy and unreliable operation, so relying on the >>> *cleanup* means higher chances of data resurrection? >>> Do you think we should discard the unowned token-ranges as part of the >>> regular compaction itself? What are the pitfalls of doing this as part of >>> compaction itself? >>> >>> Jaydeep >>> >>> On Thu, May 4, 2023 at 7:25 PM guo Maxwell <cclive1...@gmail.com> wrote: >>> >>>> compact ion will just merge duplicate data and remove delete data in >>>> this node .if you add or remove one node for the cluster, I think clean up >>>> is needed. if clean up failed, I think we should come to see the reason. >>>> >>>> Runtian Liu <curly...@gmail.com> 于2023年5月5日周五 06:37写道： >>>> >>>>> Hi all, >>>>> >>>>> Is cleanup the sole method to remove data that does not belong to a >>>>> specific node? In a cluster, where nodes are added or decommissioned from >>>>> time to time, failure to run cleanup may lead to data resurrection issues, >>>>> as deleted data may remain on the node that lost ownership of certain >>>>> partitions. Or is it true that normal compactions can also handle data >>>>> removal for nodes that no longer have ownership of certain data? >>>>> >>>>> Thanks, >>>>> Runtian >>>>> >>>> >>>> >>>> -- >>>> you are the apple of my eye ! >>>> >>>
