Hi, responses inline... > On 11 Feb 2025, at 17:36, Long Pan <panlong...@gmail.com> wrote: > > Hey Sam, > The improvements in CEP-21 look awesome. I am currently running Cassandra 4.1 > and plan to upgrade to 5.x in the future, where CEP-21 has been implemented. > I have a few questions: > • I am using the single-token architecture, where operators set the token > for every node by explicitly configuring the initial_token field in > cassandra.yaml. There should be no conflict between this setup and CEP-21, > correct? My understanding suggests it is compatible, but I’d like to confirm > it to be safe.
Absolutely, single token configuration is completely supported. > • In the CEP, you provided a detailed explanation and examples of the > bootstrap and decommission flows (link). Would you mind extending this to > cover the flow for node replacement as well? Node replacement is a lot like bootstrap, but slightly simplified as it doesn't involve any range splitting / adding new tokens. The replacement node just takes ownership of the range(s) previously replicated by the node being replaced. The sequencing of steps is the same as bootstrap though : 1) new node added as write replica 2) new node streams existing data from peers 3) new node becomes read replica & old node removed from set of read replicas 4) old node remove from write replica set > • Since the Cassandra Management System (CMS) holds the source of truth > for cluster topology, will there be a nodetool command to query CMS directly > for this information? As operators, we often need to retrieve topology > details, such as which nodes are leaving, live, joining, moving, or > unreachable. Currently, this information is obtained via a JMX call to > org.apache.cassandra.db:type=StorageService, which is gossip-backed. However, > gossip mismatches can lead to non-deterministic results across nodes. The topology-related methods on the StorageService mbean interface report state according to cluster metadata now and don't rely on gossip state any more. By extension, nodetool commands like "ring" & "status" are backed by cluster metadata. > Thanks, and I appreciate your insights! Thanks a lot, Sam > > Best, > Long
