Agree with Paulo on this one. If you're running a cluster on K8s, in the cloud, or under some other conditions in which IPs change, the cassandra-topology.properties file is going to quickly become a burden. Especially if that cluster has more than just a few nodes.
Increasing your cluster from 99 nodes to 120? Need to make sure that updated file ends up on all 120 nodes, with all 120 IPs. Also, I'm pretty sure that a node can't read the new file without a restart. So now you're talking about bouncing a 100+ node cluster just to add new nodes. Same with replacing a single node or IP. Update the file, push it out to all nodes, and restart all nodes. Basically, the cassandra-rackdc.properties file is preferred because it makes operations easier at scale. Config files that change less make everyone happier! At my last gig, we built the propagation of the cassandra-rackdc.properties file into our node-add automation. That way it looks at the target instance, and already knows which DC and rack to inject into the file. Thanks, Aaron P.S. - When using the cassandra-rackdc.properties file, the prevailing production wisdom has always been to delete the cassandra-topology.properties file to keep it from interfering. Not sure if that's still an issue or not, but it was in the 3.x versions. On Thu, Jun 2, 2022 at 7:59 AM Paulo Motta <pauloricard...@gmail.com> wrote: > It think topology file is better for static clusters, while rackdc for > dynamic clusters where users can add/remove hosts without needing to update > the topology file on all hosts. > > On Thu, 2 Jun 2022 at 09:13 Marc Hoppins <marc.hopp...@eset.com> wrote: > >> Hi all, >> >> Why is RACKDC preferred for production than TOPOLOGY? >> >> Surely one common file is far simpler to distribute than deal with the >> mucky-muck of various configs for each host if they are in one rack or >> another and/or one datacentre or another? It is also fairly >> self-documenting of the setup with the entire cluster there in one file. >> >> From what I read in the documentation, regardless of which snitch one >> implements, cassandra-topology.properties will get read, either as a >> primary or as a backup...so why not just use topology for ALL cases? >> >> Thanks >> >> Marc >> >
