[CASSANDRA-8304] Explore evicting replacement state sooner

• Type: Improvement
• Status: Open
• Priority: Normal
• Resolution: Unresolved
• Fix Version/s: 5.x
• Component/s: Legacy/Distributed Metadata, Local/Startup and Shutdown
• Assignee: Brandon Williams
• Reporter: Brandon Williams

Authors

Brandon Williams

• Created: 12/Nov/14 23:59
• Updated: 15/Mar/23 21:38

Description

As a follow-up to CASSANDRA-8260 Tyler suggests we evict and quarantine in step 2. I don't want to change any core gossip logic in 2.0 at this point, but his theory seems feasible and we should explore it for 3.0.

Issue Links

• depends upon: CASSANDRA-8260 Replacing a node can leave the old node in system.peers on the replacement
• depends upon: CASSANDRA-8252 dtests that involve topology changes should verify system.peers on all nodes
• is related to: CASSANDRA-18319 Cassandra in Kubernetes: IP switch decommission issue